Метрики кода, или Как определить внутреннее качество продукта
Необходимость качественного и грамотного написания кода — вот одна из основополагающих вещей, которым мы обучаем будущих программистов при выполнении учебных проектов.
И это не только то, чему мы учим, это еще и то, что принято у нас в компании при работе над проектами заказчиков — мы стараемся делать их так, чтобы внутреннее качество продукта (как написан код) не уступало внешнему (как отрабатывает функционал).
Многие зачастую уделяют внимание только второму — главное функционал, чтобы заказчик принял и заплатил. А после нас — хоть трава не расти — какая разница, кто и как будет поддерживать, или пытаться изменить этот код — пусть мучаются, мы же в свое время мучились с чужими макаронами.
Внутреннее качество важно не только из-за того, что мы гуманисты и думаем о том, кто этот код будет поддерживать. Еще мы честолюбивы и эгоистичны.
Итак, внутреннее качество нам обеспечивает:
- Понятность (что помогает легко выполнять bug fixing, быстрее и легче включаться в работу новым членам команды, легко поддерживать код)
- Уменьшение работы в перспективе (количество ошибок снижается, количество времени на разбор кода сокращается, облегчается поддержка кода)
- Адаптируемость (мы работаем по Agile, а это предполагает, что требования заказчиков меняются часто, и реагировать на изменения нужно быстро)
Как же это внутреннее качество контролировать? Подходов есть несколько. Мы применяем все.
1. Проводить code review
Причем review у нас проводят не тех лиды, а все члены команды. Здесь мы убиваем двух зайцев одним махом: проверяется качество кода, и знание кода распределяется между членами команды.
На что мы проверяем код во время code review? На соответствие стандартам, отсутствие антипаттернов (как в коде, так и в построении схемы БД), следование практик ООП/ООД, качество документации.
На проведение code review мы отдельно закладываем время, у нас есть специальный статус для задач (Open->In Progress->Ready for Code Review->In Review-> Ready for Testing...). Так что не сделать не выйдет.
2. Использовать сторонние инструменты контроля качества кода
Мы используем Sonar и для Java, и для .NET проектов. На что мы инспектируем код с помощью Sonar?
Покрытие кода юнит тестами (Code coverage). Да-да, мы пишем юнит тесты:
- Line Coverage — сколько строк кода выполнено и протестировано. Наша метрика, которую мы соблюдаем — 80%.
- Branch coverage — каждое ли условное выражение (true/false) было выполнено и протестировано. Аналогично — 80%. Более важный, чем line coverage, т.к. показывается реальную степень тестируемости бизнес-логики.
Комментарии (Comments):
- Документируемость API — следим, чтобы код содержал пояснения. Особенно важно для распределенных Agile проектов. Метрика — 80% публичных методов должны быть задокументированы.
- Следим, чтобы не было закомментированного кода — 0 строк.
Отсутствие связности внутри методов (LCOM4) — чем эта метрика больше, тем риск падения системы выше при изменении функционала. Особенно из-за тех мест, которые дают увеличение этой метрики (Sonar выдает усредненную).
Индикатор спутанности пакетов (Package tangle index) — количество циклический зависимостей между пакетами и общим числом зависимостей должно стремиться к 0.
Процент дублирования кода (Duplications) — отсутствие копипаста кода — должно стремиться к 0%
Цикломатическая сложность (Сomplexity) кода определяет сложность структуры кода: чем меньше вложенных операторов ветвления и циклов, тем лучше:
- На метод мы придерживаемся метрики — до 7. Больше — рефакторим.
- На класс — до 15.
- На файл — мы отключаем.
Также мы внимательны к замечаниям (violations), которые выдает Sonar — мы исправляем блокеры, критикалы и мажоры.
Sonar — настраиваемый инструмент, и есть еще множество метрик, которые можно собирать и анализировать. Иногда мы к ним прибегаем, но зачастую останавливаемся на вышеперечисленных стандартных.
Что влияет на возможность отслеживать внутренне качество?
- Грамотный CI. Не будет его — не будет возможности собирать метрики.
- Выстроенные процессы. Во время спринта разработчики отслеживают метрики на своих машинах, проводят code review В конце спринта, на ретроспективе, метрики — один из обязательных предметов обсуждения, если что-то осталось не так — закладываем задачу на коррекцию на след спринт.
Подводим итоги. Писать код качественно абсолютно не сложно. Через пару итераций те штуки, за которыми раньше разработчики следили, становятся естественными (вырабатывается внутренняя культура). Надо только правильно настроить процесс. Не утаю, что вначале это будет отнимать лишнее время. Но вскоре все окупится с торицей.
В следующей заметке попробую немного приоткрыть тайну KPI, CSF и еще нескольких аббревиатур, которые так любят заказчики и топ менеджмент.
На заметку: Если вам необходим выгодный кредит под недвижимость, то в таком случае рекомендуем вам обратиться по данному вопросу в компанию kreditor77.ru.
