Как сокращаешь технический долг?

Как сокращаешь технический долг?

Технический долг — это накопление неправильных решений, неоптимального кода и заброшенных рефакторингов, которые замедляют разработку в будущем. Сокращение технического долга требует стратегического подхода и постоянного внимания. Давайте разберём практические методы.

Понимание технического долга

1. Типы технического долга

"""
ТИПЫ ДОЛГА:

1. КОД:
   - Дублирование логики (copy-paste)
   - Огромные функции (>50 строк)
   - Плохие имена переменных
   - Отсутствие документации
   - Magic numbers без констант

2. АРХИТЕКТУРА:
   - Слабая модульность
   - Жёсткие зависимости
   - Монолитные структуры
   - Нарушение SOLID принципов

3. ТЕСТЫ:
   - Низкое покрытие (<80%)
   - Медленные тесты
   - Хрупкие тесты (падают при рефакторинге)
   - Отсутствие критических тестов

4. ДОКУМЕНТАЦИЯ:
   - Устаревшая документация
   - API без примеров
   - Отсутствие README
   - Нет схем и диаграмм

5. ИНФРАСТРУКТУРА:
   - Старые зависимости
   - Нелицензируемые библиотеки
   - Неэффективные алгоритмы
   - Нет мониторинга
"""

Идентификация и приоритизация

2. Находить и оценивать долг

import ast
import os
from pathlib import Path

class TechnicalDebtDetector:
    """Класс для обнаружения техдолга в коде"""
    
    def __init__(self, project_path: str):
        self.project_path = project_path
        self.issues = []
    
    def check_file_complexity(self, filepath: str) -> dict:
        """Найти сложные функции"""
        with open(filepath, 'r') as f:
            try:
                tree = ast.parse(f.read())
            except SyntaxError:
                return {}
        
        issues = {}
        for node in ast.walk(tree):
            if isinstance(node, ast.FunctionDef):
                # Считаем количество строк
                lines = node.end_lineno - node.lineno
                if lines > 50:  # Функция больше 50 строк
                    issues[node.name] = {
                        'type': 'high_complexity',
                        'lines': lines,
                        'suggestion': 'Разделить на несколько функций'
                    }
                
                # Проверяем количество параметров
                if len(node.args.args) > 4:
                    issues[node.name] = {
                        'type': 'too_many_params',
                        'params': len(node.args.args),
                        'suggestion': 'Использовать объект конфигурации'
                    }
        
        return issues

# Использование
detector = TechnicalDebtDetector("./my_project")
issues = detector.check_file_complexity("services.py")

# Пример вывода:
# {
#     'process_payment': {
#         'type': 'high_complexity',
#         'lines': 120,
#         'suggestion': 'Разделить на несколько функций'
#     }
# }

Практический план по сокращению долга

3. Стратегический подход

from enum import Enum
from dataclasses import dataclass
from typing import List

class Priority(Enum):
    CRITICAL = 1  # Блокирует разработку
    HIGH = 2      # Замедляет разработку
    MEDIUM = 3    # Может ждать
    LOW = 4       # Улучшение

@dataclass
class DebtItem:
    title: str
    description: str
    priority: Priority
    effort_hours: int  # Сколько часов на исправление
    impact: str  # Как это повлияет на систему
    owner: str = None  # Кто отвечает

class DebtManagement:
    """Управление техдолгом"""
    
    def __init__(self):
        self.items: List[DebtItem] = []
    
    def add_debt(self, item: DebtItem):
        """Добавить элемент долга"""
        self.items.append(item)
    
    def prioritize(self) -> List[DebtItem]:
        """Отсортировать по приоритету"""
        return sorted(
            self.items,
            key=lambda x: (x.priority.value, -x.impact_score())
        )
    
    def plan_sprint(self, available_hours: int) -> List[DebtItem]:
        """Спланировать работу на спринт"""
        sorted_items = self.prioritize()
        sprint_items = []
        total_hours = 0
        
        for item in sorted_items:
            if total_hours + item.effort_hours <= available_hours:
                sprint_items.append(item)
                total_hours += item.effort_hours
        
        return sprint_items

# Использование
debt_mgmt = DebtManagement()

