Когда я только начинал программировать, я мечтал писать идеальный код. Чистый, элегантный, с правильной архитектурой и комментариями в духе учебников. Каждый метод — не длиннее 10 строк, каждое название переменной — словно из художественной литературы.
Но потом пришла реальность.
История из практики
На одном проекте мне дали задачу: «Сделать выгрузку данных в Excel». Казалось, что на пару часов. Но я решил подойти «по-взрослому»: выделил отдельный слой сервисов, сделал абстракции под разные типы экспорта, добавил конфигурацию под будущее масштабирование.
И знаете что?
Через три дня ко мне подошёл менеджер и сказал:
— Нам нужно просто одну кнопку, которая выгружает таблицу. Ничего больше.
В итоге мой «шедевр архитектуры» полетел в корзину. Потому что бизнесу нужно было решение здесь и сейчас, а не идеальная система для гипотетического будущего.
Где грань?
- Идеальный код полезен, когда проект долгосрочный, будет развиваться и поддерживаться. Чистая архитектура экономит десятки часов в будущем.
- Рабочий код спасает, когда важна скорость: MVP, тест гипотезы, срочный багфикс. Иногда «костыль» — это не зло, а реальный способ спасти дедлайн.
Вывод
Нет смысла фанатично стремиться к идеалу, если завтра проект могут закрыть. Но и лепить хаос ради скорости тоже не вариант — он быстро превращается в болото, где невозможно работать.
Истина где-то посередине: код должен быть настолько хорошим, насколько это нужно задаче и бизнесу.
И вот главный секрет: опытный разработчик умеет чувствовать этот баланс.
