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

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

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

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

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

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

Давление бизнеса

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

В этом случае, в коде появляются заплатки и костыли, которые скрывают недоделанные части проекта.

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

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

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

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

Это когда проект напоминает монолит, а не связь отдельных модулей.

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

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

Отсутствие немедленной обратной связи поощряет быстрые, но рискованные исправления (читай, «костыли»), иногда прямо на продакшене.

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый участник проекта пишет код так, как считает правильным (читай, «так как он писал на прошлом проекте»).

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

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

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

Устали читать?

Сбегайте за подушкой, у нас тут контента на 7 часов чтения.

Или попробуйте наш интерактивный курс. Он гораздо более интересный, чем банальный текст.

Узнать больше...