Статистика работы программиста

Иногда надо оценить проделанную работу разработчика. Как правило для этого чаще всего считают количество строк кода ( Source Lines of Code — SLOC), но также бывает считают количество классов функций, комментариев. Я не хочу писать о разных методиках расчёта цены программного продукта, а скорее хочу сделать небольшой обзор утилит для подсчёта статистических параметров.
Если надо посчитать просто количество строк в файле то вполне может хватить wc (надеюсь у вас не возникло асоциаций с туалетом).
$ cat file_name | wc -l
Так можно и пройти по дереву каталогов и подсчитать количества строк в куче файлов, но этот метод посчитает также и пустые строки. Есть много плагинов к IDE которые могут посчитать количество строк кода, нарисовать крутую диаграмму но как правило подобные плагинны рассчитаны только на Java, C#, C++ и всё. Да и многие из них платные, закрытые программы.
Первая программа о которой я хотел-бы написать это SLOCCount. Она достаточна старая, и поддерживает не большое число языков, но зато она написана на Си и достаточно быстрая. Если вы уже посмотрели список языков которые она поддерживает и решили что про «небольшое» я соврал так вы просто не видели пока других :) . Список поддерживаемых языков программирования можно найти на сайте проекта. Она также по количеству строк кода пытается оценить цену программы, но если честно мне это не понравилось (нет не потому что она сказала что мой код дешёвый :) ).
Применил я эту программу к исходникам фреймворка django, работала она 2.1 секунды, что достаточно быстро. Получил вот такой результат:

$ sloccount ./
Creating filelist for bin
Creating filelist for conf
Creating filelist for contrib
Creating filelist for core
Creating filelist for db
Creating filelist for dispatch
Creating filelist for forms
Creating filelist for http
Have a non-directory at the top, so creating directory top_dir
Adding /usr/lib/python2.7/site-packages/django/.//__init__.py to top_dir
Adding /usr/lib/python2.7/site-packages/django/.//__init__.pyc to top_dir
Adding /usr/lib/python2.7/site-packages/django/.//__init__.pyo to top_dir
Creating filelist for middleware
Creating filelist for shortcuts
Creating filelist for template
Creating filelist for templatetags
Creating filelist for test
Creating filelist for utils
Creating filelist for views
Categorizing files.
Finding a working MD5 command....
Found a working MD5 command.
Computing results.


SLOC	Directory	SLOC-by-Language (Sorted)
34006   contrib         python=34006
10746   db              python=10746
7270    utils           python=7270
6716    core            python=6716
2989    template        python=2989
2935    test            python=2935
2920    views           python=2920
2712    forms           python=2712
2068    conf            python=2068
943     http            python=943
533     templatetags    python=533
423     middleware      python=423
204     dispatch        python=204
60      shortcuts       python=60
54      bin             python=54
18      top_dir         python=18


Totals grouped by language (dominant language first):
python:       74597 (100.00%)




Total Physical Source Lines of Code (SLOC)                = 74,597
Development Effort Estimate, Person-Years (Person-Months) = 18.51 (222.11)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.62 (19.48)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 11.40
Total Estimated Cost to Develop                           = $ 2,500,340
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."


Если честно мне такой вывод кажется немного перегруженным и запутанным, и ориентироваться не очень удобно. Она 74 тысячи строк кода django оценила в 2,500,340 долларов, что получается по 34$ за строку кода :) . После этого гуглил цену строки кода, и примерно нашёл что в среднем одна строка кода стоит 12-18$. Но работа разработчика это не только написание кода: но и отладка, и тд.

Ладно что-то я отошёл от темы.
Теперь давай рассмотрим другую программу. Мне она среди других понравилась больше всего. Она называется cloc, написана на perl. Количество языков которые она поддерживает просто впечатляет, но она работает не так быстро как предыдущая. Подсчёт количества строк в django работал ощутимо дольше, а именно 14 секунд. Вывод как мне кажется намного информативнее и удобнее.

$ cloc ./
    2081 text files.
    2072 unique files.                                          
    1324 files ignored.

http://cloc.sourceforge.net v 1.56  T=15.0 s (62.6 files/s, 8718.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                         804          16559          26666          74131
Javascript                      26           1261           1098           6174
HTML                            95            341             16           2019
CSS                              8            495             69           1875
XML                              6              0              2             68
-------------------------------------------------------------------------------
SUM:                           939          18656          27851          84267
-------------------------------------------------------------------------------

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

Теперь перейдём к пожалую самой навороченной программе в моём обзоре. Sonar которая написана на Java. Для того что-бы вы оценили количество фитч проги скажу что её бинарная сборка весит 52 мегабайта. Её также можно поставить как плагин к Eclipse IDE, вот пару скринкастов. Sonar это как-бы не просто считалка числа строк кода, а система оценки и анализа кода. Вот демо её веб интерфейса. Кстати количество языков которые она поддерживает увы не большое, зато она может считать очень много разной статистики, хотя мне лично такого количества фитч не надо, она скорее подойдёт очень большой софтверной компании (или тем кто очень увлекается всякой статистикой) :) . При небольшой команде или проекте её интерфейс просто кажется нереально перегруженным.

