На протяжении всей карьеры этот вопрос часто поднимался, но, как понятно из его частоты, действительно хорошего ответа на него нет.
Есть метрики по коду для каждого программиста – сколько строк написано и т.п. Сами по себе они ничего не значат, но их изменение может говорить либо об изменении характера задач (например, помощь по другим проектам, больше общения с заказчиками и т.п.), либо изменение в мотивации программиста (потеря интереса, болезнь без больничного и т.п.). Так что это инструмент в руках менеджера, но не что-то абсолютное.
Аналогично метрики отработки часов.
Метрики на проект (без привязки к программистам) – это:
- метрики качества кода (что-то вроде Sonarqube)
- метрики соответствия стиля кодирования (например, ktlint) Это полезно, хорошо, если это проверяется при каждом MR/PR. Вполне объективные показатели, которые можно и нужно сделать обязательными.
Из git без относительно конкретного программиста можно достать метрику частоты изменения классов / методов (code churn rate). Это показывает наиболее горячий код: к нему нужно присмотреться, подумать о рефакторинге и дополнительных тестах. При этом достаточно хороших утил (работающих на уровне методов/функций/классов для Kotlin) я не видел. Чаще на уровне файлов, например https://github.com/garybernhardt/dotfiles/blob/main/bin/git-churn .
Количество строк кода (SLOC) – так же важная метрика. Она показывает сколько логики заложено в проект (и насколько сложно в этом разобраться). Но это скорее метрика проекта, а не конкретного разработчика. Это особо хорошо интегрировано в Rails:
+----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 176 | 149 | 10 | 18 | 1 | 6 | | Helpers | 38 | 35 | 0 | 4 | 0 | 6 | | Models | 183 | 147 | 5 | 20 | 4 | 5 | | Libraries | 0 | 0 | 0 | 0 | 0 | 0 | | Integration tests | 0 | 0 | 0 | 0 | 0 | 0 | | Functional tests | 855 | 686 | 9 | 3 | 0 | 226 | | Unit tests | 684 | 568 | 7 | 0 | 0 | 0 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 1936 | 1585 | 31 | 45 | 1 | 33 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 331 Test LOC: 1254 Code to Test Ratio: 1:3.8
– сразу что-то можно сказать о проекте просто по данным цифрам.
SLOC хорошо показывает усилия по поддержке, а Hit of code усилия по разработке – https://hitsofcode.com/ . В Hit of code учитывается не только текущий код, но и удаленный.
Из относительно недавнего хороши метрики работы приложения (DORA):
- Lead time for changes – время от попадания кода в main до попадания его к клиентам
- Change failure rate – % выпусков для клиентов, которые требуют немедленных исправлений
- Deployment frequency – частота выпуска новых версий для клиентов
- Mean time to recovery (MTTR) – среднее время на восстановление после сбоя
(понятно, что нас в данной заметке интересуют технические, а не продуктовые/маркетинговые метрики)
В итоге, есть несколько классов метрик, и все их имеет смысл использовать. При этом нет метрик, которые сами по себе показали бы премировать программиста или увольнять.
Это все хорошо, но все же как сравнить 2х программистов в разных проектах по метрикам?
Ответ достаточно банален: никак. Можно сравнивать программистов внутри команды: они работают в достаточно одинаковых условиях и что-то можно увидеть.
А в разных проектах может быть слишком много разных вещей: в одной команде слабый аналитик (или вообще нет) и больше времени тратится на постановку задачи, а в другой команде своеобразные непродуктовые требования и время уходит на это. Как тут можно сравнивать по коду?
В целом, если хочется, то можно сравнивать проекты целиком: сколько прибыли приносят, сколько проблем при развитии и поддержке. При этом расходная и нефункциональные части зависят от программистов. Доходная же опосредованно через нефункциональную часть (например, стабильность и быстрота работы).