Как измерить код? (часть 1)

Почти все из тех кто так или иначе имеет отношение к разработке ПО слышали про метрики: количество строк кода, цикломатическая сложность, плотность ошибок и т.п. Меньше тех, кто пробовал измерить свой проект какой-нибудь утилитой. И ещё меньше тех, кто смог извлечь из этого хоть какую-то пользу. Действительно, узнать сколько в твоей программе строк кода или классов может и любопытно, но какой от этого толк?

Метрики и то чем их можно посчитать

Утилиты предназначенные для подсчёта метрик можно условно поделить на три группы. К первой относятся те, что выполняют статический анализ исходного кода. При этом не важно синтаксический ли это разбор (CCCC) или использование мета-данных (ndepend). Таким способом можно узнать, сколько строк кода в вашем проекте, классов, методов и т.п. Контроль объектно-ориентированных метрик в умелых руках может принести весьма ощутимую пользу, т.к. позволяет выявить код нуждающийся в рефакторинге.
Ко второй группе можно отнести утилиты выполняющие анализ информации содержащейся в системах контроля версий (SvnStat, GitStats). Такие утилиты анализируют логи систем контроля версий и позволяют получить много любопытной информации, в основном об активности коммитеров. Это тоже может оказаться полезным, если вы хотите следить за тем, кто и когда работает, точнее коммитит.
И к третьей группе можно отнести всякую экзотику позволяющую, например, оценить такие вещи как «стоимость» и «затраты» внесения изменений или помочь с планированием дальнейшей проектной активности COCOMO. Подобные вещи как правило представляют академический интерес и не находят широкого применения на практике.

Путь MSR Tools

MSR Tools — нечто среднее между представителями всех трёх вышеупомянутых групп. MSR Tools позволяет выполнять расчёт метрик для «довольно произвольных» множеств кода. Метрик как таковых немного: количество строк кода, плотность ошибок и… пока всё! Но как было сказано выше, то самое множество кода, для которого считается метрика может быть задано различными условиями. Ну например, взявшись за отдельного разработчика можно узнать сколько кода он добавил, сколько удалил, сколько его кода осталось на текущий момент, какова плотность ошибок его кода, сколько кода он удалил за прошлый год из того кода что был добавлен за позапрошлый год… и т.д. Таким образом, хвала комбинаторике, можно получить тысячи метрик. Разумеется не все они одинаково полезны интересны. Но многие действительно представляют интерес и могут дать понимание того, что происходит с проектом. Конечно главная задача, для которой MSR Tools и создан — это подсчёт плотностей ошибок для различных множеств кода, таких как код отдельного программиста, код в файле, код в подсистеме и т.п. Контроль таких метрик позволит свести к минимуму вероятность ситуации, когда «вдруг» окажется, что «ваш софт — *овно».

Всё это здорово, но надо помнить, что MSR Tools всего лишь инструмент и чтобы им воспользоваться необходимо выполнение ряда условий. Вот эти условия:

  • Вы используете систему контроля версий. Построение истории изменений возможно посредством анализа информации из системы контроля версий, поэтому если Вы её не используете, то MSR Tools ничем не сможет Вам помочь.
  • Вы используете систему контроля версий правильно. Тут наверно всё ясно. Если работая в команде Вы редактирует код в одной папке и раз в неделю делаете коммит, то это неправильно. А вообще на эту тему много уже написано. Гуглите и Вам нагуглится!
  • Вы вносите исправления в виде отдельных коммитов. Одна ошибка — один коммит, исправляющий эту ошибку и не вносящий других изменений. При этом в логе вы пишете комментарий, по которому можно понять, что этот коммит исправляет ошибку.

Требования вполне выполнимые. Неписанные, но интуитивно очевидные. Практически любой сколь либо серьёзный проект с открытым исходным кодом этим требованиям удовлетворяет. Коммерческий проект, в котором по идее дисциплины должно быть больше, тем более должен им удовлетворять. Первое требование обязательное. От степени выполнения двух других будет зависеть количество и точность метрик, которые Вы сможете получить.

Как это работает

MSR Tools включает в себя набор из нескольких утилит. Прежде всего, Mapper — утилита, которая осуществляет импорт информации из системы контроля версий в реляционную базу данных. Делается это посредством парсинга log’ов, diff’ов, и blame’ов для всех коммитов. Или не для всех. Формируется база данных, хранящая в упрощённом виде историю об эволюции проекта. Как только база сформирована, можно не стесняясь заSQLить её до смерти. И тут может пригодиться помощь двух других утилит. StatGenerator — генератор статистики в html позволяет в удобном виде посмотреть основные метрики. Visualizator — предназначен для построения графиков. Следует отметить, что генератор и визуализатор расширяемы и можно добавить собственную страницу в отчёт или визуализацию без пересборки основных компонентов. Для этого придётся немного подредактировать файл настроек, который по совместительству является ни чем иным как файлом конфигурации контейнера unity.

На этом пока всё. В следующий раз я расскажу как же заставить MSR Tools посчитать метрики для Вашего проекта.