Как показать инженерный вклад, если весь код лежит в закрытых репозиториях

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

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

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

Три способа измерить вклад: от бесполезного к честному

Все они строятся на git-истории. Но между ними огромная разница.

Почему blame авторитетнее остальных? Потому что код не просто написан — он пережил чужие рефакторинги, релизы и до сих пор исполняется. Это и есть выжившее авторство.

Две детали, которые делают цифру защищаемой

Флаги. Я запускаю git blame -w -M против production-ветки. Флаг -w игнорирует изменения, состоящие только из пробелов, а -M находит строки, перенесённые или скопированные внутри файла. Оба флага делают результат консервативнее: авторство остаётся у того, кто написал строку изначально, а не переформатировал её. Если бы мне нужна была цифра побольше, я бы эти флаги снял. Любой, кто знает команду, проверит это без доступа к репозиторию.

Выборка. Она детерминированная: каждый N-й файл из отсортированного списка. Никакого ручного выбора каталога и никакого случайного дампа, который можно перебрасывать, пока цифра не станет лестной. Ошибка обычно происходит именно с выборкой по каталогам — потому что авторство в репозитории распределено неравномерно: в одних пакетах вы хозяин, в других гость. Случайный сэмпл этого не отразит.

Что делать, если измерение показывает неудобную правду

В одном проекте, где я был одним из двух инженеров-основателей, blame по детерминированной выборке из нескольких сотен файлов TypeScript показал 84,7% выживших строк фронтенда. Доля моих коммитов в production-ветку за тот же период — 80,7%. Заметьте: выживших строк больше, чем коммитов. Это значит, что я не только наращивал объём кода, но и переписывал существующий, консолидировал его. Код, написанный другими, непропорционально часто заменялся моим. Отсюда и «основной автор», а не «тот, кто чаще коммитил».

Бывает и наоборот: доля коммитов выше доли выживших строк. Это означало бы, что вы написали много кода, который позже переписали другие. Такой исход реален. Метод, который не способен его показать, ничего не стоит.

В бэкенде того же проекта всё сложнее: 23,2% выживших строк против 30,9% коммитов. Я присоединился к бэкенду через шесть месяцев после начала работы, а до меня его восемнадцать месяцев активно развивали другие инженеры. Честная формулировка: я был существенным, но не главным автором части системы, к которой пришёл поздно. И да, я пытался не намекать нигде на обратное.

Интереснее разбивка по модулям. Моя доля коммитов в тестах — 83,2%, в доменных сервисах — 53,6%, в обработчике событий — 55,4%. А в инфраструктуре — 24,1%, в ядре домена — 20,8%, в CQRS-handler'ах — 16,6%. То есть я не был крупнейшим бэкенд-автором по объёму. Я владел частями, требующими архитектурных решений, и тестами, на которые опиралась команда. Это разные утверждения, и они должны звучать по-разному.

Сводная цифра по всем четырём репозиториям за время моей работы — 5717 коммитов из 10402, то есть 55,0%. Я записываю её только потому, что она самая консервативная из возможных. Но вести аргумент с неё нельзя: число, смешивающее фронтенд, где я главный автор, и интеграционный сервис, где я появлялся редко, ничего не говорит и о том, и о другом.

Когда доступен только слабый метод

Во втором проекте, где я работал совместителем на позиции founding-инженера, доступны были только коммиты. Веб-приложение: 157 из 209 коммитов, то есть примерно три четверти — и первый коммит мой. Python API: 31 из 209, это около 15%. Я формулирую так: «основной автор веб-приложения» и «внёс вклад во второй сервис». Пятнадцать процентов не наряжаю ни во что.

Если commit share — единственное, что у вас есть, говорите об этом прямо. Не подавайте его в той же интонации, что и цифру blame.

Отдельно стоит случай, где никакой анализ не нужен. В одном репозитории все коммиты в директории мобильных приложений — мои: 47 в iOS и 28 в Android, плюс конфигурация Capacitor и все end-to-end тесты Playwright, 11 из 11. Ни один другой автор ни разу туда не коммитил. Это не анализ, это арифметика. И её сложнее оспорить, чем любую выборку.

Что добавляет веса самостоятельным измерениям

Метод с раскрытием деталей даёт утверждение, которое можно оценить. Но не подтверждённое извне, и никакое самопубликованное измерение этого не заменит. Закрывают разрыв три вещи:

• Артефакты процесса, существующие независимо от моих слов: 255 дизайн-спецификаций, 207 планов имплементации, 17 прод-ранбуков, 377 релизов, скоординированных по четырём репозиториям за 239 активных дней разработки за двенадцать месяцев.
• Два сооснователя, готовые выступить референсами и подтвердить границы моей зоны ответственности без меня в комнате.
• Предложение, которое ничего не стоит, но показывает уверенность: прогулка по моим системам строка за строкой, включая места, которые я бы сейчас переписал.

Измерения нужны, чтобы разговор начинался не с взаимных заявлений, а с воспроизводимой процедуры. Они не доказательство. Они — способ узнать правду. Поэтому весь метод я публикую так, чтобы с ним можно было не согласиться: с флагами, выборкой и оговорками, напечатанными рядом с каждой цифрой.