Используйте историю Git, чтобы определить болевые точки в любом проекте

Вы слышали о творчестве Адама Торнхилла? Если нет, я настоятельно рекомендую вам выделить время и проверить Ваш код как место преступления или Рентгеновские снимки ДИЗАЙНА ПО. В обеих книгах автор погружается в неизведанную территорию — рассматривает эволюцию кодовой базы как фактор ее изменений с течением времени.

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

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

Git на помощь

В своих книгах Торнхилл обсуждает несколько вариантов развития одной и той же основной идеи — файлы, которые часто меняются (за некоторыми исключениями), как правило, являются теми файлами, в которых возникает больше всего проблем, отсюда и необходимость их изменения. Мы редко задумываемся об этом простом факте, когда работаем над одним и тем же проектом в течение длительного периода времени. Тем не менее, при адаптации нового члена команды, поиске неизвестного фрагмента кода или просто ретроспективном анализе вашего кода такие знания могут оказаться бесценными.

Код на удивление прост:

git log --format=format: --name-only | egrep -v '^$' | sort | uniq \ -c | sort -rg | head -10

Что мне нравится делать, так это добавлять такие команды в мой список псевдонимов git. Откройте файл ~/.gitconfig и добавьте следующие две строки в раздел [Aliases]:

code-changes = "!git log --format=format: --name-only | \ 
egrep -v '^$' | sort | uniq -c | sort -rg | head -10" 
cc = "!git code-changes"

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

Сделаем пример. Я решил (совершенно случайно) взглянуть на Gorm, одну из популярных Go ORM. Это 10 лучших файлов, которые появляются на момент написания этой статьи:

272 main.go
246 scope.go
208 README.md
155 scope_private.go
117 main_test.go
116 gorm_test.go
105 model_struct.go
97 do.go
81 model.go
80 utils.go

Исключая файл README.md, отчетливо видно некоторое преобладание одних файлов над другими. Многие проекты Go начинаются с одного файла main.go, и со временем логика переходит к другим файлам и пакетам. В нашем случае это точно не так. main.go Горма — это один большой кусок кода, который можно легко разделить на два или более файлов, особенно потому, что несколько файлов могут совместно использовать один и тот же пакет Go.

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

Что ты видишь?

Первоначально опубликовано на https://preslav.me 1 марта 2020 г.