Управление техническим долгом в проекте

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

  • Владение кодом (определение разработчиков, ответственных за разные участки кода). Код, у которого нет явно выраженного владельца (доля коммитов каждого из программистов меньше 65, а то и 50 процентов), скорее подвержен дефектам. 1, 2:

    • Компоненты ПО с большим количеством участников больше подвержены дефектам.
    • Компоненты ПО с явно выраженным владением (доля коммитов одного разработчика составляет от 50 до 100 процентов) менее подвержены дефектам.

    Способы анализа владения есть в 3, главы 12 и 13, помимо них предлагается:

    • Обращать внимание на минорных участников, изменяющих код, которым они не владеют
    • Удостовериться, что все изменения минорных участников проходят ревью у основных участников (владельцев кода)
    • Проверять, владеют ли функциональные команды “своими” участками кода

  • Связность (cohesion). Это косвенная мера качества архитектуры, показывает, насколько хорошо спроектированы компоненты. Высокая связность уменьшает (в идеале минимизирует) количество людей, необходимых для внесения изменений в код компонента. Низкая связность - причина дефектов 4. Связный коммит - тот, в котором изменения вносятся только в исходники одного пакета (модуля, папки и т.п.). Исходя из этого можно вывести долю “связных” коммитов в общем числе коммитов. Или же можно воспользоваться показателем “временное связывание” из 3, главы 7,8. Анализ показателя предлагается проводить по двум направлениям:

    • Отслеживать изменения доли “связных” коммитов, она должна расти.
    • Находить излишне связанные компоненты, чтобы инициировать рефакторинг

  • Взбалтывание кода (churn). Это повторяющиеся изменения. В идеале готовая функциональность не должна дорабатываться, все новые функции должны оформляться в виде новых файлов и модулей (Open-Closed Principle). Исследование Microsoft 5 показало, что активно изменяемые файлы составляли 2-8% от общего числа, но на их долю приходилось 60-90% всех дефектов. В 3 анализ этой метрики рассматривается в главе 14, наряду с этим можно использовать следующие направления:

    • Отслеживать наиболее часто изменяемые файлы - это, как правило, источник дефектов
    • Обеспечить более тщательную проверку часто изменяемых файлов на код-ревью

Источник или Архив в Pocket

Связи и ссылки

Don’t Touch My Code! Examining the Effects of Ownership on Software Quality in Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, 2011

Active files as a measure of software maintainability — Microsoft Research или https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/using-simple-code-churn-metric-find-software-bugs

  1. Исследование в Microsoft ↩︎

  2.  ↩︎

  3. Your Code as a Crime Scene, Adam Tornhill, Код как место преступления ↩︎ ↩︎ ↩︎

  4. https://ieeexplore.ieee.org/document/6498451 ↩︎

  5.  ↩︎