Почему 200 коммитов не говорят, что код пережил релиз

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

Количество действий удобно считать, но оно плохо отвечает на главный вопрос: что осталось в продукте?

Смотреть нужно после того, как код пожил

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

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

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

Как поможет DevScore

DevScore рассчитывает приближённую выживаемость значимого кода по зрелым трёхмесячным окнам, использует историю Git и учитывает изменения путей файлов. Руководитель видит не только поток коммитов, но и то, какая часть работы закрепилась в продукте. Это хороший повод обсуждать архитектуру и процессы — а не соревноваться в количестве нажатий на Commit.