Есть ли долги

# Технический долг в разработке

Да, техдолг — это ключевая концепция в разработке ПО, которая часто возникает при работе в реальных проектах.

Что такое технический долг?

Технический долг (Technical Debt) — это накопление проблем в коде, которые возникают из-за:

• Спешки в разработке
• Неправильных архитектурных решений
• Отсутствия рефакторинга
• Устаревших технологий
• Недостаточного тестирования

Аналогия: как финансовый долг, техдолг "растёт" с процентами — со временем его становится всё дороже выплачивать.

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

1. Долг кода (Code Debt)

// Плохой код - техдолг
@Service
public class UserService {
    public void process(List<Map<String, Object>> data) {  // Нет типизации
        for (int i = 0; i < data.size(); i++) {
            Object obj = data.get(i);
            if (obj != null) {
                String name = (String) ((Map) obj).get("name");  // Небезопасно
                String email = (String) ((Map) obj).get("email");
                // Дублирование кода
                if (name != null && !name.isEmpty()) {
                    // Обработка...
                }
            }
        }
    }
}

// После уплаты долга - чистый код
@Service
public class UserService {
    public void processUsers(List<UserRequest> users) {
        users.stream()
            .filter(this::isValid)
            .forEach(this::processUser);
    }
    
    private boolean isValid(UserRequest user) {
        return user.getName() != null && !user.getName().isEmpty() &&
               user.getEmail() != null && !user.getEmail().isEmpty();
    }
    
    private void processUser(UserRequest user) {
        // Логика обработки
    }
}

2. Архитектурный долг

// Монолит - множество зависимостей, сложно модифицировать
@Service
public class OrderService {
    private final Database database;
    private final EmailService emailService;
    private final PaymentGateway payment;
    private final InventoryManager inventory;
    private final NotificationService notification;
    private final ReportGenerator report;
    private final AuditLogger audit;
    // 50+ методов в одном классе
}

// После уплаты долга - микросервисная архитектура
// OrderService → ответствен только за заказы
// Остальное → отдельные сервисы

3. Долг в тестировании

// Без тестов - техдолг
@Service
public class ComplexBusinessLogic {
    public Order calculateDiscount(Order order) {
        // Сложная логика, но нет тестов
        // Изменения в этом методе могут сломать что-то
        return order;
    }
}

// Покрыто тестами - долг уплачен
@SpringBootTest
public class OrderDiscountTest {
    @Test
    public void testStandardDiscount() { ... }
    
    @Test
    public void testBulkDiscount() { ... }
    
    @Test
    public void testLoyal CustomerDiscount() { ... }
}

4. Долг в документации

// Без документации
public void doSomething(int x, String y) {
    // Что это делает? Что означают параметры? Какие исключения?
}

// С документацией
/**
 * Обновляет пользовательский профиль.
 * 
 * @param userId идентификатор пользователя (не может быть null)
 * @param profileData JSON с данными профиля
 * @return обновленный профиль
 * @throws IllegalArgumentException если userId < 0
 * @throws UserNotFoundException если пользователь не найден
 */
public UserProfile updateProfile(Long userId, String profileData) { ... }

5. Долг в зависимостях

// Устаревшие версии - техдолг
pom.xml:
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>2.0.0</version>  <!-- Java 2022, поддержка закончилась -->
</dependency>

// Современные версии - долг уплачен
<version>3.2.0</version>  <!-- Последняя версия, полная поддержка -->

Почему техдолг возникает?

1. Спешка (Часто)

Дедлайн: завтра! →  Писем код быстро, без рефакторинга → Техдолг

2. Неправильные дизайн-решения

// Решение ради сегодняшних требований
public String generateReport(User user, Order order, Inventory inv) {
    return user.getName() + " order " + order.getId() + " items " + inv.count();
}

// Через месяц нужен новый формат + локализация
// Это создаёт техдолг - нужна переработка

3. Отсутствие рефакторинга

"Если оно работает, не трогай" → Код становится всё хуже → Техдолг растёт

Как измерить техдолг?

Инструменты

# SonarQube - анализирует код
./sonar-scanner -Dsonar.projectKey=my-app

# Code coverage - процент покрытия тестами
maven jacoco:report

# Cyclomatic complexity - сложность методов
# Время на запуск тестов - медленные тесты = долг

Метрики

- Дублирование кода: > 5% = срочно уплачивать
- Покрытие тестами: < 80% = техдолг
- Время запуска тестов: > 10 мин = долг
- Методы с complexity > 10: = долг

Как управлять техдолгом?

1. Предотвращение

// Code review - ловить долг до commit'а
// SonarQube в CI/CD - автоматическая проверка
// Unit тесты - защита от регресса

2. Баланс: скорость vs качество

Yes: Быстро + неидеально (но покрыто тестами)
No:  Идеально медленно (проект не успеет)
No:  Очень быстро + без тестов (техдолг взрывается)

3. Регулярный рефакторинг

Sprint: 80% функции + 20% рефакторинга (техдолг)

4. Боевой план уплаты долга

1. Идентифицировать (SonarQube, code review)
2. Приоритизировать (что больше всего замедляет разработку?)
3. Планировать (выделить 20% спринта на рефакторинг)
4. Выполнить (тесты → рефакторинг → проверка)
5. Мониторить (не допустить нового долга)

Пример из реальности

До (Техдолг = высокий)

// 500 строк в одном классе
// Нет тестов
// Старые паттерны
// Дублирование кода
// Время разработки: 1 новая фича = 5 дней

После (Техдолг уплачен)

// Разделено на 10 классов
// 90% покрытие тестами
// Clean code + SOLID
// DRY принципы
// Время разработки: 1 новая фича = 1 день

Вывод

Технический долг — не враг, а неизбежное явление разработки. Ключ — управлять им:

1. Принимайте решения осознанно — иногда долг оправдан (быстрый MVP)
2. Не игнорируйте долг — он растёт с процентами
3. Выделяйте время на рефакторинг — 20% спринта
4. Автоматизируйте проверку — SonarQube, unit тесты
5. Обучайте команду — Clean Code, SOLID, TDD

В здоровом проекте техдолг управляем, а не подавляет разработку.