Приёмка Laravel-проекта: чек-лист перед новыми функциями

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

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

1. Выясните, чем вы владеете

Проблема — копия кода без контроля над системами вокруг. Zip-файл не даёт выпустить исправление, продлить сертификат или восстановить сайт, когда исчезает старый логин хостинга.

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

Что делать:

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

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

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

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

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

Что делать:

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

Стек Corpsoft.io для той работы с унаследованными проектами включал CI/CD, Docker и AWS. Не копируйте этот стек. Спросите, можно ли выпустить изменение без ритуала, который живёт в памяти одного человека.

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

Проблема — приложение, которое запускается, но следующее изменение зависит от непроверенного пакета или от оплаты, которую никто не проходил после ухода предыдущего разработчика.

Обновление всего сразу становится незапланированным переписыванием. Пропуск сценариев, которые берут деньги или обслуживают клиентов, — это то, как небольшое исправление ломает вход или списание.

Что делать:

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

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

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

Проблема — приёмка, которая выглядит завершённой, пока реальное использование не оказывается медленным, а единственное описание — «сайт медленный». Это не говорит, что менять. Медленный экран часто оказывается одним запросом, одним payload или одним отсутствующим индексом. Перестраивать продукт по этой причине — направить работу не туда.

Что делать:

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

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

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

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

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

Что делать:

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

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

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

Я беру такую приёмку и разработку после неё. Услуги описывают работу над производительностью, SaaS и backend-системы и AI-интеграции. Проекты держат восстановление в Corpsoft.io, измерения Skillsline и процесс контроля качества звонков в Sintegrum — каждый в том объёме, который результат действительно имел. Чтобы разобрать ваш репозиторий, хостинг и сценарий, который беспокоит, напишите мне в LinkedIn.