Эту тему я уже разбирал, но, правда, только с технической стороны в статье «Как я выбираю: костыль, рефакторинг или чистая архитектура» - там про алгоритм, зоны ответственности и инструменты. Здесь же я хочу поговорить, где проходит та самая внутренняя граница, после которой решение перестаёт быть профессиональным.
В моменте, костыль редко выглядит как костыль
Вы когда нибудь слышали или сами принимали решение со словами: "А давайте сделаем нашу систему хуже, чем она есть"? Вот и я никогда этого не слышал.
Наоборот, в моменте оно почти всегда выглядит разумно, логично и даже профессионально.
- "Сейчас не до архитектуры, бизнес горит, отгрузки стоят"
- "Это временно, потом переделаем"
- "Главное, чтобы сейчас заработало"
Я сам так говорил и продолжаю так говорить, не потому, что не понимаю последствий, а потому, что в этот момент эти последствия кажутся какими-то абстрактными, а задача вот она, здесь, конкретная и срочная.
Проблема в том, что “потом” почти никогда не наступает.
Не потому, что все ленивые. А потому, что как только решение начинает работать, у бизнеса сразу пропадает мотивация что-либо менять, появляются более срочные и важные задачи. Оно же работает или "работает, не трожь". То, что такое решение при этом медленно убивает систему изнутри, не видно же в отчётах за текущий месяц.
При этом самое опасное в таких решениях не сам костыль, который остался в системе, а момент, когда мы перестаём считать его своей ответственностью или другими словами, когда он для нас перестает казаться костылем. Вот с этого места начинается уже не технический долг, а профессиональное равнодушие. Этим довольно часто "грешат" фирмы-франчайзи 1С, не буду говорить о всех, но я довольно часто встречал такие решения, оно и понятно, сроки, акты, нужно как можно быстрее закрыть задачу, тут уже не до архитектуры, работает и хорошо, акт у заказчика подписан, отлично, деньги заплатил - вообще супер!
В качестве теста можно задать себе простой вопрос, готов ли ты через год открыть этот код и сказать: "Да, это всё ещё моё решение" или будет стыдно даже вспомнить, что ты здесь участвовал.
Где проходит та самая граница на самом деле
Эта граница проходит не по красоте кода, не по количеству паттернов и даже не по тому, "правильно" ли сделано с точки зрения учебника.
Граница проходит по ответственности за будущее.
Не за то, что система заработает сегодня, а за то, какой она станет через год, два, три и сколько будет стоить её поддержка, развитие и исправление найденных ошибок.
Я для себя давно сформулировал один простой фильтр:
Готов ли я потом отвечать за последствия этого решения - не формально, а по-чесноку?
Если ответ "да" - значит, решение в зоне моей ответственности, даже если оно временное, кривое, косое и неидеальное.
Если ответ "нет" - значит, я в этот момент не помогаю бизнесу, а перекладываю проблему на будущих себя, коллег или компанию.
И вот здесь появляется важный момент: иногда этично все же сделать костыль.
Но неэтично - не осознавать, что ты его сделал и не считать себя ответственным за его последствия.
И если ты в момент принятия решения честно можешь сказать:
"Да, я понимаю, что это временно. Да, я понимаю, какие риски я беру. Да, я беру ответственность за то, что это нужно будет переделать" - то, скорее всего, ты по эту сторону границы.
А если внутри звучит: "Ну, я тут просто закрыл задачу, дальше пусть кто-нибудь другой разбирается" -
то, скорее всего, граница уже пройдена.
Как делать костыли этично
Да, иногда костыль нужен и даже обязателен. Срочно, вчера, чтобы бизнес не встал.
Но разница между профессионалом и просто "сделаем и забьём" - в том, что профессионал ставит метку на временное решение и несёт ответственность за его последствия.
Вот мои простые правила:
-
Нужно признать, да это костыль
Хорошо бы отметить его комментариями, в документации, в таске. Не нужно прятать за комментарием "это маленькая правка". Костыль нужно называть своим именем:
// ВРЕМЕННОЕ РЕШЕНИЕ (FIRE). Удалить после: 01.03.2026. Автор: Иванов. -
Не нужно превращать временное решение в постоянное
Костыль должен жить ровно столько, сколько нужно, чтобы снять пожар. Дальше обязательно рефакторинг или архитектура. -
Последствия
Даже временное решение имеет свою цену: время будущих коллег, ошибки, сложность изменений и доработок. -
Выйти за пределы задачи
Если костыль влияет на другие модули или процессы, хорошо бы его как-то изолировать. Вынести логику в отдельный модуль, чтобы не заразить всю систему. Чтобы не лепили на этот костыль другие костыли. -
Разбор полётов
Нужно обязательно создать задачу, напоминание, тикет, который не даст забыть о костыле и вовремя напомнит.
Кажется, это сложно, но на практике все просто: костыль перестаёт быть "заложенной бомбой" и остаётся инструментом, который решает срочную проблему, при этом не убивая систему изнутри.
Профессиональная ответственность как компас
Костыль в моменте почти всегда выглядит разумным, но его последствия растут незаметно.
Профессионал тот, кто честен с собой, понимает риски, фиксирует временные решения, несёт ответственность за них и не превращает их в постоянные или будущие проблемы.
Этика в ИТ - это внутренний компас, который говорит: "Вот здесь я могу временно пожертвовать чистотой кода ради бизнеса, а вот здесь уже нет". Если научишься слушать этот компас, то в дальнейшем меньше придется разбираться последствия чужих или собственных "удобных" решений.
В конечном счёте код, за который не стыдно, - это и есть настоящая совесть профессионала.
Другие статьи автора:
Вступайте в нашу телеграмм-группу Инфостарт