Ещё одна программа которая мне понравилась это ohcount. Она состоит из библиотеки и программы, так что её можно легко использовать в своих программах без необходимости парсить вывод, есть также модули для python и ruby. Программа точно не поддерживает Windows об этом написано в Readme (хотя на их месте я не был бы на столь категоричным, под cygwin вполне может собраться, потом может попробую). Сама программа разрабатывалась для известного сервиса ohloh. Ещё одно предупреждение, если будете собирать прямо из git репы, то при тестах сборка падает. Утила вроде как работает не плохо, но стабильные ветки проходят тесты, так что лучше собирать стабильную ветку. Она написана на Си и работает достаточно быстро. Ещё у неё есть одна интересная фитча, она может определять лицензии кода, если сама лицензия где-то указанна в файле. Хотя как я понял это работает просто по поиску подстроки, например если я где-то в файле напишу GPL, то оно может защитать файл как под лицензией GPL. Вот результат её работы для исходников django:

 $ ohcount /usr/lib/python2.7/site-packages/django
Examining 5445 file(s)

                          Ohloh Line Count Summary                          

Language          Files       Code    Comment  Comment %      Blank      Total
----------------  -----  ---------  ---------  ---------  ---------  ---------
python              809      74324      26604      26.4%      16567     117495
javascript           33       6494        990      13.2%       1271       8755
css                  12       1943         76       3.8%        495       2514
html                 96       1739         10       0.6%        331       2080
xml                   7         74          2       2.6%          0         76
----------------  -----  ---------  ---------  ---------  ---------  ---------
Total               957      84574      27682      24.7%      18664     130920

На подсчёт строк в Django она потратила 6 секунд.
А вот результат поиска лицензий:

$ ohcount -l /usr/lib/python2.7/site-packages/django
apache_2 ipv6.py
python_software_foundation baseconv.py
gpl jquery.js
gpl jquery.min.js
bsd inlines.js
bsd test_mutable_list.py
bsd test_geos_mutation.py
bsd mutable_list.py
gpl __init__.py

Кстати поиск лицензий работает быстрее.
Но детектор лицензий порой ошибаться, у меня на одном файле как раз произошёл подобный случай.

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

На этом я пожалуй закончу обзор утил для подсчёта строк кода, но помимо количества строк кода всего проекта можно посмотреть количество комитов и тд.
Например в Git можно посмотреть число комитов сделанных каждым автором такой командой:
$ git shortlog -s
Также для статистики можно использовать команды типа такой:
$ git log --numstat
Вместо numstat также можно использовать dirstat, stat и тд. что они делаю лучше прочитайте в доке.
Также для более продвинутой статистике для гита написаны некоторые другие утилы, такие как git-loc и gitstats. Мне лично больше всего понравился gitstats, если интересно посмотрите например этот пример.

Для статистики в Mercurial можно использовать такую команду:
$ hg log --template "{author|person}\n" | sort | uniq -c | sort -nr — что выдаст число комитов по авторам, также можно поставить плагин Churn (что намного лучше, кстати сейчас он поставляется вместе с Mercurial так что его надо только включить)
$ hg churn -c
Также он может делать кое что что не может делать git (но может gitstats), а именно считать число добавленных и удалённых строк по автору.
$ hg churn --diffstat

У этого плагина хорошая дока на русском:

 $ hg churn --help
hg churn [-d ДАТА] [-r РЕВ] [--aliases ФАЙЛ] [ФАЙЛ]

гистограмма изменений, внесенных в хранилище

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

    Статистика основана на количестве изменённых строк, либо числе
    соответствующих ревизий, если задана опция --changesets.

    Примеры:

      # отобразить число изменённых строк для каждого автора
      hg churn -t '{author|email}'

      # отобразить график ежедневной активности
      hg churn -f '%H' -s -c

      # отобразить активность разработчиков помесячно
      hg churn -f '%Y-%m' -s -c

      # отобразить число изменённых строк за каждый год
      hg churn -f '%Y' -s

    Можно заменить почтовые адреса на любые другие, задав файл следующего
    формата:

      <псевдоним адреса> = <настоящий адрес>

    Такой файл может быть задан опцией --aliases, иначе поиск файла .hgchurn
    происходит в корне рабочего каталога.

параметры:

 -r --rev РЕВИЗИЯ [+]    рассчитывать статистику для заданной ревизии или
                         диапазона
 -d --date ДАТА          рассчитывать статистику для ревизий, соответствующих
                         заданному шаблону
 -t --template ШАБЛОН    шаблон для группировки изменений (по умолчанию:
                         {author|email})
 -f --dateformat ФОРМАТ  strftime-совместимый формат для группирования по дате
 -c --changesets         считать количество наборов изменений
 -s --sort               отсортировать по ключу (по умолчанию: сортировать по
                         количеству)
    --diffstat           отобразить добавленные/удалённые строки отдельно
    --aliases ФАЙЛ       файл с псевдонимами почтовых адресов
 -I --include ШАБЛОН [+] добавить файлы, имена которых соответствуют данным
                         шаблонам
 -X --exclude ШАБЛОН [+] не добавлять файлы, имена которых соответствуют
                         данным шаблонам
    --mq                 работать с хранилищем патчей mq

параметры, помеченные [+], могут указываться многократно

используйте "hg -v help churn" для дополнительной информации

Статистику по комитам можно посмотреть так:
$ hg diff -r 0 -r tip --stat

Из интересного ещё есть hg activity и hg chart.

С свн немного обстановка хуже, так как из коробки никакой статистики нету, разве что количество изменённых строк кода к комите :) . Но зато дату о комитах можно перекинуть в xml, или можно юзать statsvn, вот пример. Есть также mpy-svn-statsвот так выглядит его результат, другой svnstats и svnplot.

Из универсальных утил есть code_swarm который по дате из данных о комитах сделает небольшое кино :) . Там на сайте есть список поддерживаемых VCS.
Есть также чей-то проект MSR Tools который поддерживает svn и git но он только под Windows. Вот его результат для Django
На этом пока всё.

Запись опубликована в рубрике Tips & trics, Utils, Заметки, Программирование с метками , , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>