Приёмка Laravel-проекта: чек-лист первой недели

Когда бизнес получает существующее Laravel-приложение, главная задача не в том, чтобы немедленно заказывать новые функции. Сначала нужно понять, чем именно вы управляете, что реально работает и где проект зависит от памяти одного человека. Без этого даже аккуратная доработка легко превращается в дорогую паузу.

Обычно внешне всё выглядит терпимо: сайт открывается, пользователи заходят, платежи проходят. Но как только прежний разработчик отходит от проекта, всплывают пробелы. Неясно, у кого домен и хостинг. Непонятно, какая ветка развёрнута. Очереди, фоновые задачи и релизы существуют скорее как привычка, чем как описанный процесс.

Поэтому приёмка нужна не для формальности. Она должна заранее ответить на несколько практических вопросов. Контролируете ли вы сервисы, за которые платите? Сможет ли другой разработчик поднять приложение из репозитория? Какие сценарии опасно трогать без дополнительной проверки? Такой разбор помогает принять текущую систему без лишних разговоров о полном переписывании.

1. Выясните, что вам действительно принадлежит

Частая ситуация проста: вам передали код, но не управление. Один zip-архив не поможет выпустить исправление, продлить сертификат, поменять DNS или восстановить сайт, если старый логин от хостинга больше недоступен.

Начинать лучше отсюда. Репозиторий и production нередко расходятся. Папка, которую вам отправили, может не совпадать с тем, что реально развёрнуто. А платёжный сервис или почта могут оставаться на чужой учётной записи.

Что делать:

• Откройте репозиторий и посмотрите историю коммитов, а не только текущую копию кода.
• Зафиксируйте хостинг, регистратора, DNS, TLS и шаги релиза. Перенесите это на компанию и на логин, который контролируете вы.
• Запишите, кто владеет платежами, почтой, файловым хранилищем, трекингом ошибок и SMS.
• Отдельно укажите, какая ветка сейчас развёрнута, а не держите это только в одном чате.

В одной продуктовой компании с мая 2024 по январь 2026 работа включала приёмку слабых и частично проваленных проектов от других команд. В таких production-системах уже были проблемы с архитектурой и производительностью. Первый шаг оставался одинаковым: понять, что реально работает, и только потом стабилизировать уязвимые места. Речь шла о восстановлении унаследованных приложений, а не о разработке с нуля.

2. Убедитесь, что приложение запускается не у одного человека

Приёмку нельзя считать завершённой, если проект стартует только на компьютере предыдущего разработчика. Локальный пакет, неописанный .env или база, которую никто больше не сможет восстановить, долго остаются скрытыми.

Отдельная тестовая среда здесь служит простой проверкой. Если чистая установка ломается, вы видите пропущенный шаг ещё в тот момент, когда его есть кому объяснить.

Что делать:

• Поднимите отдельную среду из репозитория по письменной инструкции. Запишите первый шаг, на котором всё остановилось.
• Опишите все нужные переменные среды. Секреты не храните в репозитории, тикетах и чатах.
• Зафиксируйте миграции, очереди, запланированные задачи и сборку frontend. Отдельно отметьте, нужен ли воркер очереди или планировщик.
• Не переносите реальные данные клиентов в незащищённую тестовую среду. Используйте сокращённую или обезличенную копию.
• Запишите, есть ли в проекте тесты и пайплайн доставки.

Для такой работы использовались CI/CD, Docker и AWS. Но копировать чужой стек без причины не стоит. Лучше задать прямой вопрос: может ли команда выпускать изменения без набора действий, который помнит только один человек?

3. Проверьте зависимости и критические сценарии

То, что приложение сегодня открывается, ещё не значит, что с ним безопасно работать дальше. Следующее изменение может упереться в пакет без поддержки. Или в оплату, которую никто не проверял после смены команды.

Массовое обновление всего подряд легко превращается в переписывание без плана. Есть и другая ошибка: команда пропускает сценарии, где есть деньги, доступы или данные клиентов.

Что делать:

• Запишите версии Laravel, PHP и основных пакетов и отметьте, какие из них ещё получают исправления безопасности.
• Оценивайте обновления в контексте этого приложения. Не трогайте lockfile только потому, что вышел новый релиз.
• Пройдите вход, оплату, обращения клиентов и фоновые задачи. Отметьте, что до сих пор не проверено.
• Один раз восстановите резервную копию в отдельной среде.
• Уроните одну задачу очереди и запустите её повторно. Убедитесь, что она не дублирует оплату, письмо или отчёт.
• Если несколько клиентов работают в одном приложении, опишите, как разделяются данные между аккаунтами.
• Для каждого внешнего сервиса укажите, какие учётные данные используются и что сломается после окончания их срока действия.

