Принцип YAGNI (You Ain’t Gonna Need It) — «Тебе это не понадобится»

Часто на картинках с DRY и KISS мелькает еще один важный принцип — YAGNI. Он гласит: не добавляй функциональность, которая может понадобиться в будущем, но не нужна прямо сейчас.

Основные идеи YAGNI:
1️⃣ Не реализуй то, что не требуется сейчас — если нет конкретного ТЗ, не пиши код «на всякий случай».
2️⃣ Избегай ненужной сложности — лишний код усложняет поддержку и тестирование.
3️⃣ Оптимизируй только при необходимости — преждевременная оптимизация может навредить.
4️⃣ Экономи время и ресурсы — меньше лишнего кода = чище и понятнее архитектура.

Примеры нарушения YAGNI:

- Абстрактная архитектура «на будущее», которая никогда не пригодится.

- Параметры в функции, которые пока не используются.

- Сложная система логирования для одноразового скрипта.

Хороший принцип… но я его нарушаю в автотестах😅

Вот как и почему:

🔹 Генерация клиентов
Если писать клиенты вручную, логично описать только нужный контроллер для нужного API сервиса. Но я давно использую сгенерированные клиенты — и если генерировать, то все сразу.

🔹 Версии API (V1, V2, OLD и т. д.)
Контроллеры в разных версиях API могут называться одинаково, и появляются фикстуры вроде old_controller_api, v2_controller_api и т. п. Проще сразу сделать фасад, который объединит API (контроллеры) одного сервиса, где через точку можно доставать нужный, вместо того чтобы путаться в версиях контроллеров.

🔹 Обёртки над методами
Контракты меняются, и если не подготовиться, придётся переписывать все тесты, а не один метод-абстракцию. Поэтому я довольно часто добавляю еще один класс, в виде наследника от API клиента, в котором упрощаю интерфейс тестируемого метода.

Да, это усложняет проект, но зато даёт архитектуру, которую легко поддерживать годами.
А если все это генерировать это вовсе сводит трудозатраты к минимуму, задавая чёткие рамки проекта.

Вывод: YAGNI — хорошее правило, но иногда его можно нарушать осознанно. Главное — понимать, зачем.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы