Что такое принцип YAGNI в разработке?

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

Суть принципа: Боритесь с желанием написать код "на всякий случай", основываясь на предположениях о будущих требованиях. Это ведет к:

• Росту сложности без реальной пользы.
• Увеличению времени на разработку и тестирование неиспользуемого кода.
• Накоплению технического долга, так как невостребованный код все равно требует поддержки.

Пример нарушения YAGNI (преждевременная абстракция):

// Создаем интерфейс и класс для логгера, хотя сейчас нужен только вывод в файл.
public interface ILogger { void Log(string message); }

public class FileLogger : ILogger
{
    public void Log(string message) => File.AppendAllText("app.log", message + "n");
}

// В коде везде используется зависимость от интерфейса ILogger.
public class OrderProcessor
{
    private readonly ILogger _logger;
    public OrderProcessor(ILogger logger) { _logger = logger; }
    // ...
}

Пример по YAGNI (реализуем только текущую потребность):

// Реализуем простой класс, решающий актуальную задачу.
public class Logger
{
    public void Log(string message) => File.AppendAllText("app.log", message + "n");
}

// Код зависит от конкретного, простого класса.
public class OrderProcessor
{
    private readonly Logger _logger;
    public OrderProcessor(Logger logger) { _logger = logger; }
    // ...
}

Когда можно отступить от YAGNI? Принцип не является догмой. Иногда его разумно нарушить, если:

1. Добавление абстракции (как в примере с интерфейсом) требует минимальных усилий (например, современные IDE делают это за секунды).
2. Вы абсолютно уверены в необходимости этой функциональности в самом ближайшем будущем (в рамках текущего спринта).
3. Речь идет о нефункциональных требованиях, таких как безопасность или наблюдаемость, где продуманная архитектура закладывается сразу.

Главный вывод: фокусируйтесь на реализации текущих user stories, а не на гипотетических сценариях.