КЕЙС:

Коллеги, небольшой клиент попросил внутреннюю CRM: клиенты, задачи, статусы, пара отчётов. Бюджет скромный, срок — две недели.

Стажёр предлагает: «Давайте честный MVC: роуты, контроллеры, модели, middleware, валидация, слои!» Звучит солидно. Но я посчитал: 15 сущностей, 3 экрана, 1 роль. Если строить дворец, не успеваем.

Выбрал классическое ООП: аккуратные классы, простые сервисы, тонкий слой БД. Без фреймворочной магии.


Что сделали:

— Client, Task, Status как сущности;
— ClientService и TaskService для логики;
— один входной файл с простым роутингом, PDO-обёртку и минимум зависимостей.


Почему это быстрее:

— меньше слоёв — меньше кода, который надо писать и отлаживать;
— не нужно спорить о «правильном» разделении ответственности там, где задача на один метод;
— правку в продакшене можно найти за 5 минут, а не блуждать по папкам.


Итог: рабочую версию отдали за 5 дней, поддержка занимает минуты, клиент доволен.

Спустя месяц клиент попросил экспорт в Excel. Добавили один метод в сервис и простой шаблон, а не переписывали половину проекта.

Важно: я не против паттернов. Для большого проекта с командой, ролями, API и сложными сценариями слои оправданы. Но для маленькой внутренней системы классическое ООП часто выигрывает у «архитектуры ради архитектуры».

Совет: выбирайте сложность под масштаб задачи. Лучше скучный рабочий код, чем красивый, но не сданный в срок.

Вот так. Идем кодить дальше! 🚀