Программа Programeter на основе анализа исходников проекта в репозитории позволяет оценить/измерить такие характеристики работы каждого программиста:
- уровень знакомства программиста со всей базой исходников;
- количество нового, привнесённого этим программистом кода в репозиторий;
- уровень “выживаемости” кода программиста;
- размер общего вклада программиста в репозиторий;
- уровень активности в течение одного месяца;
- ориентированность на сотрудничество с другими программистами;
- среднюю сложность написанного кода;
- соотношение объёма написанных комментариев к объёму написанного кода.
По-моему, фуфло полнейшее. Если в вашей организации пытаются внедрить что-то похожее и принимать какие-то кадровые/зарплатные решения на основе таких вот данных: смело меняйте работу, если не хотите страдать от приступов маразма менеджмента.
Почему менеджмент, принимающий решения на основе таких показателей маразматичен?
Потому что все эти циферки накручиваются, с разной степенью лёгкости.
Например, повысить уровень “сотрудничества с другими программистами” можно так: договориться группой в курилке о том, что как только у кого-то возникает потребность в новой “библиотечной” функции, он сообщает об этом коллегам и кто-то (кому нужно поднять уровень сильнее всего) создаёт эту функцию.
Сложность кода накручивается тоже очень легко; искусственное завышение размера общего вклада также не вызывает особых проблем у опытного программиста.
А накручивать обязательно будут, если накрутка приносит какую-то выгоду (повышение или непонижение з/п, например). Вот выдержки из реальной истории о том, как в одной конторе начали оценивать работу программистов по количеству коммитов в неделю (в переводе Сергея Можайского):
“С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%.
Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов.”
Хорошо, если накрутчики будут просто не ухудшать код своими накрутками, а если начнут ухудшать? Выгребать и фиксить будет вся команда, а не только накручивающие.
В общем, если в вашем проекте решения о уровне полезности программистов принимаются не на основе мнения ведущего программиста, а на основе таких вот “показателей надоев”, то дело плохо.
я советую попробовать
без пробы сложно оценить все прелести продукта
Comment by Марк — 08.07.2008 @ 08:17
Марк, ну я не представляю ситуации, когда результаты, полученные вашей программой, можно использовать для каких-либо целей, отличных от развлекательных.
Если на их основе принимаются какие-то решения, то люди начнут читить, чтобы не попасть под санкции — это неизбежно.
Вот пример того, как можно повысить уровень “сотрудничества с другими программистами”: договориться группой в курилке о том, что как только у кого-то возникает потребность в новой “библиотечной” функции, он сообщает об этом коллегам и кто-то (кому нужно поднять уровень сильнее всего) создаёт эту функцию.
Не могу найти WTF-ссылку на организацию, где производительность сотрудников оценивалась по количеству сделанных ими коммитов. Но понятно, к чему это привело, да?
Ваши параметры чуть сложнее, но тоже накручиваются, особенно при взаимодействии программистов.
А причина простая: репозиторий, по исходникам из которого ваша программа выставит максимальные оценки программистам, совершенно не обязатально будет содержать что-то стоящее.
Comment by Val Petruchek — 08.07.2008 @ 09:13
Похоже, имелась в виду вот эта статья:
thedailywtf.com/Articles/Productivity-20.aspx
“С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%”
“Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов”
Comment by Sergei Mozhaisky — 08.07.2008 @ 18:16
Вы по-большому правы.
Но, к счастью, на моей работе начальство не знает такого понятия, как “репозиторий” и смутно догадывается что есть некий “код”.
Comment by Kopwyh — 08.07.2008 @ 20:56
Сергей: я твой коммент внёс в тело заметки, спасибо! (я делал поиск “commit” по ридеру, а надо было искать “checking”)
Корвин: есть мнение, что source control надо использовать даже в случае проектов из одного разработчика. Дисциплинирует и облегчает работу.
Comment by Val Petruchek — 08.07.2008 @ 21:22
Kopwyh - на самом деле Вам крупно повезло с начальством:)))
Comment by Видим — 15.07.2008 @ 23:15