Сегодняшний день посвящён теме Code Archeology. Она представляет из себя подход к исследованию кода как чёрного ящика. Мы в сам код не смотрим, но получем информацию о нём по внешним проявлениям. Основным чупальцем являются системы контроля версий (СКВ), но могут быть и багтрекеры, сервисы ревью кода и разного рода анализаторы.

Она хорошо дополняет такие известные практики как автотесты, ревью и статический анализ, которые являются примерами проактивного ухода за кодом. При этом статей и инструментов на тему Code Archeology немного.

Автотесты довольно дороги. Code Archeology отвечает на вопрос, где они нужны в первую очередь и стал ли код стабильнее после их внедрения; показывает хорошо ли автотесты спроектированы или ломаются после каждого изменения кода и вреда от них больше, чем пользы.

Метрики кода, включая test coverage, показывают насколько код плох, но ничего не говорят о том, а надо ли что-то с этим делать. Есть мнение, что не весь код обязан быть одинаково хорошим. Code Archeology помогает понять, для каких частей кода это критично.

Кодревью играет важную роль в раннем предотвращении ошибок технического и архитектурного характера, но вещь дорогая, т.к. завязана на людей. Code Archeology подсвечивает, где эта цена оправданна и, более того, как я покажу завтра, позволяет отыскать наиболее подходящих ревьюеров.

Я покажу применение техник Code Archeology на примере рабочего проекта – клиента Облака Mail.Ru для #iOS. Это позволит мне предметно отвечать на возможные вопросы о пользе той или иной раскопки.

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

Чем больше круг, тем чаще вносятся изменения в код. Чем краснее круг, тем чаще изменения связаны с фиксами багов.

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

Сравнение однотипных срезов – ключ для понимания, есть ли улучшения в результате рефакторинга. Для ограничения выборки временным интервалом есть доп. параметры --after и --before. Они используются для снятия аналитических срезов в разные периоды жизни проекта.

Для использования стандартных инструментов обработки данных, последние необходимо привести в общеупотребительный формат вроде csv. С этой задачей хорошо справляются скрипты Адама Торнхилла из книги "Your Code as a Crime Scene". https://github.com/adamtornhill/code-maat

После сборки тулы по инструкции на выходе будет jar-файл. На вход она принимает файл с логом от git в формате --numstat, как в примерах выше. Заалиасим тулзу следующим образом: alias maat='java -jar /path/to/code-maat/target/code-maat-1.1-SNAPSHOT-standalone.jar'

Вывод самых часто изменяемых файлов в 2018 году с помощью связки git + maat:

git log --pretty=format:'[%h] %an %ad %s' --date=short --after=2017-12-31 --before=2019-01-01 --numstat > all-2018.log

maat -l all-2018.log -c git -a revisions | head -n 20

Инфильтруем все технологические файлы, запайпив вывод maat командой sed, пропускающей заголовок csv и строки с инфой по файлам с расширением m или mm.maat -l all-2018.log -c git -a revisions | sed -n '1p;/\.[m|mm]/p' | head -n 20