debt_mgmt.add_debt(DebtItem(
    title="Рефакторить payment_service.py",
    description="Функция process_payment занимает 150 строк",
    priority=Priority.CRITICAL,
    effort_hours=8,
    impact="Ускорит разработку новых фич на 30%",
    owner="team-backend"
))

debt_mgmt.add_debt(DebtItem(
    title="Добавить type hints",
    description="Проект почти без типизации",
    priority=Priority.HIGH,
    effort_hours=16,
    impact="Поймём баги быстрее, улучшим IDE support",
    owner="team-backend"
))

# Получить элементы для спринта (20 часов)
sprint_items = debt_mgmt.plan_sprint(20)

Систематический рефакторинг

4. Безопасный рефакторинг

import unittest
from typing import Callable

class SafeRefactoring:
    """Паттерн безопасного рефакторинга"""
    
    @staticmethod
    def refactor_with_tests(
        old_code: Callable,
        new_code: Callable,
        test_cases: list
    ) -> bool:
        """
        Рефакторить с гарантией - сначала написать тесты!
        """
        # ШАГ 1: Убедиться, что старый код полностью протестирован
        print("1. Запуск тестов на старом коде...")
        for test_input, expected_output in test_cases:
            result = old_code(test_input)
            assert result == expected_output, f"Тест не пройден: {test_input}"
        print("   OK - старый код работает корректно")
        
        # ШАГ 2: Написать новый код (рефакторинг)
        print("2. Реализация нового кода...")
        
        # ШАГ 3: Запустить те же тесты на новом коде
        print("3. Запуск тестов на новом коде...")
        for test_input, expected_output in test_cases:
            result = new_code(test_input)
            assert result == expected_output, f"Новый код не прошёл: {test_input}"
        print("   OK - новый код работает идентично")
        
        return True

# Пример: Рефакторинг функции расчёта скидки
def old_calculate_discount(total: float, is_vip: bool) -> float:
    """Старый код - сложный для понимания"""
    if total > 100:
        if is_vip:
            d = total * 0.2
        else:
            d = total * 0.1
    else:
        if is_vip:
            d = total * 0.1
        else:
            d = total * 0.05
    return total - d

def new_calculate_discount(total: float, is_vip: bool) -> float:
    """Новый код - понятный и поддерживаемый"""
    VIP_DISCOUNT_LARGE = 0.2  # Скидка VIP для больших заказов
    REGULAR_DISCOUNT_LARGE = 0.1
    VIP_DISCOUNT_SMALL = 0.1  # Скидка VIP для малых заказов
    REGULAR_DISCOUNT_SMALL = 0.05
    
    if total > 100:
        discount_rate = VIP_DISCOUNT_LARGE if is_vip else REGULAR_DISCOUNT_LARGE
    else:
        discount_rate = VIP_DISCOUNT_SMALL if is_vip else REGULAR_DISCOUNT_SMALL
    
    discount = total * discount_rate
    return total - discount

# Тесты
test_cases = [
    (50, False, 47.5),    # 50 - 2.5
    (50, True, 45.0),     # 50 - 5
    (150, False, 135.0),  # 150 - 15
    (150, True, 120.0),   # 150 - 30
]

SafeRefactoring.refactor_with_tests(
    old_calculate_discount,
    new_calculate_discount,
    test_cases
)

Автоматизация проверок

5. Инструменты для обнаружения долга

"""
ИНСТРУМЕНТЫ PYTHON:

1. КАЧЕСТВО КОДА:
   - pylint: Проверка стиля и потенциальных ошибок
   - flake8: PEP8 compliance и ошибки
   - black: Автоматическое форматирование
   - isort: Сортировка импортов

2. ТИПИЗАЦИЯ:
   - mypy: Static type checking
   - pyright: Type checker от Microsoft
   - pydantic: Runtime validation

3. ТЕСТЫ:
   - pytest: Фреймворк тестирования
   - coverage: Покрытие кода тестами
   - pytest-cov: Coverage для pytest

4. СЛОЖНОСТЬ:
   - radon: Cyclomatic complexity
   - cohesion: Анализ связанности кода

5. БЕЗОПАСНОСТЬ:
   - bandit: Проверка уязвимостей
   - safety: Проверка зависимостей

6. ЗАВИСИМОСТИ:
   - pip-audit: Поиск уязвимостей в зависимостях
   - pipenv: Управление зависимостями
"""

