Иногда плохой код - не проблема

Будучи джуном, и только попав на реальный коммерческий проект, делая большую задачу, в одном из “попутных” компонентов я встретил функцию-швейцарский нож на 400+ строк.

Первая же мысль - инкапсулировать, вынести проверки, преобразования, сайд-эффекты и тд в отдельные функции.

Так и сделал.

На следующее утро на дейлике я рассказал как круто я все сделал, как теперь легко и просто читать и понимать, что там в коде происходит.

После дейлика со мной созвонился лид, и если кратко озвучить суть разговора: “не нужно тратить время на рефакторинг и подобные оптимизации. Это место было написано 6 лет назад, столько же никому не было нужно, и столько же не понадобится”.

Тогда меня это сильно демотивировало, потому что я услышал “этот код никому не нужен”.

По прошествии лет, вспоминая эту историю я понимаю, что речь была совсем о другом.

Я смотрел на ситуация глазами разработчика.

Лид смотрел на нее глазами бизнеса.

Разработчик видит функцию на 400+ строк и хочет сделать “красиво”. Бизнес видит место в системе которое живет, не ломается и не требует изменений.

Именно тогда я впервые столкнулся с мыслью, которая поначалу мне совсем не понравилась:

Не каждая проблема в коде является проблемой для бизнеса.

И чем дольше работаешь в коммерческой разработке, тем чаще приходится выбирать не между хорошим и плохим кодом, а между стоимостью изменений и их реальной ценностью для проекта.