В одном агентском проекте с января по август 2026 обработка звонков в мультитенантной CRM работала через RabbitMQ с идемпотентной обработкой и надёжной работой с ошибками, поэтому повторный запуск не создавал второй результат. Тот же вопрос нужно задать и вашим очередям, даже если инструменты другие. Базы филиалов там были изолированы, а миграции и индексы поддерживали это разделение.

У вашего проекта может быть другая схема. Но письменный ответ всё равно нужен: может ли один клиент увидеть записи другого? В том же процессе были AI-обработка, телефония, сообщения, учёт и API отчётности.

4. Измерьте медленные места, которые люди уже замечают

Иногда приёмка выглядит завершённой, пока команда не возвращается к обычной работе. Потом звучит общая фраза: сайт тормозит. Но по такой фразе нельзя выбрать исправление. Медленным часто оказывается не весь продукт, а конкретный запрос, тяжёлый ответ API или отсутствующий индекс.

Что делать:

• Назовите страницу, экспорт или задачу, на которой люди уже ждут, и замерьте её до любых изменений.
• Проверьте, нет ли запроса в цикле, поиска без индекса или ответа API, который больше, чем нужно странице.
• Каждую цифру привязывайте к конкретной операции, которая её дала.

На учебной платформе с интеграциями партнёрских сервисов цикл запросов к базе заменили одним агрегирующим запросом. Эта операция сократилась с 12,41 секунды до 2,451 секунды, а использование памяти уменьшилось на 1,5 ГБ. Средняя недельная нагрузка CPU снизилась с 82,2% до 2,75% после устранения узких мест, включая отсутствующие поисковые индексы. Отдельная критическая операция сократилась с 23 937 мс до 48 мс.

Один ответ API уменьшился с 912 КБ до 2,1 КБ. Все эти числа относятся именно к тем операциям. Они не означают, что вся платформа стала быстрее в фиксированное число раз.

В другой роли, с января 2023 по май 2024, удалось убрать зависание UI, а критический процесс сократить с часа до шести минут. Эти результаты относятся к той роли вместе с оценкой, архитектурой и выбором технологий для более чем 20 проектов. Это не статистика учебной платформы. Замеряйте именно ту операцию, которую меняете.

5. Превратите выводы в рабочий план

Слабый аудит заканчивается либо длинным документом без действий, либо разговором о том, что всё нужно выбросить и начать заново. В обоих случаях никто не отвечает за следующий шаг. Унаследованные системы можно стабилизировать.

В одной продуктовой компании техническое лидерство на нескольких проектах сочетало практическое восстановление с более ясным процессом: сначала архитектура и производительность, потом AI-assisted разработка функций, рефакторинг и code review. Стек включал Laravel, TypeScript, Node.js и Vue.

Главный вопрос был не в том, выбрасывать ли приложение, а в том, что стабилизировать первым.

Что делать:

• Разделите выводы на срочные риски, поддержку и более поздние улучшения.
• Для каждого пункта назначьте ответственного и способ проверки завершения.
• Согласуйте, что может подождать до следующей функции.
• Не начинайте новую функцию, пока не закрыты доступ к репозиторию, отдельная среда и проверенное восстановление.

Когда звать специалиста

Этот путь можно пройти вместе с предыдущим разработчиком. Можно и с человеком, который видит код впервые. Помощь нужна тогда, когда репозиторий и хостинг всё ещё не под вашим контролем, когда приложение не поднимается по заметкам или когда с очередями и медленным местом по-прежнему нет ясности, а дата релиза уже назначена.

Я беру такую приёмку и дальнейшую разработку. Услуги охватывают производительность, SaaS и backend-системы, а также AI-интеграции. Проекты показывают восстановление в одной продуктовой компании, измерения на учебной платформе и процесс контроля качества звонков в мультитенантной CRM — каждый результат в своём реальном масштабе. Список можно пройти по пунктам самостоятельно, а Приёмка и поддержка Laravel проходит вместе с вами по реальному репозиторию, хостингу и очередям. Если хотите разобрать репозиторий, хостинг и сценарий, который вас беспокоит, напишите мне.