Технический долг

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

Впервые метафору «технического долга», относительно грязного кода, предложил Говард Каннингэм.

Взяв кредит в банке, вы сможете ускорить какое-то приобретение. Однако вернуть вам предстоит не только основную сумму кредита, но и дополнительные проценты, которые набегут за то время, пока вы не погасите заём.

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

То же происходит и с кодом. Сегодня вы временно ускоритесь, не написав тесты для новой фичи. Но каждый день пока эту фичу приходится тестировать руками, замедляет ваш общий прогресс. В какой-то момент, сумма этого времени превысит ту, которую вы бы потратили на изначальное написание теста.

Причины появления технического долга

Давление со стороны бизнеса

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

Отсутствие понимания последствий технического долга

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

Отсутствие борьбы с жёсткой связанностью компонентов

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

Отсутствие авто-тестов

Отсутствие немедленной обратной связи поощряет быстрые, но рискованные исправления и «костыли», иногда прямо на продакшене. Эффекты от этого бывают катастрофические. Например, невинный хот-фикс рассылает тестовое письмо по всей базе клиентов или удаляет реальные данные клиентов в базе данных.

Отсутствие документации

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

Отсутствие взаимодействия между членами команды

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

Долговременная одновременная разработка в нескольких ветках

Может вызвать накопление технического долга, который необходимо восполнить при слиянии изменений воедино. Чем больше изменений, которые сделаны изолировано, тем больше итоговый технический долг.

Отложенный рефакторинг

Требования к проекту постоянно изменяются и в определённый момент, может стать очевидным, что части кода устарели, стали громоздкими и должны быть переработаны под новые требования.

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

Отсутствие контроля за соблюдением стандартов

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

Отсутствие компетенции

Когда разработчик просто не умеет писать качественный код.