Нет ничего более постоянного, чем временный костыль в коде 🤔

Как часто вы сталкивались с ситуацией: на проекте что-то срочно сломалось, горит, ждать нельзя, нужно чинить прямо сейчас. Решение? Конечно, быстро чинить, ведь на этом может держаться критичный функционал, а на некоторых проектах минута простоя стоит миллионы, а иногда и больше.

Делается моментальный фикс, в коде появляется TODO: потом переделать, все выдыхают и бегут дальше.

А потом? А потом никто до этой "временной" правки так и не добирается.

Через какое-то время таких TODO становится десятки, а еще позже – сотни. И вот уже целые модули строятся на костылях, которые вроде бы работают, но на них страшно смотреть. Ведь оно же работает. А если работает – лучше не трогать, потому что страшно представить, что может развалиться при попытке что-то поправить.

Не зря говорят: нет ничего более постоянного, чем временное.

📌Почему временные костыли живут вечно?

❌ Нет времени на рефакторинг Поставили задачу, запилили фичу, закрыли тикет. Всё. А когда-нибудь потом обязательно наведём порядок… Но потом приходят новые задачи, дедлайны, фичи – и уже не до этого.

❌ Костыль работает – значит, пусть живёт Если код не падает и не вызывает критичных проблем, его редко трогают. Даже если внутри всё держится на соплях, главное – «работает же».

❌ Боязнь сломать что-то ещё Разработчики не трогают старый код, потому что не до конца уверены, что за собой потянут изменения. Если система сложная и тестов мало – лучше не рисковать.

❌ Отсутствие культуры технического долга В компании просто не принято выделять время на устранение временных решений. Если нет культуры работы с долгом, костыли накапливаются и в какой-то момент превращаются в проблему.

📌Как мы с этим боремся?

✅ Фиксируем костыли в коде и в задачах Если пришлось сделать временное решение – его нужно зафиксировать. Мы используем техдолговые тикеты в бэклоге, а в коде ставим TODO с датой и комментарием, чтобы было понятно, зачем этот костыль появился.

✅ Закладываем время на рефакторинг в спринты Недостаточно просто завести тикет. Обычно рефакторинг – это «сделаем потом». Мы включаем его в планирование, чтобы он не откладывался в долгий ящик. Обычно 10% времени в спринте мы уделяем именно рефакторингу и устранением таких вот TODO.

✅ Проводим ревью не только кода, но и архитектуры Костыли часто проходят код-ревью, потому что они локально решают проблему. Но если смотреть на архитектуру в целом, можно заранее находить решения, которые лучше переделать сейчас, а не через год. Ревью архитектуры стоит также регулярно планировать, мы обычно проводим 1 раз в месяц.

✅ Добавляем аналитику по TODO в ретроспективу Сколько появилось, сколько закрыли, общее количество. То, что измеряется – улучшается. Если на каждой ретроспективе смотреть динамику: сколько новых TODO появилось, сколько убрали, сколько висит слишком долго – процесс будет под контролем, а не в хаосе.

📌Что в итоге? Костыли в коде – это не всегда плохо. Иногда они помогают быстро решить локальную проблему и не дать бизнесу потерять деньги. Вопрос в том, что с ними делать дальше.

❌ Если забыть – временное становится постоянным. ✅ Если контролировать – код остаётся чистым и поддерживаемым.