Каждая современная система управления версиями может нарезать и вырезать историю программы. Существует множество инструментов для статического и динамического анализа кода. Какая математическая формула позволила бы мне интегрировать объем активности в файл вместе с количеством развертываний этого программного обеспечения? Мы обнаруживаем, что даже если программа завершает все свои модульные тесты, она требует больше работы, чем мы ожидаем во время обновления. Мера такого типа должна быть возможной, но сидеть и думать даже о своих единицах я поставил в тупик.
Обновление: Если что-то отправляется на тестовую машину, я вижу маркировку менее гнилой. Если что-то будет отправлено во все тестовые боксы, я смогу увидеть, как оно получает новый маркер. Если что-то пойдет в производство, я мог бы кивнуть и уменьшить его bitrot . Если в его файлах много активности, и он никуда не отправляется, я бы выбрал из этого дерьмо. Не сосредотачивайтесь на коде, предположите, что любые данные мне нужны.
Какой анализ коммитов (комментарии коммитов (упомянутый ниже) или время между коммитами) являются достоверными данными для применения?
Обновление: Я думаю, что размерный анализ, вероятно, может быть основан только на возрасте. Относительно этого немного сложнее. Старый код гнилой. Средний возраст каждой строки кода по-прежнему просто мера времени. Большой исходный модуль гниет быстрее, чем меньший, более сложный?
Обновление Покрытие кода измеряется в строках. Код, выполняемый часто, по определению должен быть менее гнилым, чем код, который никогда не выполнялся. Чтобы точно измерить битрот, вам понадобится анализ покрытия, чтобы действовать как демпфер.