❓Эффект разбитых окон при доработке легаси-кода

Представьте ситуацию: разработчику Васе (имя вымышленное, но ситуация реальная) предстояло изменить некий существующий функционал. По факту оказалось, что за последний год до него там была пара итераций доработок, выполненных другими подрядчиками.

В результате этих доработок изначально неплохо написанный механизм два разработчика довели до смердящего 💩 состояния. (Оценку "неплохо" даю по фрагментам незатронутого доработками смежного кода.)

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

Заказчик в код не смотрит, а новый функционал соответствует его ожиданиям. Ограничения по бюджету и сроку соблюдены. Сам Вася комплексов, как я понял, не испытывает. Код в этом модуле изменяется относительно редко и от него ничего серьезного не зависит. Это так мой внутренний голос эффективного (зачеркнуто) менеджера 😈 убеждает меня, что все ок.

А моя технарская душонка 👼 не спокойна и все равно требует сказать Васе, что так нельзя и что нужно было хотя бы поднять вопрос о рефакторинге. А еще лучше, заставить его в назидание все хорошенько прибрать.

Как бы поступили вы на месте разработчика? Зарефакторили молча? Или все-таки сначала обсудили бы явно с руководителем/заказчиком, а уже в случае отрицательного решения — наговнокодили? Или, может быть, забили бы на окружающий старый код, но сами постарались бы написать чисто?

Нормально ли, когда разработчик, видя говнокод, который ему предстоит доработать, вместо того, чтобы прибрать, подбрасывает в него свеженького? Или это проявление непрофессионализма?

Кажется, неплохая тема для пятничной дискуссии. Предлагаю обсудить в @ssl1c :-)

#codesmells #говнокод