5 ошибок в Laravel-проекте, которые потом больно чинить на проде
Первое — смешивать бизнес-логику с контроллерами. Когда в action лежат запросы к БД, условия, форматирование и отправка событий, проект быстро становится хрупким. Логику лучше выносить в сервисы, actions или domain-слой, а контроллер оставлять тонким.
Второе — полагаться на Eloquent везде. Для сложных выборок, массовых апдейтов и отчётов он удобен, но не всегда экономичен. Если запрос тяжёлый, проверь SQL, индексы и количество round-trip к базе; иногда Query Builder или raw-запрос честнее и быстрее.
Третье — игнорировать очереди и idempotency. Любая задача, которую можно повторить без катастрофы, должна уметь пережить retry. Для писем, webhooks, синхронизаций и биллинга это не опция, а базовая защита от дублей и гонок ⚙️
Четвёртое — держать тесты только на happy path. Если не проверять пустые данные, ошибки внешних API и конкурирующие запросы, баги всплывут в самый неудобный момент. Минимум — feature-тесты на критические сценарии и отдельные проверки на правила валидации.
Если проект уже растёт, начни с аудита контроллеров, очередей и самых тяжёлых запросов: обычно там и лежат первые часы будущей экономии.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
5 ошибок в Laravel-проекте, которые потом больно чинить на проде
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.