О том, что такое технический долг и кому мы его должны, вы можете узнать по ссылке:

Здесь же рассмотрим варианты оценки технического долга:

  • Контроль качества внешними аудиторами;
  • Визуальная проверка качества разработчиками (код-ревью);
  • Автоматизированные отчеты о качестве кода (разовые);
  • Непрерывная инспекция (Continuous Inspection).

Разберем их подробно:
Допустим, вы решили проверить, что же там наразрабатывали ваши инженеры-разработчики, и обратиться к аудиторам из громкой COMPANYNAME; передаете им в каком-то виде код, аудиторы долго и упорно, упорно и долго, долго и долго проверяют, затем выдают вам толстенный отчет о том, как все плохо и вообще. Но что дальше? Дать отчет своим разработчикам, дабы они прочитали и кинулись исправлять? А как же новый функционал, сроки ведь горят?! (Это еще не говоря об оплате услуг аудиторов).

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

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

И вот здесь на сцену выходят системы непрерывной инспекции кода. В общем случае, это система, которая проверяет с некоторой частотой (раз в сутки/каждый коммит/etc) исходный код, сохраняет в базу данных замечания с именем причастного разработчика и суммой того самого Технического Долга, внесенного в систему.

Сравним же между собой подходы по разным критериям:

Отмечу еще раз: собственно сумму технического долга в явном виде – количество времени, необходимого на рефакторинг – выдают только системы Continuous Inspection.

Что непосредственно влияет на сумму технического долга, вы можете узнать здесь:

Вы нашли ответ?