Анализ метрик кода на примере NHibernate

Сегодняшний герой дня — NHibernate. Довольно популярный ORM для платформы .NET. Метрики подсчитанные для этого проекта можно найти здесь.

Общая статистика

На странице общей статистики даётся следующая информация:

  • Generation date — дата генерации отчёта;
  • Statistics period — период времени охватываемый статистикой;
  • Number of authors — количество разработчиков;
  • Number of commits — количество коммитов;
  • Number of fix commits — количество коммитов исправляющих ошибки;
  • Number of refactoring commits — количество коммитов-рефакторингов;
  • Number of files — количество файлов текущее/всего добавлено/всего удалено;
  • Number of LOC — количество строк кода текущее/всего добавлено/всего удалено;
  • Traditional defect density — традиционная плотность ошибок, та про которую все знают и к которой все привыкли. Рассчитывается как количество дефектов на 1000 строк кода;
  • Defect density — альтернативная плотность ошибок, рассчитывается как количество дефектов на 1000 строк добавленного кода.

В чём принципиальная разница между традиционной и альтернативной плотностью ошибок и почему нельзя обойтись одной я расскажу в другой раз, а пока можно отметить, что все метрики плотности ошибок для файлов и авторов рассчитаны альтернативным способом.

Для NHibernate традиционная плотность ошибок составляет 2,058, Что означает, примерно 2 дефекта на 1000 строк кода. Это является хорошим показателем.

Авторы

Таблица статистики по авторам содержит следующие колонки:

  • Author — логин разработчика в системе контроля версий;
  • Commits — число коммитов автора и их процент от общего числа коммитов;
  • Fix commits — число исправлений автора и их процент от числа коммитов автора;
  • Refactoring commits — число рефакторингов автора и их процент от числа коммитов автора;
  • Defect density — плотность ошибок для кода автора;
  • Added/Removed/Current LOC — количество строк кода добавленных, удалённых и имеющихся в коде на данный момент;
  • Contribution — метрика определяющая какой процент из кода имеющегося на данный момент принадлежит автору;
  • Specialization — метрика определяющая процент файлов от их общего текущего числа, над которыми работал автор;
  • Unique Specialization — метрика определяющая процент файлов от их общего текущего числа, над которыми работал только автор и никто кроме него.

Метрики по отдельным разработчикам. Вот где есть неиссякаемая почва для поиска козлов отпущения… Контролируйте себя!

Для NHibernate, как можно видеть, не имеет место какое-то разделение труда в плане исправления ошибок и рефакторинга. Наиболее активные разработчики занимаются этими видами деятельности с примерно одинаковой интенсивностью. Можно отметить лишь разработчика с логином crowdozer. Три четверти его активности — это рефакторинг. При этом исправлением ошибок он не занимается совсем, при том что плотность ошибок его кода не самая низкая, т.е. человек не утруждает себя исправлять даже собственные ошибки. Таким же образом поступает tjb300. А вот justme84 и fabiomaulo при собственных небольших плотностях ошибок явно исправляют ошибки за других. Подобная ситуация для open-source проекта вполне нормальна. Контрибьюторы помогают по мере сил и компетенции, а лидеры за ними подчищают. В коммерческих же проектах подобная ситуация нежелательна и опасна, хотя и может быть приемлемой в отношении стажёров, студентов и просто новичков если таковые имеются.

Для разработчиков чей вклад в кодовую базу значителен, плотность ошибок невысока и составляет примерно 1-2 дефекта на 1000 строк. Хороший показатель. Выделяется только разработчик mthird, чей код имеет плотность ошибок 16 дефектов на 1000 строк, что значительно выше средних показателей по проекту. Возможно лидерам стоило бы пересмотреть целесообразность участия этого товарища или по крайней мере внимательней изучать его патчи.

В костяк разработчиков можно отнести 6 человек: fabiomaulo, justme84, steverstrong, mikedoerfler, ayenderahien, RicBrown. Для каждого из них вклад в кодовую базу больше 1 %. Среди них выделяется главный лидер проекта — fabiomaulo. Он работал над 64 % всех файлов, а над третью всех файлов кроме него не работал никто. Также следует особо отметить следующих авторов: tehlike, darioquintana, davybrion. Их вклад в кодовую базу незначителен, но значительная часть их работы — это работа над файлами, над которыми не работает никто кроме них. Можно сделать вывод, что они занимаются поддержкой каких-то подсистем, которые либо не интересны всем прочим, либо прочие в них хуже разбираются. Интересно, что разработчик mikedoerfler при значительном вкладе в кодовую базу совсем не занимается какой-то уникальной работой.

Грамотный анализ метрик Defect density, Contribution, Specialization и Unique Specialization может помочь объективно выбрать кандидатов на увольнение например или на выдачу премии или чего ещё…

Файлы

На странице статистики по файлам есть две таблицы. Первая отражает статистику по расширению файлов и содержит следующие колонки:

  • Extension — расширение файла;
  • Number of files — количество файлов с соответствующим расширением;
  • Defect density — плотность ошибок для кода в файлах;
  • Added/Removed/Current LOC — количество строк кода добавленных, удалённых и имеющихся в коде на данный момент.

Вторая таблица содержит статистику по каталогам, которые обычно соответствуют пространствам имён и подсистемам. Она содержит следующие колонки:

  • Directory — путь к каталогу;
  • Number of files — количество файлов в каталоге включая подкаталоги;
  • Defect density — плотность ошибок для кода в каталоге;
  • Added/Removed/Current LOC — количество строк кода добавленных, удалённых и имеющихся в коде на данный момент.

Для NHibernate в настройках мэппинга была указана выборка по расширению *.cs, поэтому файлы с другим расширением в статистику не вошли. Можно отметить, что из наиболее объёмных  каталогов наибольшей плотность ошибок обладают следующие:

  • /trunk/nhibernate/src/NHibernate/Impl
  • /trunk/nhibernate/src/NHibernate/Type
  • /trunk/nhibernate/src/NHibernate/Engine
  • /trunk/nhibernate/src/NHibernate/Dialect
  • /trunk/nhibernate/src/NHibernate/Mapping
  • /trunk/nhibernate/src/NHibernate/Loader
  • /trunk/nhibernate/src/NHibernate/Util

Это говорит о том, что сложность кода в этих каталогах больше чем в тех, для которых плотность ошибок меньше. При необходимости такая статистика может быть детализирована вплоть до отдельных файлов. Её анализ может указать на проблемные файлы, которые нуждаются в рефакторинге или на которых следует сосредоточить больше усилий при тестировании в преддверии очередного релиза.

2 комментария: Анализ метрик кода на примере NHibernate

  1. Евгений говорит:

    Не понятно почему количество строк Added минус Removed не всегда равно Current?

    • Semyon Kirnosenko говорит:

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