# Пример конфигурации pre-commit hook
pre_commit_config = '''
repos:
  - repo: https://github.com/psf/black
    rev: 23.1.0
    hooks:
      - id: black

  - repo: https://github.com/PyCQA/flake8
    rev: 6.0.0
    hooks:
      - id: flake8
        args: ['--max-line-length=100']

  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.0.0
    hooks:
      - id: mypy

  - repo: https://github.com/PyCQA/isort
    rev: 5.12.0
    hooks:
      - id: isort
'''

Непрерывное улучшение (CI/CD)

6. Автоматизация в pipeline

# Пример CI/CD конфигурации (.github/workflows/quality.yml)

quality_workflow = """
name: Code Quality

on: [push, pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.11'
      
      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install black flake8 mypy coverage pytest
      
      - name: Check code style (Black)
        run: black --check .
      
      - name: Lint with flake8
        run: flake8 . --max-line-length=100 --statistics
      
      - name: Type checking (mypy)
        run: mypy . --ignore-missing-imports
      
      - name: Run tests with coverage
        run: pytest --cov=. --cov-report=xml
      
      - name: Upload coverage
        uses: codecov/codecov-action@v3
        with:
          files: ./coverage.xml
"""

Культура и процессы

7. Социальные аспекты снижения долга

"""
ПРОЦЕССЫ ДЛЯ СНИЖЕНИЯ ДОЛГА:

1. CODE REVIEW:
   Обязательный review ДО merge в main
   Обсуждение альтернатив
   Обучение молодых разработчиков
   Предотвращение долга на этапе создания

2. ТЕХДОЛГ БЭКЛОГ:
   Отдельный бэклог для техдолга
   20-30% спринта на техдолг
   Регулярный рефакторинг
   Не откладывать "на потом"

3. ДОКУМЕНТИРОВАНИЕ:
   README для каждого модуля
   Docstrings на все функции
   ADR (Architecture Decision Records)
   Диаграммы архитектуры

4. МЕТРИКИ:
   Отслеживать покрытие тестами
   Сложность функций (cyclomatic)
   Время на исправление бага
   Time to market новых фич

5. ОБУЧЕНИЕ:
   Code review sessions
   Architecture workshops
   Паттерны проектирования
   Best practices
"""

Реальный пример: Снижение долга в проекте

8. Case Study

from datetime import datetime, timedelta
from enum import Enum

class ProjectMetrics:
    """Отслеживание метрик проекта"""
    
    def __init__(self, project_name: str):
        self.project_name = project_name
        self.metrics = {
            'test_coverage': 0.65,  # 65%
            'avg_function_lines': 45,
            'technical_debt_items': 23,
            'avg_time_to_fix_bug': 4,  # часов
            'avg_time_to_feature': 8,  # часов
        }
    
    def report_after_6_months(self):
        """Результаты после 6 месяцев работы над долгом"""
        return {
            'test_coverage': 0.92,  # +27%
            'avg_function_lines': 25,  # -44%
            'technical_debt_items': 3,  # -87%
            'avg_time_to_fix_bug': 1.5,  # -62%
            'avg_time_to_feature': 5,  # -37%
        }

# Результаты
initial = ProjectMetrics("MyProject")
final = initial.report_after_6_months()

"""
РЕЗУЛЬТАТЫ ЗА 6 МЕСЯЦЕВ:

До:                      После:
- Покрытие 65%          - Покрытие 92%         (+27%)
- Функции по 45 строк   - Функции по 25 строк  (-44%)
- 23 элемента долга     - 3 элемента долга     (-87%)
- 4 часа на фикс баги   - 1.5 часа на фикс     (-62%)
- 8 часов на фичу       - 5 часов на фичу      (-37%)

ВЫВОДЫ:
✓ Разработка ускорилась на 37%
✓ Качество существенно улучшилось
✓ Время на исправление багов снизилось на 62%
✓ Новые разработчики быстрее адаптируются
✓ Код стал более поддерживаемым
"""

Таким образом, сокращение технического долга требует:

1. Измерения — отслеживать метрики качества
2. Приоритизации — выбирать наиболее критичное
3. Планирования — выделять время в спринт
4. Процессов — code review, тесты, документация
5. Автоматизации — linting, type checking, CI/CD
6. Культуры — команда должна ценить качество