YAGNI (You Aren't Gonna Need It) - «вам це не знадобиться»: не реалізовувати можливість, доки вона справді не потрібна.
KISS (Keep It Simple) - обирати найпростіше рішення, що розв'язує задачу.
Обидва - про боротьбу з передчасною складністю, але з різних боків: YAGNI - про що будувати (не будувати зайвого), KISS - про як (не ускладнювати те, що будуєте).
Типові порушення YAGNI:
- інтерфейс і три реалізації «на випадок, якщо колись зміниться платіжний провайдер»;
- налаштування й прапорці, які ніхто не просив;
- узагальнений «рушій правил» для двох правил знижок;
- мікросервіси для застосунку з однією командою й десятком користувачів;
- підтримка кількох баз даних, хоча застосунок ніколи не змінить базу.
Чому це дорого (за Фаулером):
- вартість побудови - час на непотрібне замість потрібного зараз;
- вартість затримки - потрібна функція виходить пізніше;
- вартість підтримки - кожен рядок треба читати, тестувати, оновлювати, і він ускладнює зміни поруч;
- вартість помилки прогнозу - коли можливість таки знадобиться, вона часто потрібна інакше, ніж її передбачили, і готову абстракцію доводиться ламати.
Важливе уточнення: YAGNI стосується можливостей, а не якості коду. Він не означає «не писати тестів», «не рефакторити» чи «не думати про структуру». Навпаки - чистий, протестований код дешево змінювати, коли нова вимога справді прийде. Саме це робить YAGNI безпечним.
Як це виглядає в Laravel-проєкті:
- спершу - Eloquent напряму в діях, без репозиторіїв «на майбутнє»;
- один клас-сервіс замість ієрархії стратегій, доки варіант один;
- конфігурація в
config/, а не адмінка налаштувань, доки її ніхто не змінює.
Коли передбачення виправдане: рішення, які дорого змінити потім - схема публічного API, формат даних, вибір основної бази, безпека. Тут думати наперед доречно; у внутрішньому коді - краще відкласти.