Парадокс разработки: чем меньше кода, тем дороже вы стоите. Сегодня о YAGNI

80% кода в типичном среднем проекте никогда не используется. Он просто лежит. Он усложняет поддержку, ломает сроки и тихо убивает вашу репутацию как разработчика.

И вот вопрос: зачем вы его пишете?

YAGNI - не про “лениться”. Он про выживание проекта

YAGNI расшифровывается: You Aren’t Gonna Need It. Или если на наш язык: Тебе это не понадобится.

Звучит банально. Но на практике это самый часто нарушаемый принцип среди Middle PHP-разработчиков.

И вот тут начинается самое интересное.

Вы можете возразить, что вы не пишете “лишний код”. Вы инвестируете в гипотетическое будущее, которого, скорее всего, не будет. )

Где именно вы нарушаете YAGNI

• “Сделаю универсальный сервис на всякий случай”
• “А вдруг потом добавим 5 типов оплаты”
• “Надо сразу заложить масштабирование”

Знакомо? И тут есть одна проблема.

Вы не знаете будущее проекта. Никто не знает.

И каждое такое “на всякий случай”:

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

Из практики

Небольшой e-commerce проект. Обычная задача. Каталог, корзина, оплата.

Разработчик решил “сделать правильно”:

• абстрактный слой оплаты
• интерфейсы под 5 провайдеров
• конфигурируемая стратегия

Через 6 месяцев проект использует один платежный метод. И не планирует расширение.

Результат:

• + over много времени разработки
• сложная логика
• баги при рефакторинге

И начинается боль.

Любое изменение требует понимания архитектуры, которая не приносит ценности.

Почему Middle-разработчики особенно уязвимы

Junior не знает как “правильно”.
Senior знает когда “правильно” не нужно.

А Middle?

Он уже умеет. Но еще не умеет останавливаться.

И это ловушка.

Вы хотите:

• писать “чистый код”
• строить архитектуру
• выглядеть профессионально

Но реальность другая.

Бизнес платит не за архитектуру. Бизнес платит за результат.

Как применять YAGNI на практике

Не теория, дам конкретные шаги.

1. Перед каждой абстракцией задайте вопрос

Есть ли сейчас минимум 2 реальных кейса?

Если нет, не делайте KISS в помощь.

2. Удаляйте “гипотетический код”

Если вы написали:

• расширяемую систему
• универсальный класс
• “на будущее”

Остановитесь. Спросите себя: где это используется прямо сейчас?

Если ответа нет, удаляйте.

3. Оптимизируйте только под текущую нагрузку

Не под миллионы пользователей. Не под гипотетический рост. А под текущую задачу. И вот тут многие ломаются.

Потому что кажется, что вы делаете “хуже”. Но на самом деле вы делаете лучше и для работы и для себя.

Важный парадокс

Чем проще код сейчас, тем быстрее вы адаптируетесь потом и наоборот.

Сложная “заранее продуманная” архитектура:

• ломается при реальных изменениях
• мешает гибкости
• замедляет команду

Открытая петля, о которой стоит подумать

Есть одна техника, которую используют сильные разработчики, но почти никто о ней не говорит.

Она позволяет:

• писать минимум кода
• не терять гибкость
• и при этом масштабироваться без боли

Секрет: отложенная архитектура

Не стройте систему сразу. Дайте ей вырасти.

Как это выглядит:

1. Пишите простой код под задачу
2. Ждете повторения кейса
3. Только тогда обобщаете

Это и есть зрелый подход. Не “предугадывать”, а реагировать.

Финальная мысль

YAGNI - это не про экономию времени. Это про контроль над сложностью.

И если коротко:

• не пишите код, который не нужен сейчас
• не проектируйте будущее, которого нет
• не усложняйте систему ради “красоты”

Потому что в реальности выигрывает не самый “умный” код.

А самый живучий и живучий, тот, что сделан просто.