Я хотел бы написать ловушку перед фиксацией, которая сообщит вам, улучшили ли вы или ухудшили некоторую метрику кода проекта (т.е. среднюю длину функции). Хук должен знать, какова была предыдущая средняя длина функции, и я не знаю, где хранить эту информацию. Один из вариантов - сохранить в репозитории дополнительный файл .metrics, но это звучит неуклюже. Другой вариант - git stash вычислить метрики, git stash pop, снова вычислить метрики и распечатать дельту. Я склоняюсь к последнему. Есть ли другие решения?
Хранение метрик кода
Ответы (1)
Отказ от ответственности: я являюсь автором инструмента Metrix ++, который я использую в рабочем процессе, описано ниже. Думаю, тот же рабочий процесс можно выполнить с другими инструментами, способными сравнивать результаты.
Одна из предложенных вами идей отлично работает, если вы добавите пару проверок CI (см. Шаги ниже). Я считаю это твердым. Не уверен, почему вы считаете это неуклюжим.
У меня есть файл с результатами метрик, который обновляется перед каждой фиксацией и сохраняется в VCS. Назовем этот файл metrics.db и рассмотрим автоматизацию следующего рабочего процесса при сборке / тестировании проекта:
1) если metrics.db не изменялся с момента последней проверки (т.е. это исходные данные для предыдущей / базовой версии), скопируйте его в metrics-prev.db
2) Соберите метрики для текущего кода, что снова создаст файл metrics.db. Примечание: это очень полезно, когда инструмент метрик может выполнять итеративное сканирование для достижения наилучшей производительности (т. е. вычислять метрики для обновленных функций / классов), поэтому он дает вам возможность запускать инструмент метрик для каждой сборки, включая итеративную. < / em>
3) Сравните metrics-prev.db с metrics.db. Если метрики выявляют регрессию, выполнить сборку невозможно и [необязательно] не разрешить фиксацию - командное правило. Если показатели хороши, сборка прошла успешно и может произойти фиксация.
4) [опционально] вы можете запустить непрерывную интеграцию (CI), которая проверяет, что фактический зафиксированный файл metrics.db соответствует зафиксированному коду для той же ревизии (т. Е. Выполните те же 1-3 шага и убедитесь, что разница равна нулю в шаг 3). Если diff не равен нулю, это означает, что кто-то забыл обновить файл metrics.db и, по-видимому, не выполнил проверку перед фиксацией, поэтому отмените изменение.
5) [необязательно] CI может выполнить шаги 1-3, если вы получите metrics.db как metrics-prev.db из предыдущей версии. В этом случае CI может также проверить, что собранный файл metrics.db совпадает с зафиксированным (альтернатива или дополнение для шага 4).
Еще одна реализация, которую я видел: файлы metrics.db хранятся на отдельном диске, вне VCS, и пользовательский сценарий может найти соответствующий metrics.db для ревизии. Я считаю это решение ненадежным, поскольку диск может исчезнуть, файлы можно перемещать и переименовывать и т. Д. Таким образом, размещение файла в VCS - лучшее решение, но подойдет любое.
Я попытался применить предложенную вами альтернативу: переключиться на предыдущую версию и дважды запустить инструмент метрик. Я отказался от этого подхода по нескольким причинам: скрипт проверки метрик изменяет ваши исходные файлы (поэтому невозможно включить его в итеративную перестройку и продолжить бесперебойную работу с вашей IDE, поскольку он будет жаловаться на измененные файлы), а во-вторых, он очень медленный. производительность (по сравнению с итеративным повторным сканированием она очень медленная).
Надеюсь, поможет.
person
Andrew
schedule
10.02.2015
