Как предсказать баги по истории коммитов: исследование Microsoft про code churn — VogueTech

Что нового

Исследователи Microsoft — Начиаппан Нагаппан и Томас Болл — в 2004–2005 годах предложили способ заранее оценивать «забагованность» системы по истории изменений кода (code churn).

Ключевые факты из работы:

Вместо абсолютного churn (сколько строк кода поменяли) они используют относительные метрики: изменения в привязке к размеру компонента и ко времени.
Для прогноза они применяют статистические регрессионные модели.
На кейсе Windows Server 2003 их набор метрик смог рано предсказать плотность дефектов в компонентах системы.
Метрики позволили разделять бинарники на fault‑prone и не склонные к ошибкам с точностью 89,0%.
Исследование опубликовано Ассоциацией вычислительной техники (ACM), полная версия доступна в ACM Digital Library.

Главное изменение подхода: не просто считать, сколько кода поменяли, а соотносить это с масштабом компонента и периодом, за который произошли изменения.

Как это работает

Что такое code churn

Code churn — это количественная оценка того, как часто и насколько сильно меняется код:

сколько строк добавили;
сколько удалили;
сколько переписали за определённый период.

Microsoft смотрит на churn по компонентам (например, по бинарникам в Windows Server 2003) и связывает историю изменений с тем, сколько дефектов нашли в этих компонентах.

Абсолютные vs относительные метрики

Авторы проверили два подхода:

Абсолютные метрики churn:
- общее число изменённых строк;
- общее число изменений в файле/компоненте за период.
Относительные метрики churn:
- churn, нормированный на размер компонента (например, изменённые строки / общее число строк);
- churn в привязке к времени (на каком этапе жизненного цикла продукта происходили изменения);
- другие соотношения, которые связывают объём и скорость изменений с характеристиками компонента.

Дальше они строят регрессионные модели и проверяют, как хорошо каждая группа метрик предсказывает плотность дефектов (defect density) — сколько багов приходится на единицу размера компонента.

Результат:

абсолютный churn плохо объясняет, где будут баги;
относительные метрики churn дают сильную предсказательную силу и позволяют заранее понять, какие бинарники потенциально проблемные.

Кейc Windows Server 2003

Microsoft взяла реальные данные по Windows Server 2003:

история изменений бинарников;
размер компонентов;
данные о дефектах.

На этом датасете исследователи проверили свои модели и показали, что:

относительные метрики churn действительно коррелируют с плотностью дефектов;
по ним можно классифицировать бинарники на «склонные к ошибкам» и «относительно безопасные» с точностью 89,0%.

Что это значит для вас

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

Не полагайтесь на голые числа по коммитам.
- «Мы изменили 10 000 строк» само по себе почти ничего не говорит о риске багов.
- Важно, какой это процент от компонента и когда эти изменения произошли.
Вводите относительные метрики churn в отчёты. Примеры полезных показателей:
- изменённые строки / общий размер компонента;
- частота изменений в критичных модулях за релизный цикл;
- всплески churn ближе к релизу.
Используйте churn для приоритизации тестирования.
- Компоненты с высоким относительным churn — кандидаты на более плотное тестирование и code review.
- Это особенно полезно в больших системах, где нельзя протестировать всё одинаково тщательно.

Если вы разработчик

Смотрите на историю файла перед тем, как в него лезть.
- Часто меняющийся файл с большим относительным churn — сигнал, что там выше риск сломать что‑то ещё.
Будьте осторожнее с поздними большими изменениями.
- Исследование связывает интенсивные изменения и высокую плотность дефектов.
- В конце релизного цикла лучше дробить доработки и тщательнее ревьюить.
Используйте churn как аргумент в дискуссиях.
- «Этот компонент стабилен, churn низкий, менять его рискованно» — это уже не ощущение, а метрика, подтверждённая исследованием Microsoft.

Если вы занимаетесь инженерной аналитикой

Стройте регрессионные модели вокруг относительных метрик churn.
- Авторы показали, что такие модели реально предсказывают плотность дефектов.
Используйте churn для ранних сигналов.
- Это не замена баг‑репортам, а способ заранее увидеть зоны риска и перераспределить ресурсы.

Исследование не требует VPN или доступа к закрытым сервисам Microsoft. Полный текст доступен в ACM Digital Library; для некоторых сценариев может понадобиться подписка или доступ через университет.

Место на рынке

Работа Нагаппана и Болла — это не продукт, а научное исследование, которое легло в основу многих современных практик инженерной аналитики в индустрии.

По факту, оно конкурирует не с конкретным инструментом, а с другими подходами к предсказанию дефектов:

простые метрики сложности кода;
количество найденных багов в прошлом релизе;
субъективные оценки риска.

Отличительные моменты подхода Microsoft:

упор на историю изменений вместо статичного снимка кода;
использование относительных показателей вместо сырых чисел по строкам;
подтверждение на крупном промышленном проекте Windows Server 2003 с измеримой точностью 89,0% при разделении бинарников на fault‑prone и нет.

Если вы строите свои внутренние дашборды или системы предсказания дефектов, эта работа — хороший ориентир, какие метрики churn реально имеют смысл и как их использовать в статистических моделях.