КОДЕКС
Получение максимальной отдачи от показателей качества кода
Полное использование цикломатической сложности, индекса ремонтопригодности, покрытия модульными тестами и других показателей в разработке программного обеспечения
Метрика - это число, которое измеряет некоторые аспекты кодовой базы. В разработке программного обеспечения существует множество показателей кода, которые можно собирать и анализировать для различных целей. Вот лишь несколько общих показателей кода:
- Покрытие модульными тестами измеряет процент покрытого (выполненного) кода модульными тестами.
- Цикломатическая сложность измеряет минимальное количество тестовых примеров, необходимых для получения полного тестового покрытия.
- Когнитивная сложность - это мера того, насколько сложно понять приложение.
- Индекс ремонтопригодности показывает, насколько легко поддерживать и изменять исходный код.
- И многие другие, такие как количество запахов кода, количество дубликатов (строка, блок, файл), глубина наследования, связывание классов, строки исходного кода, строки исполняемого кода и т. Д.
Метрики качества кода можно измерить отдельно для разных уровней проекта. Например, цикломатическая сложность может быть измерена для метода, класса, пространства имен, модуля или всего проекта.
Приятно то, что все виды показателей можно быстро собрать с помощью инструментов статического анализа кода (SonarQube, Veracode, DeepSource и т. Д.). Отчет, который включает в себя набор показателей кода, может быть предоставлен клиенту, чтобы сделать его счастливее, но это не единственный способ их использовать.
Постоянный мониторинг кодовой базы
Когда команда инженеров начинает работу над новым проектом, они должны начать сбор метрик с самого начала фазы разработки. Такой подход позволит команде быстро заметить снижение качества кода и немедленно отреагировать.
Когда группа инженеров начинает работу над унаследованным проектом, они должны собирать показатели, чтобы получить истинное представление о состоянии проекта, представлять их клиентам и / или менеджерам и постепенно увеличивать числа показателей до приемлемых значений. за счет улучшения качества кода.
Важное примечание: статический анализ кода должен быть частью конвейера непрерывной интеграции, и он прерывает сборку, когда показатели падают ниже приемлемых значений (или так называемых ворот качества).
Качественные ворота
Команда разработчиков программного обеспечения должна определить так называемые номера ворот качества для каждой интересующей их метрики и опубликовать их в пространстве проекта (например, Confluence). Такой подход позволит каждому члену команды, менеджеру или клиенту быстро проверить определенные параметры качества в любой момент времени и предложить некоторые улучшения. Если команда изо всех сил пытается выяснить, каким качественным номерам ворот должны быть равны, они могут выбрать их в соответствии с передовой практикой. Например, охват модульным тестом должен быть не менее 70%.
Масштабный рефакторинг
Рефакторинг - это то, что не очень ценно для менеджеров и клиентов, потому что они не могут быстро увидеть результаты проделанной работы. Один из способов доказать, что масштабирование было полезным, - продемонстрировать отчет о метриках качества кода «до» и «после». Для этого вам потребуется:
- Собирайте метрики перед рефакторингом
- Выполнить рефакторинг
- Собирать метрики после рефакторинга
Убедитесь, что в отчет включены метрики, понятные для нетехнических специалистов, такие как количество дубликатов, охват модульных тестов и т. Д.
Цель сбора показателей до и после рефакторинга не только в том, чтобы показать результаты рефакторинга нетехническим специалистам. Эти «отчеты до и после» важны для разработчиков программного обеспечения, поскольку они могут быть уверены, что рефакторинг одной части кодовой базы не повлиял на качество других частей.
Быстрый поиск некачественного кода
Причины быстрого поиска некачественного кода в большой кодовой базе могут быть разными, например:
- Когда проект программного обеспечения передается от компании A компании B, архитекторам программного обеспечения компании B необходимо оценить кодовую базу проекта: собрать ее метрики и описать все обнаруженные элементы технического долга. Компания Б может даже отклонить проект, если он очень низкого качества.
- Иногда техническим руководителям сложно найти работу для одного из членов команды. Это может произойти, если команда выполнила задачи спринта на несколько дней быстрее, но объем работ для следующего еще не ясен. В этом случае технический руководитель может запустить статический анализатор кода, найти какой-то фрагмент кода низкого качества и попросить члена команды провести его рефакторинг.
Заключение
Сами метрики просты. У инженеров-программистов есть инструменты статического анализа кода, чтобы быстро собрать их в несколько кликов. Почему бы не начать их использовать сейчас?
