Статья о том, какие неочевидные вещи можно достать из логов гита. Методы ниже не бьют на 100%, но «щито поделать, десу».

Подготовка:

1. в корне своего репозитория выгружаем git лог в файл: git --no-pager log --raw --numstat --oneline --all --reverse --date=iso-strict --pretty=format:"%ad>%aN>%aE>%s" > log.txt

2. файл кидаем сюда

Анализ email адресов

Пункты ниже основаны на том, что в информации о коммите есть email пользователя. В процессе работы люди иногда меняют аккаунты. После этого коммиты оказываются подписаны разными email адресами.

Год рождения

• выписываем все email;

• фильтруем «личные» (зарегистрированные на публичных сервисах типа yandex.ru, gmail.com, mail.ru);

• находим те, у которых есть цифры в логине (alex1989, pushkin.05 и т.п.);

• проверяем, что разница с текущем годом больше 18, но меньше 70;

Пет-проекты

• выписываем все email;

• фильтруем «тех. почту github»;

• вырезаем логины;

• формируем ссылки на профиль github;

Модель ноутбука

MacOS, в качестве email по умолчанию иногда подставляет название устройства в стиле: Macbook-Air-Alex или Macbook-Pro-Ivan. Т.к. Air и Pro это разные типы ноутбуков, мы можем разделить пользователей на три группы:

• обладатели MacBook Pro;

• обладатели MacBook Air;

• остальные;

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

Исследуем локальную сеть

Когда MacOS не подставляет в email название устройства, она подставляет туда его IP адрес в локальной сети.

Я пытался найти какую-то связь, типа:

• IP выдаются по порядку;

• мы знаем что устройства находятся в одной сети;

• можем предположить количество устройств в офисе;

Но связи найти не смог, т.к. все эти предположения зависят исключительно от того, как админ настроил сеть и нет какой-то «стандартной практики». Да и большинство устройств выдавали один и тот же диапазон с 49, 50, 51 на конце.

Частотность коммитов и их подпись

График отпусков

Два стула столпа нашей аналитики:

• в логах можно найти логины и даты коммитов;

• в отпусках люди не комитят;

Перебираем все коммиты пользователя и выписываем длительные перерывы:

• Не коммитил пару недель — ушел в отпуск;

• Перерыв полгода — перевод в другой отдел;

• Стабильно коммитил, а потом пропал на пару лет — вероятно, успел поработать в другой конторе и вернулся назад на проект.

Ну или во всех случаях выше программист «работал в стол» и его код не вливали. В крупных конторах с хоть какими-то процессами обычно получается график отпусков, а не график «работы в стол».

Есть еще тимлиды. Они постоянно сидят на совещаниях и редко пишут код. Тут на графике будет один сплошной отпуск. Ну так и мы не из 1С данные выгружаем, а гадаем на кофейной гуще логах.

Текущее доступное количество дней отпусках

Из прошлого пункта мы +/- знаем сколько дней потрачено каждым членом команды. Найдем остаток:

• Берем количество отработанных лет для каждого сотрудника;

• Умножаем каждый год на 28 дней отпуска (по ТК РФ, который предсказываем по часовому поясу);

• Вычитаем 100% потраченные (недели без коммитов);

• Перепроверяем смену email адресов, чтобы убедиться, что сотрудника не переоформляли в другое ООО через увольнение и выплату отпускных.

Владельцы гринкарты Релоканты в команде

Это уже немного затрагивалось в прошлой статье, где мы вычисляли местоположение программистов по тайм-зоне и делали коррекцию по языку, фамилии и выходным. Но тут можно покрутить тему лингвистики.

Будем в тексте коммитов искать орфографические и пунктуационные ошибки. Наша задача найти случаи, когда пользователь применяет правила одного языка при письме в другом.

Например: в русском имеем «и т.д.», а в английском «, etc». Русскоязычный может написать на английском «and etc», сделав прямой перевод. Если он долго в другой языковой среде, то может появится обратный вариант «, етц». Англоговорящий по аналогии может написать «, т.д.».

Ещё пример:

• В английском: запятая перед «and» в перечислениях: «apples, bananas, and oranges»

• В испанском: «ano» вместо «año»

• Во французском: «aktiv» вместо «actif»

Составим каталог таких ошибок. В зависимости от региона и используемого языка в commit message можем подобрать список ошибок для поиска. Если в регионе северной Америки видим пунктуацию восточной Европы (и наоборот) — это наш клиент.

Местоположение офиса разработки

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

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

Обратный метод:

• по тайм-зоне и почте угадываем страну и компанию;

