Як defect prediction допомагає знаходити баги до релізу?
Дефекти в коді не випадкові. Файли з високою цикломатичною складністю, великою кількістю авторів і частими змінами статистично містять у 3–5 разів більше багів, ніж стабільні модулі. Ми будуємо ML-модель, яка аналізує статичні метрики коду, історію змін і патерни комітів, щоб заздалегідь вказати на зони ризику — до того, як баг потрапить у продакшен. Наша система цикломатичної складності (термін Томаса Маккейба) інтегрується у ваш CI/CD і видає попередження на кожен Pull Request. Досвід впровадження на 300+ проєктах показує: кількість інцидентів знижується на 30–40%, а час на code review скорочується на 20%.
Чому defect prediction — це не просто статичний аналіз?
Статичний аналізатор знаходить уже існуючі помилки: невикористані змінні, потенційні NPE. Але він не передбачить, який модуль «вибухне» через місяць. Defect prediction використовує історію змін: якщо файл змінювали 10 разів за 30 днів, у ньому 5 авторів і цикломатична складність 20, ймовірність дефекту в наступному спринті — 80%. Такі патерни не видно статичному аналізатору.
Які ознаки ми використовуємо?
Якість передбачення визначається набором ознак. Використовуємо три групи: Метрики коду (статичний аналіз):
- Цикломатична складність (McCabe complexity)
- LOC, LLOC, кількість методів на клас
- Глибина успадкування (DIT), зв'язність (CBO) для OOP
- Кількість параметрів методів
- Halstead Volume, Maintainability Index
Git-метрики (history-based):
- Кількість комітів за 30/90/365 днів (change frequency)
- Кількість унікальних авторів
- Вік файлу (days since creation)
- Кількість merge conflicts в історії
- Code churn:
(lines_added + lines_deleted) / LOC
Process-метрики:
- Кількість пов'язаних issues/tickets
- Час життя PR до merge
- Кількість review iterations
- Кількість revert-комітів
import pandas as pd from sklearn.ensemble import GradientBoostingClassifier from sklearn.pipeline import Pipeline def build_defect_predictor(train_df: pd.DataFrame): feature_cols = [ 'cyclomatic_complexity', 'loc', 'num_authors', 'change_frequency_90d', 'code_churn', 'avg_pr_iterations', 'dit', 'cbo', 'halstead_volume' ] pipeline = Pipeline([ ('clf', GradientBoostingClassifier( n_estimators=300, max_depth=5, learning_rate=0.05, subsample=0.8, random_state=42 )) ]) pipeline.fit(train_df[feature_cols], train_df['has_defect_90d']) return pipeline Збір і розмітка даних
Розмітка — ключовий етап. Визначаємо «дефектний» файл: файл, до якого прив'язаний хоча б один коміт з повідомленням, що містить fix, bug, defect, hotfix за період спостереження. Додатково — ручна розмітка від команди за серйозними інцидентами.
Для формування датасету використовуємо PyDriller для вилучення git-метрик і radon для Python-метрик, lizard — універсальний аналізатор для Python, Java, Go, C++, JavaScript.
# Збір метрик через radon і lizard radon cc src/ -j -a > complexity_metrics.json lizard src/ --csv > code_metrics.csv Модель на Gradient Boosting показує AUC-ROC на 10% вище, ніж логістична регресія, на датасетах з дисбалансом класів. Ми гарантуємо точність передбачення: precision у топ-20% ризикованих файлів — 0.71–0.78.
Інтеграція в Code Review процес
Модель запускається при відкритті Pull Request. У коментарі до PR додається попередження для файлів з defect_probability > 0.7:
⚠️ Високий ризик дефекту в `src/payment/processor.py` Прогнозована ймовірність дефекту: 83% Фактори ризику: висока цикломатична складність (18), 5 авторів, змінено 12 разів за останні 30 днів Рекомендація: обов'язкові 2 рецензенти, додати інтеграційні тести Додатково система формує щотижневий звіт «Технічний борг за ризиком» — топ-20 файлів, що потребують рефакторингу або посиленого тестування.
Метрики якості на реальних проєктах
| Метрика | Значення |
|---|---|
| AUC-ROC | 0.82–0.89 |
| Precision (топ-20% ризикових файлів) | 0.71–0.78 |
| Recall (відомі дефекти) | 0.74–0.82 |
| Передбачення за 14+ днів до багу | 68% випадків |
Підтримувані мови та репозиторії
Java, Python, Go, TypeScript/JavaScript, C++, C#, PHP. Репозиторії: GitHub, GitLab, Bitbucket — через API або локальний клон.
| Розмір кодової бази | Термін впровадження |
|---|---|
| До 50k рядків | 2–3 тижні |
| 50k–500k рядків | 3–5 тижнів |
| Більше 500k рядків | 5–8 тижнів |
Як впровадження впливає на вартість підтримки?
За нашими даними, впровадження системи скорочує кількість багів, що доходять до продакшену, на 35%. Це зменшує витрати на гарячі фікси та знижує навантаження на чергову команду. Один із клієнтів після впровадження скоротив час на debugging на 40% завдяки пріоритезації ризикованих модулів. Ми гарантуємо якість: підтримка моделі протягом 3 місяців після впровадження. Зв'яжіться з нами для оцінки вашого проєкту — отримайте консультацію щодо впровадження defect prediction у вашу команду. Наш досвід — понад 300 проєктів у сфері ML.
Що входить у роботу
- Аудит кодової бази та збір метрик (цикломатична складність, git-історія)
- Навчання моделі з підбором гіперпараметрів (AUC-ROC > 0.85)
- Інтеграція в GitHub/GitLab через webhook (коментарі до PR)
- Дашборд з топ-ризиковими файлами та трендами
- Документація та навчання команди (2 сесії)
- Гарантія якості: підтримка 3 місяці, коригування моделі при дрейфі даних
Замовте аудит вашого репозиторію вже сьогодні.