Иногда в проект заходишь, открываешь routes/web.php и видишь там полжизни: SQL в контроллере, бизнес-логика во вьюхах, фасады отовсюду. Это нормальная ситуация для старого Laravel-проекта. Важно не сломать всё в первый же день.

Расскажу, как я подхожу к легаси на Laravel и какие сложности там чаще всего всплывают.

1. Главная проблема легаси: страх трогать код

Типичные признаки: • контроллеры на 500+ строк с кучей if и foreach • модели знают всё обо всём (и бизнес-логика, и запросы, и события) • никакого разделения слоёв: контроллер → модель → вьюха, всё вперемешку • тестов нет, максимум пара сломанных unit-тестов «из коробки»

Сложность не в том, чтобы «написать лучше», а в том, что любой фикс может что-то отломать, а проверить нечем.

2. Первое, что я делаю: инвентаризация, а не переписывание

Я никогда не начинаю легаси с «перепишем всё на чистую архитектуру».

Сначала: • смотрю версии PHP и Laravel, список пакетов • строю картинку маршрутов (php artisan route:list) • отмечаю критичные сценарии: • авторизация • заказ/оплата • формы заявок • включаю нормальные логи: LOG_CHANNEL=daily, debug в нужном окружении

Задача этапа: понять, куда нельзя лезть без каски.

3. Больные места в легаси-Laravel

Чаще всего именно тут: • толстые контроллеры, которые: • тянут данные, • принимают решения, • отправляют почту, • рисуют вьюху • «магия» через фасады и глобальные хелперы, зависимости неясны • запросы к БД прямо в Blade-шаблонах • странные миграции: дропы, переименования, «горячие фиксы» в проде • ручной SQL вместо нормальных Eloquent-реляций и индексов

Сложность: любое изменение затрагивает сразу несколько слоёв.

4. Как я начинаю лечить: маленькие безопасные шаги

Последовательность примерно такая: 1. Оборачиваю критичный функционал в минимальные тесты Даже простые feature-тесты на happy-path уже дают защиту. 2. В самых страшных контроллерах: • выношу куски логики в отдельные методы/классы (Service/Action) • ничего не меняю по смыслу, только раскладываю 3. Вместо фасадной магии аккуратно завожу зависимости через DI: • сначала в конструктор контроллера • потом в сервисы 4. Любой новый код пишу по правилам, даже если вокруг болото: • FormRequest для валидации • Resource для ответа • чёткие DTO/модели запросов

Идея: не «очистить всё», а постепенно строить оазисы нормального кода.

5. Версии и обновления: отдельная головная боль

Частая сложность: Laravel 5.x, PHP 7.x, куча старых пакетов.

Я обычно: • сначала стабилизирую проект (логи, минимальные тесты, понять домен) • фиксирую версии в composer.json, чтобы окружение не «плавало» • планирую апгрейд по шагам: • PHP → последняя совместимая версия • Laravel → следующая мажорная • пакеты → по очереди, начиная с самых важных

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

6. Чек-лист работы с легаси-Laravel • Понимаю критичные пользовательские сценарии • Есть хотя бы минимальные feature-тесты на эти сценарии • Включены адекватные логи и понятен их путь • Толстые контроллеры аккуратно разбиваются на методы/сервисы без смены поведения • Новый код пишется по нормальным правилам, не подстраиваясь под хаос • Версии PHP/Laravel/пакетов зафиксированы, есть план апгрейда

Что чаще всего ломает работу с легаси • попытка «переписать всё сразу», пока бизнес ждёт горячие фиксы • правки напрямую в проде без логов и бэкапов • изменения в контроллерах без понимания, какие ещё места это задевает • обновление Laravel/PHP одним рывком «на проде, потому что времени нет»

Итог

Сложность работы с легаси на Laravel не в старом коде, а в отсутствии опор: тестов, логов, понимания бизнес-процессов. Если начать с инвентаризации, минимальных тестов и маленьких безопасных рефакторингов, даже очень старый проект постепенно превращается из «мины замедленного действия» в нормальный рабочий код, который уже не страшно трогать.