Новый разработчик и «синдром наследия» 🌀

Приходит новый разработчик в компанию. Первое, что он видит — это, скорее всего, уже написанный код какого-нибудь работающего проекта компании. Начинает его изучать и удивляется: «Как это вообще работает?». Затем он убеждается в этом и, как мы помним, со своим уставом в чужой монастырь не ходят — новичок начинает следовать тому стилю и приёмам в коде, которые использовались при написании кода до него. А если и прошлого разработчика ещё и повысили или поставили новичку в руководство, то это подкрепляет мотивацию продолжать писать так же.

Но тут скрыта коварная ловушка. Часто предыдущие разработчики (или даже целая команда!) придерживались простого принципа: «Это временная реализация и тот, кто будет за это ответственен потом это перепишет». 😈 И вот он, тот самый «новый разработчик», который должен был прийти и всё исправить, продолжает идти по тому же "наклонному" пути, что приводит к ужасному коду и непомерно выросшему техническому долгу 😒

Почему так происходит? ✅ Страх поломать рабочий код Если код работает, то трогать его страшно. Новый разработчик думает: лучше я просто допишу что-то похожее рядом, чем рискну трогать уже написанный и работающий код, так как после переписывания нужно будет ещё и всё заново оттестировать, то есть это добавит работы всем.

✅ Отсутствие времени на анализ На изучение и рефакторинг старого кода нужно время, а дедлайны по текущим задачам уже давят. Легче «подстроиться» под текущую логику, чем понять её, а тем более улучшить её реализацию.

✅ Менталитет «я здесь ненадолго» Иногда разработчики приходят в компанию с мыслью: «Я поработаю тут год-два, а дальше — другой проект». Зачем вкладывать силы в улучшение архитектуры, если тебе кажется, что это не твоя ответственность?!

✅ Код — как язык Каждая команда пишет код в своём стиле, и новому разработчику сложно ломать этот стиль, даже если он видит в нём проблемы. Он начинает адаптироваться, чтобы его не считали «чужаком».

Можно ли это исправить? Можно и нужно! Синдром наследия лечится несколькими шагами:

1️⃣ Создать культуру изменений. Объяснить команде, что улучшение кода — это не только допустимо, но и приветствуется.

2️⃣ Документировать технический долг. Ввести понятие технического долга и фиксировать его: где нужны улучшения, какие участки следует рефакторить и каким образом.

3️⃣ Давать время на редакторинг. Выделять хотя бы часть спринта для работы над улучшением старого кода.

4️⃣ Устраивать коллективные разборы. Пусть команда собирается и обсуждает проблемные участки, чтобы находить компромиссные решения.

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

Моя личная позиция: всегда нужно задавать вопросы. Почему этот код написан так? Почему никто его не трогал? Что произойдёт, если я попытаюсь его улучшить и нужно ли это делать сейчас? Новичкам важна поддержка, но и компании нужно поощрять взгляд со стороны. Иногда свежие глаза замечают то, что ветераны проекта уже просто не видят.

А вы когда-нибудь оказывались в такой ситуации? Или, может быть, сами стали тем, кто «запустил» эту цепочку? Делитесь своим опытом и мыслями в комментариях! 😊