Ответ
Принцип 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? Принцип не является догмой. Иногда его разумно нарушить, если:
- Добавление абстракции (как в примере с интерфейсом) требует минимальных усилий (например, современные IDE делают это за секунды).
- Вы абсолютно уверены в необходимости этой функциональности в самом ближайшем будущем (в рамках текущего спринта).
- Речь идет о нефункциональных требованиях, таких как безопасность или наблюдаемость, где продуманная архитектура закладывается сразу.
Главный вывод: фокусируйтесь на реализации текущих user stories, а не на гипотетических сценариях.
Ответ 18+ 🔞
А, слушай, вот есть такая штука — YAGNI. Расшифровывается как «You Aren't Gonna Need It», а по-нашему это звучит примерно как «Да нахуй это надо, тебе это не понадобится!». Суть проще пареной репы, но мозги выносит всем постоянно.
Вот смотри, сидишь ты, кодишь, и в голове: «А вдруг завтра клиенту взбредёт в голову не в файл логи писать, а в телеграм-канал? Надо сделать интерфейс ILogger, абстрактную фабрику логгеров и ещё хуй знает что!». И вот ты уже два дня хуяришь эту вселенскую абстракцию, а задача-то была — просто сообщение в файлик записать. И этот твой «архитектурный шедевр» потом десять лет висит мёртвым грузом, его никто не трогает, но поддерживать его надо, а он только жрёт время и нервы. Вот это и есть нарушение YAGNI. Ты сделал то, что тебе сейчас нахуй не упало.
Вот, например, как НЕ НАДО делать:
// Начинаем выёбываться с интерфейсом, хотя нужен один конкретный логгер
public interface ILogger { void Log(string message); }
public class FileLogger : ILogger
{
public void Log(string message) => File.AppendAllText("app.log", message + "n");
}
// И теперь весь наш код ебётся с этой абстракцией
public class OrderProcessor
{
private readonly ILogger _logger;
public OrderProcessor(ILogger logger) { _logger = logger; }
// ...
}А как надо-то? Да просто, блядь!
// Делаем ровно то, что просят: класс, который пишет в файл. Всё.
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; }
// ...
}Видишь разницу? В первом случае — это архитектурный онанизм, а во втором — рабочий, понятный код, который решает конкретную задачу сейчас. И если завтра реально понадобится слать логи в телеграм, вот тогда, ёпта, и будешь рефакторить. А до этого момента — не выёбывайся.
Конечно, это не догма, ебать её в сраку. Иногда можно и отступить. Ну, например:
- Если добавление этой гипотетической фичи — дело пяти минут. Сделал
Extract Interfaceв IDE — и похуй. - Если ты на 150% уверен, что это понадобится буквально завтра, в рамках текущего спринта. Но это должна быть не твоя фантазия, а реальное требование, которое уже согласовали.
- Если речь про безопасность или мониторинг — там иногда действительно лучше сразу заложить нормальный фундамент, а не потом всю систему переделывать.
А так — главный принцип: не гадай на кофейной гуще. Делай то, что нужно прямо сейчас, а не то, что может понадобиться когда-нибудь, возможно, если повезёт. Иначе так и будешь всю жизнь поддерживать код, который никому не упёрся, кроме твоего внутреннего архитектора-извращенца.
