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

В прошлый раз я коротко написал о том, чем и какие метрики можно измерить, а также что в этом плане может предложить MSR Tools. Сегодня речь пойдёт непосредственно о расчёте метрик для ВАШЕГО проекта. В сокращённом виде нижеследующее можно найти здесь.

Убедитесь, что установлены .NET Framework 3.5, SQL Server Express и клиент с интерфейсом командной строки для системы контроля версий, которую Вы используете. На данный момент это могут быть Subversion или Git. Репозиторий кода лучше иметь в виде локальной копии, иначе мэппинг затянется надолго. В случае Git надо помнить, что не-fast-forward слияния пока не поддерживаются и мэппинг коммитов из веток слитых таким образом с высокой долей вероятности может прерваться ошибкой.

Все утилиты MSR Tools настраиваются посредством изменения файла конфигурации для контейнера Unity. Для каждого проекта Вам понадобится отдельный такой файл. Самый простой способ его получить — взять готовый файл конфигурации здесь для Subversion или здесь для Git. Далее в полученный файл нужно внести изменения. Во-первых укажите имя базы данных, в которой будет храниться история.

<param name=”connectionString”>
<value value=”Data Source=.\SQLEXPRESS;Integrated Security=true;Database=gnome-terminal;” />
</param>

Укажите путь к репозиторию кода.

<param name=»repositoryPath»>
<value value=»file:///E:/repo/gnome-terminal/svn» />
</param>

Из репозитория в базу данных будет в дальнейшем выполнен мэппинг истории изменений. Вы можете указать в настройках история изменения каких файлов будет сохранена при мэппинге. Для этого существуют три фильтра: SkipPathByDirectory, SkipPathByExtension and TakePathByExtension. Предназначены для игнорирования папок по имени, игнорирования файлов по расширению и выборки файлов по расширению соответственно. Если Вы хотите сохранить всё что только есть в репозитории — просто убедитесь что список используемых фильтров пуст.

<param name=»pathSelectors»>
<array>
</array>
</param>

Или же Вы можете использовать выборку файлов с исходным кодом, например, по расширению.

<register type=»TakePathByExtension» mapTo=»TakePathByExtension» >
<constructor>
<param name=»extensionsToTake»>
<array>
<value value=».py» />
<value value=».js» />
</array>
</param>
</constructor>
</register>

И не забывайте добавлять используемый фильтр в список фильтров.

<param name=»pathSelectors»>
<array>
<dependency type=»TakePathByExtension» />
</array>
</param>

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

Чтобы посчитать плотность ошибок всего кода, достаточно знать общее число исправленных ошибок и объём кода. Чтобы посчитать плотность ошибок некоторого подмножества кода, необходимо уметь определять какой код содержит ошибку. Для этого в MSR Tools используется техника поиска ошибочных изменений (bug-introducing changes). При этом факт наличия ошибки устанавливается по наличию коммита эту ошибку исправляющего. Остаётся найти исправляющие коммиты. Пока реализован только вариант классификации по наличию ключевых слов в тексте комментария к коммиту. По умолчанию используются ключевые слова на английском. Если в Вашем проекте комментарии к коммитам пишут на другом языке — укажите какие ключевые слова необходимо использовать.

<register type=»IBugFixDetector» mapTo=»BugFixDetectorBasedOnLogMessage» >
<property name=»KeyWords»>
<value value=»fix fixes bug bugs bugfix bugfixes fixed» />
</property>
<property name=»StopWords»>
<value value=»warning typo» />
</property>
</register>

Файл настроек следует сохранить под именем, например, MyProject.config. Теперь можно выполнить мэппинг скажем первых десяти ревизий.

MSR.Tools.Mapper.exe MyProject.config map -c -n 10

Опция «-c» используется при первом запуске мэппинга для создания базы данных. Также её можно использовать для стирания уже имеющейся базы данных. После первого запуска мэппинг можно продолжать использовать без опции «-с» инкрементно. Можно выполнить мэппинг ещё десяти ревизий.

MSR.Tools.Mapper.exe MyProject.config map -n 20

При этом указывается сколько ревизий Вы хотите видеть в базе данных. Вместо номера можно использовать непосредственно идентификатор ревизии.

MSR.Tools.Mapper.exe MyProject.config map -c -r 20

Для Subverion это будет тот же номер, а для Git — хэш коммита (все 40 символов).

После того как база сформирована, можно наконец получить нечто более интересное. Например статистику в html.

MSR.Tools.StatGenerator.exe MyProject.config stat

Также можно воспользоваться визуализатором, чтобы построить для проекта какие-нибудь «кривые». Для этого нужно запустить файл MSR.Tools.Visualizer.WinForms.exe и открыть Ваш файл настроек через меню.