YAGNI для начинающих: как масштабировать принцип «Вам это не понадобится» в реальных проектах

Принцип YAGNI (You Aren’t Gonna Need It — «Вам это не понадобится») — один из столпов экстремального программирования и гибкой разработки. На словах он прост: не добавляйте функциональность, пока она не понадобилась на самом деле. Но как только разработчик или команда пытаются следовать ему на практике, возникают вопросы: «А как же масштабируемость?», «А если потом будет сложно добавить?», «Мы же теряем в архитектуре!». В этой статье мы разберем, как правильно понимать и масштабировать YAGNI, особенно для начинающих команд, чтобы он приносил пользу, а не становился оправданием для халтуры.

YAGNI — это не призыв к написанию плохого кода или отказу от проектирования. Это принцип управления сложностью и борьбы с преждевременной оптимизацией. Его суть в том, что попытки угадать будущие требования и реализовать функциональность «на вырост» чаще всего приводят к переусложнению системы, увеличению сроков разработки, появлению неиспользуемого кода, который все равно придется переделывать, когда реальные требования станут известны. Вы тратите ресурсы на то, что, вероятно, никогда не понадобится, или понадобится в совершенно ином виде.

Для начинающих ключевая сложность — найти баланс между YAGNI и разумным проектированием. Вот практические шаги по масштабированию этого принципа. Во-первых, отделяйте архитектурные решения от функциональных излишеств. YAGNI борется со вторым. Заложить модульную структуру, четкие интерфейсы между компонентами, точки расширения — это не нарушение YAGNI, а профессиональное проектирование. А вот реализовывать в модуле «Пользователи» пять разных стратегий аутентификации, потому что «вдруг клиент захочет войти через паспорт», — это нарушение.

Во-вторых, используйте правило трех. Добавляйте абстракцию или общий механизм не при первом, а при третьем повторении похожего кода или требования. Первый случай — пишем конкретное решение. Второй похожий случай — задумываемся, копируем с изменениями. Третий — рефакторим, выделяя общую абстракцию. Это эмпирическое правило помогает не создавать абстракции «в вакууме», а выводить их из реальных потребностей проекта.

В-третьих, применяйте инкрементальное проектирование. Архитектура и дизайн системы должны развиваться вместе с кодом и новыми требованиями, а не быть зафиксированными в самом начале. Проводите короткие сессии проектирования перед началом реализации новой фичи (например, в формате «проектировочного паззла») и рефакторинг после ее добавления, чтобы «причесать» код и структуру под новые реалии.

В-четвертых, пишите тесты. Хорошее покрытие тестами дает уверенность для рефакторинга в будущем. Если вы следуете YAGNI и откладываете реализацию какой-то возможности, вы должны быть уверены, что сможете безопасно добавить ее позже, не сломав существующую функциональность. Тесты — ваш страховочный трос.

Как масштабировать YAGNI на уровень команды? Необходима культура и общие договоренности. Технический лид или архитектор должен на ревью кода мягко, но настойчиво задавать вопросы: «Для чего этот параметр? Он используется?», «Какое текущее требование покрывает этот абстрактный класс?». Важно донести, что простота и выполнение текущих требований — главный приоритет. Используйте пользовательские истории и критерии приемки (Acceptance Criteria) как фильтр: если функциональность не описана в истории и не нужна для ее выполнения, ее нет в текущей итерации.

Частый контраргумент: «Но мы делаем продукт для внешнего рынка, нам нужна гибкость!». YAGNI не противоречит гибкости. Наоборот, он ее повышает, снижая связанность и сложность кодовой базы. Гибкость обеспечивается не раздутыми интерфейсами с десятком методов, половина из которых заглушки, а чистым кодом, модульностью и покрытием тестами, которые позволяют быстро и безопасно вносить изменения.

Начинайте с малого. Возьмите за правило в следующем спринте или задаче сознательно отсечь одну гипотетическую «фичу на будущее», которую вам захочется добавить. Сфокусируйтесь только на том, что прямо запрошено в задаче. Проанализируйте результат: стало ли решение проще? Удалось ли сдать задачу быстрее? Понимание придет с практикой. YAGNI — это мышление, которое экономит самое ценное в разработке: время и концентрацию.