• просим чат жопу gtp написать список адресов офисов ТОП 100 IT компаний;

• проверяем к какому офису подходит пользователь;

Минус: нужно хранить в коде большую таблицу адресов разных ООО (это персональные данные?), которая ещё и стареет. Делать не стал.

Кандидаты на рефакторинг

Это мне подсказали на PiterJS. Нам нужно найти файлы при помощи ИИ, которые выиграют в «говно-код-бинго» с условиями:

• много строк (например, больше 600 строк);

• их меняли в ходе разных задач (например, больше 50 задач);

• это не конфиги и тесты (отметаем расширения json, xml и т.п.);

Так себе критерии, но обычно больше половины списка реальные точки боли.

Адреса серверов хранения кода и порты

В целом понятно, что git знает, где он есть. Так же очевидно, что это знаем мы, раз уж у нас есть доступ к его логам. Но кого это волнует.

Иногда, git делает записи в логах о том что branch или PR был куда-то влит/перелит с указанием точного адреса. Список этих адресов может стать для вас сюрпризом.

Типы систем хранения кода

Разные системы хранения кода (Bitbucket, Gitlab, Github и т.п.) имеют немного разный синтаксис записи информации о «влитии кода». Зная разницу в синтаксисе можно сказать когда, откуда и куда переезжал репозиторий.

Например, событие влитие Pull Reuqest:

• Github: «Merge pull request #...»

• Bitbucket: «Pull request #...»

Или слияние веток может быть:

«Merge branch ... into ...»
«Merge branch ... of ...»
«Merge branch ... from ...»

Так же отличаются типы кавычек вокруг названий веток (и их наличие).

Размер команды

Пришел я на PythonSPb, а они мне и говорят: «Каждый последний четверг месяца мы ходим в бар» «Легко посчитать людей, чьи логины мы видим в логах репозитория. Но как посчитать тех, кого мы не видим?»

Номера задач в большинстве таск-трекеров идут последовательно и представлены в виде целых чисел. Перед числом, в большинстве случаев, находится буквенный префикс отдела. Например: HABR-123, HH-321

• выписываем все номера задач из commit-message.

• группируем их по датам. Это «объём выполненных задач» , т.к. мы нашли их номера в правках кода.

• мы видим логины тех, кто делал эти правки. Можем посчитать их количество. Это «текущая рабочая группа»

Зная «размер рабочей группы» и «объем выполненных задач», можем прикинуть «среднее количество задач на человека»

• берем разницу между самым маленьким номером задачи и самым большим в течении одной недели. Повторяем процедуру несколько раз.

Таким образом, мы узнаем на сколько в среднем увеличивается ID задач за неделю. Это «скорость заведения задач».

Обычно один отдел заводит все свои задачи в рамках одного буквенного префикса. Значит в вычисленном нами объеме имеются задачи и аналитики, и тестирования и бек/фронт/мобильной разработки.

Разделим «скорость заведения» на «среднее количество задач на человека» и узнаем примерный размер всего отдела.

В рассуждениях выше много мест с фразой «предположим». Давайте попробуем снизить шум.

Актуальность номеров задач

Как узнать новая это задача или бесконечный разбор беклога?

В этом нам помогут релизы. И чем чаще отдел отрезает релизы, тем больше шансов поймать точку синхронизации. Это буквально любой хотфикс. Тестировщики моментально описывают багу прода или релиза и просят исправить ПРЯМО СЕЙЧАС. Программист правит, подписывает коммит и мы получаем свежий номер задачи, который прямо сегодня создали в трекере. Таким образом, при частых релизах мы можем быть уверены, что наша «разница номеров задач» актуальна и привязана +/- к моменту времени (с погрешностью в размере количества дней между релизами).

Сами релизы и их состав легко посчитать, если команда отрезает следующий от предыдущего (а не от develop ветки). Ну или делает подлив в develop / main после всех фиксов. Но это и так делают многие другие библиотеки. Описывать смысла нет.

Размер бэклога

Т.к. у нас есть «историчность данных». Для каждой недели год назад мы можем перепроверить все номера задач в будущем. Это будет «бэклог взятый в работу». Мы видим:

• когда, примерно, задачи завели в таск-трекере;

• какой процент это был от общего объема анализируемой недели/месяца в прошлом;

• когда эти задачи взяли в работу.

Экстраполируем это на «невидимую» часть команды. Так же по бэклогу мы можем понимать когда берут актуальные задачи, а когда разбирают запасы. Можно даже составить график «сгорания бэклога».

Таким образом, на исторических данных мы можем выделить беклог, прикинуть его объем и посмотреть, сколько живут задачи внутри него.

Количество управленцев

