Уход одного активного разработчика может оставить без актуального автора до 97% файлов проекта. Такой результат в отдельных открытых репозиториях получил Tech Lead Сергей Прощаев, применив методику truck factor по Git: она показывает не назначенных ответственных, а концентрацию исторического авторства. Для российских команд это довольно неприятный, но полезный способ проверить, не маскирует ли CODEOWNERS зависимость от одного человека.
Об исследовании сообщает Habr / Карьера. Прощаев взял подход из работы исследователей под руководством Авелино, представленной на конференции ICPC в 2016 году, и проверил шесть открытых JVM- и Python-проектов по состоянию коммитов с 29 сентября по 23 октября 2026 года. Смысл метрики прост: сколько разработчиков должно исчезнуть из команды, чтобы более половины файлов потеряли авторов.
Расчёт строится на степени авторства файла — Degree of Authorship, или DOA. Модель учитывает, кто создал файл, сколько правок внёс конкретный человек и сколько изменений сделали другие участники. Первому автору даётся наибольший вес; последующие собственные изменения повышают показатель, чужие — постепенно снижают. Автором признаётся разработчик, если его нормированный показатель превышает 0,75, а абсолютный — не ниже 3,293. Затем из покрытия по очереди убирают человека, которому приписано больше всего файлов, пока авторы не перестанут покрывать половину кодовой базы.
В исходной работе 2016 года у 65% из 133 популярных проектов GitHub truck factor оказался не выше двух. В новой выборке результаты выглядят ещё нагляднее, если отделить исторических авторов от людей, которые действительно коммитили в последний год. У fastapi truck factor по всей истории и среди активных участников равен единице; при исключении лидера 78,6% файлов остаются без активного автора. У javalin этот показатель достигает 97%. У kotlinx.coroutines после ухода лидера без активного автора останутся 73,2% файлов, у ktor — 62,6%, у okhttp — 62,5%, у spring-petclinic — 74%.
История коммитов не равна карте знаний
Самая опасная ошибка — смотреть на весь срок жизни репозитория и считать проект устойчивым, если в истории много имён. Git хранит след ушедших сотрудников и контрибьюторов, но не сообщает, кто способен разбираться с инцидентом сейчас. В ktor и spring-petclinic показатель по всей истории равен четырём, а среди авторов с коммитами за последние 365 дней — единице. Формально у файлов есть несколько авторов, практически модуль может держаться на одном оставшемся разработчике.
Автор дополнительно ввёл две прикладные метрики: долю файлов, у которых уже нет автора с коммитами за год, и такую же долю после исключения наиболее вовлечённого активного человека. Даже без увольнений эти числа показывают «ничейный» код: он не обязательно заброшен, но его исторические авторы больше не участвуют в разработке. При смене половины команды подобная проверка полезнее красивой диаграммы оргструктуры: она показывает конкретные каталоги и файлы, для которых некому быстро объяснить архитектурные решения.
Это не повод объявить Git безошибочным измерителем компетенций. История правок отражает авторство, а не способность поддерживать код. Разработчик может знать модуль, хотя редко в него коммитит; другой мог создать файл, но давно не помнить контекст. Открытые проекты также не полностью похожи на продуктовые команды: в них иной ритм участия, больше внешних вкладов и выше доля старого кода. Но как индикатор для аудита риска truck factor по Git удобен именно тем, что не требует опросов, самооценок и героических таблиц в последний день сотрудника.
Почему CODEOWNERS и ревью не спасают сами по себе
Файл CODEOWNERS решает административную задачу: кого автоматически позвать на ревью. Правила защиты ветки позволяют сделать такое одобрение обязательным. Ни один из этих механизмов не доказывает, что назначенный владелец умеет исправить ночной сбой в модуле. Если человека добавили в список при запуске компонента и не возвращались к нему после нескольких кадровых изменений, документ превращается в декорацию с правильными фамилиями и устаревшей картиной знаний.
Отдельная ловушка — ревью, которое всегда делает один старший инженер. Комментарии к pull request и чтение диффа помогают держать качество, но не делают ревьюера соавтором файла в модели DOA и, что важнее, не гарантируют готовность другого участника поддерживать компонент. Команда получает быстрые решения и одновременно закрепляет единственного эксперта. Практичный тест здесь проще очередного регламента: сопоставить владельцев из CODEOWNERS с авторами по истории, а затем дать второму человеку небольшую задачу или разбор последнего инцидента в рискованном модуле.
Наконец, оценку усложняют AI-агенты. Коммит, подготовленный с помощью агента, всё равно попадёт в историю от имени человека, который его внёс. Git увидит рост его авторства, хотя часть понимания могла остаться в диалоге с инструментом, промптах, локальных экспериментах или вовсе не возникнуть у автора. Поэтому truck factor по Git стоит использовать как сигнал для проверки, а не как рейтинг сотрудников: измерять активность, обсуждать результаты с командой и фиксировать решения в коде, документации и тестах.
Главный вопрос для руководителей теперь не в том, успеет ли уходящий сотрудник передать дела за две недели. Важнее, сколько месяцев или лет команда позволяла знаниям оседать в одной голове — и сможет ли она увидеть это до следующей аварии. Регулярный отчёт по активному авторству не устранит зависимость автоматически, но даст ранний список модулей, где пора менять распределение задач, ревью и ответственность.
