Сбор метрик из SVN

26 ноября 2009 г.

Что это?

Суть в том, чтобы из хранилища кода SVN собрать историю работы над проектом. В эту историю могут входить количество строк кода, время комитов, активность авторов комитов и т.д.

Зачем?

Вообще я не любитель собирать такие метрики, но меня заинтересовало наблюдение Сергея Архипенкова. Я говорю о принципе цикличности при становлении команды.

Сергей заметил, что графики количества строк кода и фаз становления команды выглядят очень похоже. Дело в том, что сначала команда собирается и происходит разработка основных компонентов (формирование команды). В этот период пишется «скелет» системы, кода мало. Потом команду «штормит» и все приходит в норму. Здесь пишется основной код. И, наконец, команда выходит на максимальный уровень производительности. А вот тут уже все написано, остается только рефакторить и исправлять ошибки. Это то самое место, когда количество строчек кода уменьшается.

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

Сразу надо сказать, что сбор метрик я точно не буду применять для:

  1. вычисления производительности отдельных программистов
  2. привязки премий, зарплат и т.п. к этим метрикам

Какие решения нашел?

StatSVN

Сайт – http://www.statsvn.org

Работает в два этапа:

  1. нужно самим выгрузить лог SVN за интересующий период времени
  2. запустить формирование отчета с помощью этой утилиты

Отчеты формирует довольно симпатичные, но работает очень долго. Отчет для 6000 ревизий занял где-то 1,5 часа и напрочь повесил компьютер.

SVNPlot

Сайт – http://code.google.com/p/svnplot

Работает тоже в два этапа, но по другому принципу:

  1. создает базу данных sqlite из хранилища SVN
  2. формирует отчет с помощью запросов к базе данных

Работает на порядок быстрее, чем StatSVN.

Из недостатков можно отметить, что для ее работы надо установить много разных программ: python 2.6, sqlite3, pysvn, NumPy, Matplotlib

Сразу заметил

1. Зависимость возрастания строчек кода от времени в нашем проекте оказалась линейной (интересно, где предел?).

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

Дополнение

Если увеличить масштаб графика, то получим довольно занятную картинку:

Зеленые стрелочки отмечают вершины графика или то место, где график практически ровный. Оказалось, что эти стрелочки отмечены на расстоянии одной итерации (одна неделя). Это и логично, потому что после каждой итерации разработчики некоторое время тратят на рефакторинг и исправление ошибок. Отсюда вывод, что цикличность все-таки есть.

2. Саня комитит по ночам!

А как же 40-часовая рабочая неделя? ;)

В остальных метриках пока никакого толку не увидел. Например, есть довольно забавные графики активности:

Он что-то значит? Может быть первый программист больше рефакторит, чем последний? Нет, конечно. Все работают в парах и комиты могут делать с разных компьютеров. Можно только примерно сказать, что код в основном изменяется, а не добавляется новый. Опять же, это что-то значит?

Буду смотреть дальше, может какие закономерности под руку попадутся :)


Ссылки

Метрики кода

17 комментариев:

  1. Ну вообще, мне кажется у тебя правильный график получился. Даже если выделять время на рефакторинг и заниматься чисто им, то спада графика не будет, ты же не код половины проекта убиваешь, будет маленький спадик.
    Ну а твой график ты логично объяснил - при постоянном рефакторинге оно так и будет.
    Вообще, интересно, пиши свои наблюдения на эту тему еще. Интересно посмотреть что получится. :)

    ОтветитьУдалить
  2. Александр, привет!

    Интересный график. Слушай, а у вас есть итерации? Если есть, то на графике должны быть "полки" в то время, когда идет очередной раунд тестирования, исправляются баги и код практически не растет.

    Сергей Архипенков.

    ОтветитьУдалить
  3. Да, итерации есть.
    Первую половину графика они были по 2 недели, а сейчас идут по одной.

    Я бы не сказал, что мы натыкались на такие мощные исправления, когда код вообще перестает прибавляться. Опять же может потому, что мы пишем сначала тесты, т.е. используем TDD в чистом виде. Да, ошибки конечно вылезают, но их практически всегда было довольно легко локализовать и соответственно исправить.

    Опять же у меня пока одни гипотезы, никаких экспериментов в доказательство или опровержение не имеется =)

    ОтветитьУдалить
  4. Привет, Саша!

    Ты не мог бы пояснить что происходит с командой/проектом в точке на графике, где кривая резко идет вниз? Если я правильно понимаю график, то он говорит о том, что, если вовремя не поменять состав команды, она уйдет в стадию стагнации. Неужели это так?

    ОтветитьУдалить
  5. @Dmitry

    Зная сколько усилий надо приложить, чтобы команду сформировать, я бы не стал менять ее состав. Скорее надо поменять цели проекта, попробовать достать до новых вершин или сменить сам проект.

    Я думаю это вопрос скорее к Сергею Архипенкову =) Сергей, может прокомментируете?

    ОтветитьУдалить
  6. Еще про масштаб. Это график практически годовых изменений. Т.е. если посмотреть, то там можно увидеть периоды падений или, как минимум, остановок.

    ОтветитьУдалить
  7. 2Dmitry

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

    Постоянный мониторинг и оценка эффективности всех процессов, используемых в проекте. «Что лишнее мы делаем?» «Что можно делать проще?» «Что угрожает проекту?». Сокращение ненужных усилий вместо «стремления к новым победам».

    Определение узких мест и применение корректирующих действий там, где процессы начинают буксовать или риски слишком велики.

    Ну, и естественно, если мы изменяем внутренние процессы в команде, то производительность сначала падает, потому что по-старому работать нельзя, а по-новому пока не научились.

    Разумеется, делать это следует, после сдачи очередного релиза программного продукта, ну и, возможно, в случае глубокого кризиса проекта.

    Где-то так.
    АС.

    ОтветитьУдалить
  8. @Sergey

    Спасибо за комментарий.

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

    ОтветитьУдалить
  9. @Sergey
    Спасибо за комментарий.

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

    ОтветитьУдалить
  10. @Dmitry

    Я думаю, что на максимальной продуктивности продукт докручивается, допиливается. Т.е. происходит качественный скачек, а не количественный.

    Интересно, можно как-то качество проекта измерять? Хотя бы в попугаях =) В голову приходят метрики FxCop и NDepend, но они не всегда являются 100% индикатором качества. Может есть какие-то идеи на этот счет?

    ОтветитьУдалить
  11. Хочу уточнить.
    Я говорил о _качественном_ подобии графиков, а не о прямой корреляции. Итерация может длится одну неделю, а цикл у команды может быть полгода.
    АС.

    ОтветитьУдалить
  12. @Sergey

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

    ОтветитьУдалить
  13. @Александр

    Приведенная диаграмма и правда не самый показательный пример для подтверждения наблюдения Сергея. Может быть, дело в методологии?

    ОтветитьУдалить
  14. @Dmitry

    Как я уже говорил, гадать не буду =)

    ОтветитьУдалить
  15. Svnplot под линуксом работает только в иксах, или не пробовали?

    ОтветитьУдалить
  16. Спасибо, интересно :) Надо будет с нашей CVS такое же сделать, посмотреть :)

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...