В контексте разговора о техническом долге (ТД) следует напомнить о том, что такое ТД, и как мы можем его контролировать:

Вообще, тема непрерывной проверки кода не является каким-то секретом, про нее есть небольшая статья на википедии:

Да и на любимом всеми хабрахабре есть те, кто рекламят себя и свои продукты в данной сфере (тут уж без ссылок).

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

Для начала определимся с ключевыми принципами Continuous Inspection:

  • Качество – общая задача, ответственность за которую лежит на разработчике;
  • Информация о техническом долге должна быть актуальна в любой момент времени;
  • Данные о качестве – абсолютные и разностные;
  • Процедура проверки качества должна быть максимально объективна;
  • Стандарты качества едины для всех проектов;
  • Все новые и критичные замечания имеют ответственного за них.

Что мы получим, если будем следовать принципам:

  • Этап проверки качества кода включается в процесс ежедневной разработки;
  • Нахождение проблем до выпуска в продуктив;
  • Уверенность заказчика в качестве продукта;
  • Постоянное сокращение затрат на последующую разработку;
  • Возможность отслеживать тенденции развития продукта.

Если же отойти от презентационного языка на русский, то мы имеем дело с системой, которая в общем случае предполагает 2 сценария использования:

  • Локальный – разработчик или группа таковых разворачивают свой локальный сервер проверки кода; мотивация может быть разной, но, чаще всего это делается для упрощения процесса дебаггинга. Опытный разработчик  и так должен понимать, где он поступился с качеством в пользу сокращения затрат времени, какие костыли применил и к чему это может привести в будущем. Что-то вроде "инициативы снизу".
  • Производственный – в таком случае проверка кода ведется либо с самого начала разработки, либо внедрилась в какой-то её момент; очевидная "инициатива сверху".

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

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

Примеры в картинках:

Тут мы имеем дело с проектом, который удовлетворяет заданным критериям качества:

А здесь проект уже не проходит (и более того, понятно почему):

Более подробно (с информацией о техническом долге общем и привнесенном, ошибках и так далее):

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

  • Количество ошибок:
  • Рейтинги уязвимости, безопасности и сопровождаемости;
  • Покрытие кода тестами (а при правильной разработке тесты функционала пишутся перед его реализацией);
  • Процент дублирования кода;
  • Критерии качества;
  • Технический долг общий и на каждого разработчика;
  • Замечания к коду с указанием авторства;
  • и так далее...

Если резюмировать, то концепция Continuous Inspection – непрерывной проверки исходного кода – в качестве метода контроля технического долга еще при сравнении с другими методами чисто на бумаге показала себя выше остальных на голову. 

А после столь подробного рассмотрения, по-хорошему, должен возникать вопрос:

— Как вообще можно вести разработку без непрерывной проверки кода?

Если вы задались подобным вопросом, тогда нам с вами по пути:


P.S.: Глазастые 1С-ники на одной из картинок должны были заметить аббревиатуру BSL, подробнее здесь:

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