Откуда берется технический долг

Откуда берется технический долг

Технический долг — это скопившиеся проблемы в коде, архитектуре и процессах. Давай разберемся откуда он появляется:

1. Спешка и дедлайны

Самая частая причина. Когда есть давление на время:

# ❌ Быстро (но плохо)
def process_user_data(data):
    # Без проверок, без тестов, просто работает
    user = data['user']
    email = data['email']
    age = int(data['age'])  # Может быть ошибка
    # ... 200 строк спагетти-кода
    return {"status": "ok"}

# ✓ Медленно (но правильно)
from pydantic import BaseModel, ValidationError

class UserData(BaseModel):
    user: str
    email: str
    age: int

def process_user_data(data: UserData):
    # С валидацией, типами, тестами
    return {"status": "ok", "user": data.user}

Результат: код работает, но требует рефакторинга.

2. Недостаток знаний / опыта

Молодые разработчики пишут неоптимальный код:

# ❌ Неправильно
users = []  # Загружаем в память
for row in database.fetch_all():
    if row['is_active']:
        users.append(row)
# Memory usage: очень высокая для большого датасета

# ✓ Правильно
users = database.fetch_active_users()  # SQL filter
# Или с ORM
users = session.query(User).filter(User.is_active == True).all()

Результат: неэффективный код, который потом переписывают.

3. Меняющиеся требования

Бизнес требования постоянно меняются:

# Версия 1
class Order:
    def __init__(self, items):
        self.items = items
        self.total = sum(item.price for item in items)

# Версия 2 — нужны скидки
class Order:
    def __init__(self, items, discount=0):
        self.items = items
        self.discount = discount
        self.total = sum(item.price for item in items) * (1 - discount)

# Версия 3 — нужны налоги
class Order:
    def __init__(self, items, discount=0, tax_rate=0.1):
        self.items = items
        self.discount = discount
        self.tax_rate = tax_rate
        subtotal = sum(item.price for item in items) * (1 - discount)
        self.total = subtotal * (1 + tax_rate)

# ... это растёт и становится chaos

Результат: класс становится сложным и хрупким.

4. Отсутствие тестов

Без тестов трудно рефакторить, поэтому код скапливается:

# ❌ Без тестов
def calculate_discount(price, user_type):
    if user_type == "gold":
        return price * 0.8
    elif user_type == "silver":
        return price * 0.9
    else:
        return price
# Никто не знает, что здесь правильно, страшно менять

# ✓ С тестами
def calculate_discount(price, user_type):
    discounts = {"gold": 0.2, "silver": 0.1}
    return price * (1 - discounts.get(user_type, 0))

# И есть тесты, поэтому рефакторинг безопасен
assert calculate_discount(100, "gold") == 80
assert calculate_discount(100, "silver") == 90
assert calculate_discount(100, "bronze") == 100

5. Отсутствие документации

Без документации никто не понимает зачем это нужно:

# ❌ Без документации
def process_transaction(data):
    if data['amount'] > 10000:
        # Зачем эта проверка? Никто не знает
        notify_fraud_team(data)
    return save_to_db(data)

# ✓ С документацией
def process_transaction(data):
    """
    Обрабатывает транзакцию.
    
    Если сумма > 10,000 — уведомляет команду fraud detection
    согласно политике AML (Anti-Money Laundering).
    """
    if data['amount'] > 10000:
        notify_fraud_team(data)
    return save_to_db(data)

6. Копипаста кода

Вместо переиспользования, копируют и модифицируют:

# ❌ Копипаста
class UserValidator:
    def validate(self, user):
        if not user['email']:
            raise ValueError("Email required")
        if not user['password']:
            raise ValueError("Password required")
        if len(user['password']) < 8:
            raise ValueError("Password too short")

class AdminValidator:
    def validate(self, admin):
        if not admin['email']:  # Повтор
            raise ValueError("Email required")
        if not admin['password']:  # Повтор
            raise ValueError("Password required")
        if len(admin['password']) < 12:  # Разная логика
            raise ValueError("Password too short")

# ✓ DRY (Don't Repeat Yourself)
class Validator:
    def validate_email(self, email):
        if not email:
            raise ValueError("Email required")
    
    def validate_password(self, password, min_length=8):
        if not password:
            raise ValueError("Password required")
        if len(password) < min_length:
            raise ValueError("Password too short")

7. Работающий, но плохо спроектированный код

Код работает, поэтому «не трогаем»:

# ❌ Плохой дизайн, но работает
class UserManager:
    def __init__(self):
        self.users = []
        self.logger = Logger()
        self.email_service = EmailService()
        self.database = Database()
        # Слишком много ответственности
    
    def create_user(self, name, email):
        # создание
        # валидация
        # отправка письма
        # логирование
        # сохранение в БД
        # всё в одном методе
        pass

# ✓ Правильный дизайн (SOLID)
class UserManager:
    def __init__(self, repository: UserRepository, events: EventBus):
        self.repository = repository
        self.events = events
    
    def create_user(self, command: CreateUserCommand) -> User:
        user = User.create(command.name, command.email)
        self.repository.save(user)
        self.events.publish(UserCreatedEvent(user))
        return user

8. Отсутствие code review

Без review плохой код пролезает в production:

# ❌ Никто не заметил
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"  # SQL injection!
    return db.execute(query)

# ✓ С code review заметили
def get_user(user_id):
    return db.execute("SELECT * FROM users WHERE id = ?", (user_id,))

9. Быстрое растущие проекты

Проект растёт быстрее, чем улучшается архитектура:

Месяц 1:  Простой скрипт (100 строк)
Месяц 3:  Нужны микросервисы, но кода писали как в одном файле
Месяц 6:  Нужна кластеризация, кэширование, но архитектура для стартапа
Месяц 12: Нужен рефакторинг, но некогда (дедлайны)

10. Неправильный выбор технологии

Выбрали не оптимальный инструмент:

# ❌ Flask для high-load системы
app = Flask(__name__)
# Потом понадобился async, WebSocket, но Flask не подходит

# ✓ FastAPI с самого начала
app = FastAPI()

Где технический долг самый дорогой

1. Production системы — даже малая ошибка стоит денег
2. Critical path — если код на critical path, нужно его оптимизировать
3. Часто меняющийся код — если меняется 10 раз в месяц, должен быть идеален
4. Опасный код — безопасность, финансы, здоровье

Как управлять техническим долгом

Профилактика:

• Code review перед merge
• Автоматизированные тесты
• Linting и type checking
• Архитектурные решения в начале

Лечение:

• Регулярные спринты на рефакторинг
• Метрики качества кода (coverage, complexity)
• Поддерживаемая документация
• Постоянное улучшение

Вывод

Технический долг появляется из-за:

• Спешки (50%)
• Недостатка опыта (20%)
• Отсутствия тестов и документации (15%)
• Плохой архитектуры (10%)
• Меняющихся требований (5%)

Главное правило: лучше потратить время на качество сейчас, чем платить процентами на технический долг потом.