Когда я был начинающим разработчиком и впервые пришёл в офис крупной компании, мне довелось наблюдать забавную сцену. Два уважаемых senior-разработчика с яростью невиданной обычному человеку, спорили о том, какой type указывать в ошибках формата ProblemDetails.
Судя по важности обсуждения, казалось, что от этого выбора зависела не просто судьба нашего API, а миллиардные обороты всей компании.
Спор затянулся надолго - компания уже теряла деньги на этих обсуждениях, если считать стоимость рабочего времени участников. Но мне, тогда ещё начинающему разработчику, это казалось невероятно важным и по-своему прекрасным.
Я восхищался: вот оно - настоящее профессиональное сообщество! Люди настолько горят своим делом, что готовы до хрипоты спорить о, казалось бы, мелочах. Они искренне болели за качество продукта, стремились сделать каждую деталь идеальной. В тот момент я почувствовал, что оказался среди настоящих мастеров своего дела.
А на самом деле, насколько это важно?
Неожиданное открытие: оказалось, что фронтенду вообще неважно, какой именно ключ ошибки вы присылаете. Главное — чтобы он не менялся со временем.
Выходит, все эти горячие дискуссии были просто борьбой вкусовщины, а не поиском технически обоснованного решения. Никакой реальной пользы от них — только потраченное время.
И этот пример - лишь верхушка айсберга. За годы работы я пришел к неутешительному выводу: для большинства разработчиков понятия "правильно" и "хорошо" сводятся к простому принципу - делать так, как делали на предыдущем проекте и мне это нравилось. А на вопрос "почему так?" ответа нет. Потому что это всего лишь чьи-то вкусовые предпочтения, не более.
Причем на предыдущем месте работы, скорее всего, тоже не всё было идеально. Например, у моего друга в компании появился новый сотрудник — он активно раздавал советы налево и направо. Потом он решил «поделиться» кодом из своего прошлого проекта — просто чтобы показать. И… лучше бы он этого не делал.
Это был настоящий тихий ужас. Словно собрали команду школьников со всей страны и дали им полную свободу — реализовать все свои самые безумные программистские фантазии без единого намёка на ревью или архитектуру...
А может просто добавить еще один враппер?
В итоге, если в команде нет "сильной руки", которая держит крепко за шею любителей архитектурных изысков и вкусовщины, проект постепенно деградирует. Код обрастает лишними обертками, теряется единая архитектура, множатся баги - и вот уже живой проект превращается в легаси, которое до ужаса страшно открывать.
Самое ироничное, что сами разработчики искренне не понимают проблемы. В их глазах они следовали "лучшим практикам": напичкали код паттернами из банды четырёх, наворотили врапперов для "удобства", применили все модные подходы. Но почему-то система только усложнилась, а не стала лучше.
Заказчик обращается к разработчикам
Лучше простой медленный код, чем сложный быстрый код
Я не против использования паттернов или архитектурных решений в принципе — это всего лишь инструменты. Но, как и с любым инструментом, важно понимать, когда и зачем его применять.
Классический пример — появление ООП. Разработчики бросились использовать все его возможности без разбора: злоупотребляли полиморфизмом, выстраивали многоуровневые цепочки наследования. Результат? Монструозные кодобазы на С++, где простейшее изменение требует анализа десятков связанных классов.
Поэтому при создании проектов следует изначально стремиться к максимальной простоте, избегая ненужных архитектурных изысков. Простой, пусть даже неидеальный код обладает двумя критически важными преимуществами:
Поддерживаемость - его легче читать, анализировать и модифицировать
Потенциал - оставляет пространство для точечного рефакторинга проблемных мест
Сложные же системы с избыточными абстракциями часто попадают в замкнутый круг: их страшно менять, поэтому их дополняют новыми костылями, что делает их еще сложнее. Как показывает практика, "медленный, но понятный код" в долгосрочной перспективе оказывается выигрышнее "оптимального, но запутанного".
Немного мудрости
Я работал с очень разной кодовой базой. Когда код был простым и прямолинейным, отладка и анализ проблем редко вызывали трудности. Однако когда появлялись хранимые процедуры или модули, выбираемые из DI-контейнера по случайно сгенерированному числу, желание работать моментально пропадало.
Закон ускоренного legacy-образования
В целом, почти любые проекты со временем начинают терять актуальность и превращаться в легаси. А всё потому, что экосистема, на которой ведётся разработка, постоянно меняется и обрастает новыми плюшками, делающими код красивее и проще. Меняется и поколение разработчиков — для них эти новые плюшки становятся единственной известной реальностью, отправной точкой в работе.
А мы, как обычные работяги, можем лишь ускорять или замедлять этот процесс, постоянно отодвигая планку легаси. Для этого нужен простой код, который легко обновлять.
Когда нанял senior-разработчика на очень интересный проект и задачи
Однако бывает и так: как бы ты ни старался, проект деградирует гораздо быстрее. Это напрямую зависит от интенсивности разработки - чем она выше, тем стремительнее код превращается в легаси.
Особую роль в этом процессе играют заказчики. Сначала они четко прописывают сценарии использования функционала, а потом неожиданно требуют прямо противоположного. В результате проект неизбежно проходит через:
"Костылизацию" - временные решения становятся постоянными
Архитектурную деградацию - изначальная структура теряет целостность
Накопление технического долга - который со временем только растет
Поэтому необходимо устраивать передышки - хотя бы ненадолго приостанавливать разработку бизнес-функционала и проводить минимальный рефакторинг, прежде чем снова ринуться в эту вальхаллу разработки.
Код ревью или сделай, как мне нравиться
Ещё одно место для продвижения своих предпочтений — это сломанный процесс code review. Когда человек приходит не проверить выполнение бизнес-задачи или соответствие кода стандартам команды, а чтобы предложить, как можно сделать лучше. Ведь он-то знает, как — потому что видел, как это делали на предыдущей работе.
Причём чем больше ревьюеров в сломанном процессе — тем тяжелее обычному работяге добраться до прода.
Общение на ревью
В моей практике была сложная ситуация: делал доработку в платформенной библиотеке, где нужно было собрать 5 апрувов, а в списке ревьюеров числилось несколько отделов (человек 45). Всё превратилось в большой срач — при том что изменения были незначительные. В итоге пришлось потратить целый день, чтобы вникнуть в ситуацию и вежливо отсеять 90% ревьюеров.
Один из ревьюеров особенно болезненно воспринимал отклонение своих замечаний и буквально высасывал из пальца проблемы. Дело дошло до того, что он начал придираться к коду, который вообще не относился к моим изменениям. Пришлось отдельно с ним разбираться в личных сообщениях - выяснять, что же у него в жизни произошло, что он превратился в такого токсичного человека.
Заключение
Как ни старайся, проект всё равно будет требовать рефакторинга. Люди чаще предлагают решения исходя из личных предпочтений, а не реальной пользы. Поэтому гнаться за "идеальным" кодом по всем книжным стандартам — невозможно.
Что действительно работает — так это писать код как можно проще. Да, он не будет совершенным, но станет тем самым лучом света для обычных работяг в этом царстве легаси.
Спасибо за внимание!
