Что такое YAGNI?

Что такое YAGNI?

YAGNI — это аббревиатура от англ. "You Aren't Gonna Need It" ("Вам это не понадобится"). Это принцип экстремального программирования (XP), который гласит: не добавляй функциональность, пока она действительно не потребуется.

Товары, код, проектирование — всё должно быть максимально простым и содержать только то, что необходимо для текущих требований.

Суть принципа YAGNI

Принцип YAGNI основан на следующих идеях:

• Не предугадывай будущее — разработчики часто добавляют функции "на будущее", хотя они могут никогда не понадобиться
• Избегай оверинжиниринга — излишняя абстракция и сложность замораживают проект
• Сосредоточься на текущих требованиях — делай только то, что необходимо сейчас
• Проще поддерживать — код без ненужного функционала легче понимать и модифицировать

Проблемы без YAGNI

Если не придерживаться принципа YAGNI:

// ❌ Плохо — оверинжиниринг
public class UserManager {
    private UserRepository repository;
    private UserValidator validator;
    private UserCache cache;
    private UserNotificationService notificationService;
    private UserAuditLogger auditLogger;
    private UserStatisticsCollector statisticsCollector;
    private UserRoleResolver roleResolver;
    private UserPermissionChecker permissionChecker;
    // ... ещё 10 зависимостей
    
    public User createUser(String email, String password) {
        // Вся эта логика может быть ненужной
    }
}

Правильный подход с YAGNI

// ✅ Хорошо — делаем только необходимое
public class UserManager {
    private UserRepository repository;
    private UserValidator validator;
    
    public User createUser(String email, String password) {
        validator.validate(email, password);
        User user = new User(email, password);
        return repository.save(user);
    }
}

Примеры оверинжиниринга

Пример 1: Излишняя генерализация интерфейсов

// ❌ Плохо — создаём абстракцию "на будущее"
public interface DataProcessor<T, R> {
    R process(T input);
    void cache(T input, R output);
    void logMetrics(T input, R output, long executionTime);
    void notifySubscribers(T input, R output);
    void validateInput(T input);
    void validateOutput(R output);
    // ... и ещё 20 методов
}

// ✅ Хорошо — простая реализация для текущих нужд
public interface DataProcessor<T, R> {
    R process(T input);
}

Пример 2: Множественные реализации одного класса

// ❌ Плохо — создаём паттерны "про запас"
public interface Logger {
    void log(String message);
}

public class ConsoleLogger implements Logger { /* ... */ }
public class FileLogger implements Logger { /* ... */ }
public class DatabaseLogger implements Logger { /* ... */ }
public class RemoteLogger implements Logger { /* ... */ }

// Но используем только ConsoleLogger!

// ✅ Хорошо — создаём реализацию, когда она действительно нужна
public class SimpleConsoleLogger implements Logger {
    @Override
    public void log(String message) {
        System.out.println(message);
    }
}

YAGNI vs Design Patterns

Нужно различать:

• Design Patterns — проверенные решения для известных проблем → используй, когда действительно есть проблема
• YAGNI — не добавляй функциональность "на будущее" → делай только то, что нужно сейчас

Когда можно игнорировать YAGNI

Есть исключения:

1. Известные требования — если точно знаешь, что будет нужно
2. Архитектурные основы — базовая структура приложения
3. Стандарты и соглашения — DDD, SOLID и другие принципы
4. Производительность — если оптимизация критична

Практическое применение YAGNI

// Сначала напиши простую версию
public class OrderProcessor {
    public void processOrder(Order order) {
        calculateTotal(order);
        saveOrder(order);
    }
    
    private void calculateTotal(Order order) {
        order.setTotal(order.getItems().stream()
            .mapToDouble(Item::getPrice)
            .sum());
    }
    
    private void saveOrder(Order order) {
        // save to DB
    }
}

// Если потом нужна дополнительная функциональность — добавишь её
// Но не добавляй заранее!

Ключевые выводы

• YAGNI помогает избежать оверинжиниринга и держать код простым
• Пиши код для текущих требований, а не для предполагаемого будущего
• Проще добавить функциональность позже, чем поддерживать ненужный код
• Сочетай YAGNI с другими принципами (SOLID, DRY, KISS)
• Refactoring позволяет улучшить архитектуру, когда это действительно нужно