💻 Ты можешь сколько угодно читать “Чистый код” от Мартина, учить SOLID, стремиться к идеальной архитектуре. А потом приходит дедлайн — и ты строчишь функции по 200 строк. Почему так? И есть ли способ выбраться из этой ловушки?
Все начинается с хороших намерений
Каждый разработчик, особенно на старте карьеры, слышит фразу: «Пиши код так, будто завтра его будет поддерживать кто-то другой». Это правильно. Это красиво. Но как только начинается реальная работа, выясняется: «завтра» — это сегодня вечером, а тот, кто поддерживает — ты сам, в полусонном состоянии и с кофе вместо крови.
Вот так появляются:
- переменные a, b1, tempFinalResultNew2
- цепочки if длиной с ленинградскую блокаду
- файлы utils.js, внутри которых спрятана бизнес-логика всего проекта
Ты не хотел так писать. Но проект горит. Менеджер торопит. Появляется легитимное «потом рефакторим» — и исчезает навсегда.
Почему «грязный» код — это не признак некомпетентности
Часто думают: если код плохой — значит, программист слабый. На деле — всё наоборот. Чем опытнее разработчик, тем чаще он осознанно пишет «грязно», понимая цену времени, бюджета и задач.
Пример из жизни: если ты пишешь MVP, который либо выстрелит, либо будет удалён через 2 недели — зачем строить архитектуру, как будто это банковская система?
Реальный код живёт в компромиссах. И эти компромиссы — между качеством и скоростью, удобством и надёжностью, «правильно» и «работает».
Когда «грязный» код становится проблемой
Однако рано или поздно код «выползает» за рамки задачи. Он начинает расти. Меняться. Появляются новые разработчики, и никто не понимает, что вообще происходит.
Симптомы:
- ты боишься трогать рабочий модуль, потому что всё может сломаться
- баг фиксится в одном месте, но ломается в другом
- ты тратишь больше времени на чтение кода, чем на его написание
В этот момент «грязь» перестаёт быть компромиссом — и становится тормозом.
Что с этим делать
- Понимай контекст. Не всегда нужен идеальный код. Если это скрипт на пару часов — не трать день на архитектуру. Но если это основа проекта — подумай на 3 шага вперёд.
- Мини-рефакторинг на лету. Если зашёл в старый файл и видишь трэш — не пытайся переписать всё. Улучши хотя бы то, что трогаешь. Это как уборка по чуть-чуть: со временем становится чище.
- Пиши комментарии — себе в будущее. Не надо писать роман. Просто объясни, почему код такой. Через месяц ты будешь себе благодарен.
- Не бойся выкидывать код. Иногда проще удалить модуль и написать с нуля, чем чинить Frankenstein-код. Это не провал, а взрослая инженерная практика.
- Заводи «долг» сознательно. Если пришлось сделать костыль — запиши его в трекер задач. И поставь реальный срок. Лучше плохой код, о котором помнят, чем «забытый» ужас.
И в завершение
Каждый код — это отражение реальности, в которой он был написан. Идеальный код — редкость. Важно не стыдиться компромиссов, а понимать, зачем ты их делаешь, и уметь вовремя остановиться.
В мире, где всё постоянно меняется, лучшая стратегия — не гнаться за идеалом, а быть честным с собой и командой. И тогда даже «грязный» код станет чуть-чистее.
📌 Если было полезно — поставь лайк и подпишись на канал GIRSOFT.