Как оценить качество работы кода в продакшн?

Как оценить качество работы кода в продакшн?

Оценка качества кода в production — критическая задача System Analyst. Это не просто посмотреть на ошибки, но понять здоровье системы в целом.

Метрики качества кода (Code Quality Metrics)

1. Статические метрики (Static Metrics)

Это метрики, которые можно измерить без запуска кода.

Complexity (Сложность):

• Cyclomatic Complexity — количество путей выполнения в функции
  • < 5: OK
  • 5-10: Warning

  • 10: Refactor immediately!

Пример:

# Complexity = 1 (простая функция)
def add(a, b):
    return a + b

# Complexity = 4 (4 пути выполнения)
def validate_age(age, country):
    if age < 0:                    # Path 1
        return False
    if country == "US" and age < 18:  # Path 2
        return False
    if country == "UK" and age < 16:  # Path 3
        return False
    return True                    # Path 4

Maintainability Index:

• Комбинирует Complexity, Lines of Code, Halstead metrics
• Score 100-0

• 85: Good

• 50-85: Average
• < 50: Low (need refactor)

2. Динамические метрики (Runtime Metrics)

Это метрики, которые измеряются во время работы приложения.

Error Rate (Частота ошибок):

error_rate = total_errors / total_requests

В production:
- < 0.01% (1 на 10,000): Good
- 0.01-0.1% (1 на 1,000): OK, нужно мониторить
- > 0.1%: Red flag, нужна срочная диагностика

Response Time (Время ответа):

P50 (median):   50% запросов быстрее этого
P95:            95% запросов быстрее этого
P99:            99% запросов быстрее этого
P99.9:          99.9% запросов быстрее этого

Примеры:
API endpoint:
  P50: 50ms
  P95: 200ms
  P99: 1000ms
  
Если P99 > 5s — это проблема!

Throughput (Пропускная способность):

reqs/sec = total_requests / total_time

Пример:
  API может обработать 1000 реквестов в сек
  Реальная нагрузка: 500 реквестов в сек
  Используется: 50% capacity
  
Если реальная нагрузка > 80% capacity — нужен скейлинг!

Инструменты для оценки

SonarQube (Static Analysis)

# Сканировать проект
sonar-scanner \
  -Dsonar.projectKey=my-app \
  -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000

Что измеряет:

• Code Smells (плохие практики)
• Bugs (потенциальные ошибки)
• Vulnerabilities (уязвимости)
• Coverage (% кода с тестами)
• Duplications (дублирование)

Red flags:

• Coverage < 80%
• Blocker issues > 0
• Critical issues > 0

APM (Application Performance Monitoring)

Примеры: Datadog, New Relic, Dynatrace, Elastic APM

APM собирает:
1. Response times
2. Error rates
3. Database query times
4. External API calls
5. Resource usage (CPU, Memory)
6. Distributed traces

Типичный дашбоард:

┌─────────────────────────────────┐
│ Throughput: 5,234 req/s         │
│ Avg Response: 145ms             │
│ P95 Response: 450ms             │
│ Error Rate: 0.02%               │
│ CPU: 65%                        │
│ Memory: 78%                     │
│ Active Connections: 12,345      │
└─────────────────────────────────┘

Анализ логов (Log Analysis)

Инструменты: ELK Stack, Datadog, Splunk

Что искать:

# ПЛОХО: много ERROR логов
logger.error("Database connection failed")
logger.error("Payment API timeout")
logger.error("Cache miss")

# Если ERROR логов > 100/сек — это проблема!

# ХОРОШО: мало ERROR, есть mcontext
logger.error("Payment API timeout", extra={
    "user_id": 123,
    "api": "stripe",
    "duration_ms": 5000,
    "retry_count": 3
})

Сравнение версий (Version Comparison)

Перед деплоем новой версии:

Version 1.0.0 (текущая в production):
  Throughput: 5000 req/s
  Avg Response: 145ms
  Error Rate: 0.01%
  
Version 1.1.0 (новая версия в staging):
  Throughput: 4800 req/s (↓ 4%)
  Avg Response: 180ms (↑ 24%)
  Error Rate: 0.03% (↑ 3x!)
  
