Народ, всем привет. В мире программирования существует негласное правило, что большинство кода пишется как некое временное решение, которое остается навсегда. Этот феномен получил в народе ироничное название код "на вынос". Мы быстро пишем что-то «временно», чтобы решить текущую задачу, а потом этот код живёт годами, обслуживается другими программистами и становится техническим долгом. Но почему так происходит, почему временное становится постоянным? Почему философия "потом перепишем" почти никогда не работает? Давайте разберёмся.
1. Дедлайны
Да, все мы программисты любим чистый, поддерживаемый и расширяемый код. В теории... и на словах. Но реальный мир диктует другие правила. Компании находятся в условиях жесткой конкуренции, и скорость вывода продукта на рынок зачастую важнее его архитектурной красоты. Типичный сценарий:
— "Нам нужно выпустить этот функционал до пятницы."
— "Но архитектура требует больше времени."
— "Сделай, как можешь. Потом улучшим."
Это "потом" в 90% случаев не наступает. Как только фича работает, приоритет смещается на следующую задачу. Улучшения, рефакторинг и устранение временных решений попадают в бэклог, где тихо умирают. А начальник подкидывает вес новые задачи, и ты вроде куда-то там записал себе в блокнотик, что надо «переписать»… но где сейчас этот блокнотик?
2. Переоценка будущего времени
Человеческая природа склонна оптимистично оценивать свои будущие возможности. Мы думаем, что у нас будет время все переделать, но будущее приходит с новыми проблемами, багами, фичами, срочными запросами. И тут наступает психологический парадокс: «Я сейчас сделаю временно, потому что завтра у меня будет больше времени и ясности, чтобы всё сделать идеально.» Но правда в том, что завтра будет еще меньше времени. А ясности может и не прибавиться.
3. Код —это коммуникация
Большинство программистов думают о коде как о некой технической структуре. Но на практике код похож на средство коммуникации между людьми, его часто пишут одни, а читают другие. В условиях спешки разработчик может написать нечто быстрое, с минимумом комментариев и тестов, думая: "да и так всё понятно". Для него — да. Для коллеги через полгода — нет. Код, написанный "на вынос", становится непонятным, хрупким и опасным, потому что он вырос из контекста, который больше никто не помнит.
Если Вам нравятся наши статьи, и вы хотите отблагодарить автора (на развитие канала), нам будет очень приятно!
4. Временные решения работают
Один из самых больших парадоксов в том, что временные решения часто работают достаточно хорошо. Да, они кривые, нелогичные, хаотичные, «с костылями, как говорят, но пользователи довольны, продукт приносит деньги, система функционирует. Возникает естественное сопротивление: если работает, зачем трогать? Рефакторинг и переписывание требуют усилий и несут риски, а руководство не хочет тратить ресурсы "на то, что и так работает", особенно если итог неочевиден. Так "временное" превращается в "вечное".
5. Смена команды
Очень часто временный код остается без присмотра, когда автор уходит из команды. Новый разработчик, столкнувшись с хаотичной реализацией, думает: "Я бы это переделал… но кто знает, зачем это вообще было нужно?" А без документации и контекста любое изменение может привести к поломке. Разумный разработчик решит, что лучше не трогать (ну если его палкой не заставить). Так временное решение получает новую жизнь.
6. Миф об идеальном будущем
Команды часто живут в ожидании "новой версии", "переписанного ядра", "архитектурного прорыва", который решит все проблемы. Это дает оправдание не тратить усилия на текущий код. Что дает нам реальность? Новая версия откладывается годами, причем она создается на тех же принципах и ошибках. А когда ее запускают — она уже устарела и ожидание идеального будущего отодвигает необходимость рефакторинга сегодня.
Что нам делать?
Я тут много наговорил, и по итогу может показаться, что всё безнадежно, и любой код обречён быть "на вынос". Но это не так. Есть подходы, которые позволяют уменьшить вред от временных решений:
- добавляйте в код // TODO, скажем, временное решение до версии X, создавайте тикеты, ставьте напоминания. Когда временность становится видимой, ею проще управлять.
- планируйте в спринтах не только новые фичи, но и улучшение старого кода. Хоть 10-15% времени — это инвестиция в устойчивость.
- если пришлось принять нестандартное решение, то объясните почему. Контекст спасает будущих разработчиков от догадок и ошибок.
- если совсем нет времени на идеал, делайте минимально устойчивую архитектуру. Простую, модульную, с четкими границами, но это облегчит рефакторинг в будущем.
Кстати, у нас есть и другой канал, FIT FOR FUN, про фитнес, бодибилдинг, правильное питание, похудение и ЗОЖ в целом. Кому интересно, ждем вас в гости!