На каждые 5-7 человек, обычно образуется один менеджер, который занимается только заведением и назначением задач. На каждые 5-7 менеджеров снова добавляем «супер-менеджера» и т.д. Таким образом мы можем прикидывать количество «говорящих голов», которые есть в штате, но не пишут код.

Пример расчёта

Все, что описано выше, будет сильно мазать на маленьких проектах и сроках наблюдения. Но «типовой» отдел внутри корпорации (отдел в 10..20 человек с тестированием, беком, UI, аналитикой) на промежутке в пол года/год становится более предсказуемым.

Давайте рассмотрим пример, чтобы закрепить прошлые три пункта:

• в логах марта самый маленький номер задачи JIRA-100;

• а самый большой номер JIRA-180;

Значит за июнь завели 80 задач (180 — 100)

• в логах марта мы нашли упоминание 20 задач из этого диапазона;

• их сдело 2 человека;

Значит группа делает 10 задач на человека в месяц (20 / 2);

• до конца весны мы нашли еще 15 задач из этого диапазона;

Значит размер нового беклога этой группы в марте был 15 задач. 20 сделанных + 15 из беклога и это на 2х человек. А всего задач было 80. Значит 45 из них делали другие люди.

Если у всех задач +/- одинаковая гранулярность, то нам нужно от 3 до 5 программистов аналогичных по скорости работы тем двоим, которых мы видим). Повторяем расчет на каждый месяц. Берем среднее за три месяца, чтобы сгладить результат. Цифры будут колебаться, но общий порядок обычно не меняется.

Количество сотрудников в компании

Ну это легко:

1. Смотрим ООО через сервисы ФНС.

2. Берем все репозитории и считаем лог.

Ну камон! О чем мне тогда писать этот лонгрид? Ради интереса посчитаем возможное общее число сотрудников всего по трем коммитам сделанным одним человеком в разное время (даже без commit-message).

У нас есть три техники гендзюцу, ниндзюцу и тайдзюцу:

1. умение анализировать почтовые адреса;

2. понимание серийных ID и способ их подсчёта;

Чтобы прикинуть количество человек нам нужно чтобы совпало три условия:

1. Компания должна выдавать серийные тех. учётки (типа: SBER-100901@dev, SBER-100902@dev и т.д.)

2. Компания, время от времени, должна переводить туда-сюда сотрудников между субподрядчиками (налоговые оптимизации) или обновлять учётки (прихоть СБ).

3. Нам нужно найти одного долго-работающего сотрудника пережившего пару таких волн переводов.

Если в почтовых адресах мы найдем две/три тех. учётки с одним именем пользователя, то (как и в случае с ID задач) можем посчитать дельту приращения за период и прикинуть общее количество таких учёток во всей компании (примерно) которое существовало в этот промежуток времени.

Метод супер не надежный. Только очень большие компании подходят под условие. Зато на них отработает достаточно хорошо. Данных много и учётки меняются часто.

Коэффициент суеты

Если команда живет по графику «один релиз раз в несколько недель», то, скорее всего, когда его отрезают и начинают тестировать находят баги. На каждый баг заводят задачу. На каждую задачу делается минимум один коммит. Цикл тестирования короткий. Количество багов в этот период, как правило, больше чем до него.

Таким образом, мы можем обнаружить увеличение частоты коммитов за пару дней до сдачи релиза. Чем кривее собран релиз, тем больше будет суеты перед его выпуском.

Определим «коэффициент суеты», как «один день» деленный на «количество коммитов». Построим график «суеты» команды и каждого её члена. Скорее всего, тимлид (или релиз менеджер) покажет перед релизом повышенный коэффициент относительно других. Сразу выдадим желтую звезду ачивку этому парню.

Итого

В большинстве случаев, при анализе коммитов людям нужен просто список задач (или релизов, или PR) с фильтрами и выгрузкой в Excel (который они могли бы сделать в JIRA, если бы нормально её вели и настраивали метрики). Но авто-сбор дополнительной информации делает анализ более интересным.

Все что описано выше можно потыкать онлайн тут, исходники тут.

// NodeJS
npx assayo

// Python
pipx install assayo
assayo

// Ruby
gem install assayo
assayo

// Go
go get github.com/bakhirev/assayo
go install github.com/bakhirev/assayo
assayo

// PHP
composer require bakhirev/assayo
vendor/bin/assayo

// Docker
docker pull bakhirev/assayo

Уцы не обессудь, не все успел дописать в коде. К лету допишу мамой клянусь. До лета онлайн версия опережает те, что в в виде библиотек. Так же буду благодарен за фитбек и багрепорты