Вывод: НЕ деплоить! Есть регрессия.

Моніторинг ошибок (Error Tracking)

Инструменты: Sentry, Rollbar, Bugsnag

Типичный alert:

Error: "NullPointerException in UserService.get()"
- Occurs: 50 times in last 5 minutes
- Affected users: 234
- First seen: 10 minutes ago
- Status: ACTIVE

Stack trace:
  at UserService.get(line 42)
  at UserController.getUser(line 15)
  at Handler.handle(line 28)

Действие: Если Error Rate > 0.1% — включить alert и пейджить on-call!

Проверка специфичных компонентов

1. Database Health

-- Проверить медленные запросы
SELECT query, mean_time, max_time, calls
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

-- Если query > 1 сек:
-- 1. Добавить индекс
-- 2. Переписать запрос
-- 3. Добавить кэш

2. Cache Hit Ratio

Cache hit ratio = cache_hits / (cache_hits + cache_misses)

Пример: Redis кэш
- Hit ratio: 85% — хорошо
- Hit ratio: 50% — среднее, нужно больше data
- Hit ratio: 10% — плохо, нужна другая стратегия

3. Queue Depth (для асинхронных очередей)

Использование RabbitMQ/Kafka:
- Queue depth: 100 сообщений
- Processing rate: 50 msg/sec
- ETA to clear: 2 сек

Если Queue depth растёт (> 10,000):
- Workers не справляются
- Нужно добавить больше workers

4. Third-party API Health

Провайдер: Stripe API
- Status: UP
- Last checked: 30 sec ago
- Latency: 250ms (avg)
- Errors: 0 in last hour

Провайдер: Email service
- Status: DEGRADED
- Latency: 5000ms (avg) — норма 500ms
- Errors: 0.5% — норма < 0.01%

Действие: Переключиться на secondary email provider!

Правило трёх сигм (3-Sigma Rule)

Для обнаружения аномалий:

Норма (последние 7 дней):
- Mean response time: 150ms
- StdDev: 20ms

3-sigma bound = Mean + 3*StdDev = 150 + 60 = 210ms

Если response time > 210ms — это аномалия!
Alert: "Response time spike detected: 450ms (3x normal)"

Чек-лист оценки качества кода

□ Static Analysis (SonarQube):
  □ Coverage >= 80%
  □ No blocker issues
  □ No critical issues
  □ Code duplication < 5%

□ Runtime Metrics:
  □ Error rate < 0.01%
  □ P95 response < 1s
  □ Throughput >= expected
  □ CPU usage < 80%
  □ Memory usage < 85%

□ Database:
  □ No slow queries (> 1s)
  □ Cache hit ratio > 80%
  □ Connection pool healthy

□ Logs:
  □ ERROR count < 10/min
  □ WARNING count < 100/min
  □ No concerning patterns

□ External Services:
  □ All third-party APIs UP
  □ No timeout issues
  □ Rate limits not exceeded

□ Security:
  □ No SQL injection attempts
  □ No XSS attempts detected
  □ HTTPS enforced
  □ No sensitive data in logs

Рекомендации по регулярности

Ежедневно:

• Мониторить error rate
• Проверять alert-ы
• Смотреть на response times

Еженедельно:

• SonarQube сканирование
• Review медленных запросов
• Analyze logs за неделю

Ежемесячно:

• Полный код review
• Capacity planning
• Performance trend analysis

Перед каждым деплоем:

• Сравнить метрики staging vs production
• Убедиться, что нет регрессии
• Проверить coverage increase

Совет System Analyst

1. Не доверяй только одной метрике — смотри на картину целиком
2. Error rate > 0.1% — это чрезвычайная ситуация
3. Response time tail (P99) важнее, чем average — пользователи чувствуют максимум
4. Кэш не замена плохому коду — сначала оптимизируй
5. Мониторь тренды, не абсолютные значения — рост 10% может быть проблемой
6. Алерты должны быть actionable — не создавай noise
7. APM инструменты дороги, но worth it — они экономят часы отладки

Хороший код — это не только красивый код, это код, который быстро работает в production и не вызывает панику в 3 ночи.