Як прийняти чужий проєкт на Laravel

Прийняти чужий застосунок на Laravel — це передусім робота зі зменшення невизначеності. Код — величина відома, його можна прочитати. Чого прочитати не вийде, так це розгортання, задач за розкладом, воркерів черги і трьох змінних оточення, про які знав лише попередній розробник. Наша передача проєкту починається саме тут, а не в редакторі.

Просіть доступи раніше за все інше. Передача завершена тоді, коли у вас на руках репозиторій, сервер (SSH і панель), база даних, DNS і реєстратор домену, акаунти поштового та платіжного провайдерів і ключі сторонніх API. Відсутні доступи — найчастіша причина, через яку приймання проєкту застрягає на тижні, а зібрати їх набагато легше, поки попередня команда ще відповідає на повідомлення.

Запустіть проєкт локально першого ж дня. Клон, `composer install`, копія `.env`, генерація ключа, імпорт дампа бази, міграції. Кожен крок, що впав, — це знахідка: незадокументоване розширення PHP, пакет із приватного репозиторію, міграція, яку ніколи не виконували в правильному порядку. Записуйте ці падіння одразу — цей список і є першим чесним описом стану проєкту.

Далі читайте найнудніші файли:
— `composer.json` і `composer.lock`: версія фреймворка, покинуті пакети, наскільки ви відстали від релізу;
— `.env.example` проти бойового `.env`: які ключі справжні, а які декоративні;
— `routes/` і middleware: справжня поверхня застосунку;
— каталог міграцій: чи описана схема міграціями взагалі, чи живе тільки в базі.

Перевірте те, що працює поза циклом запиту. Команди за розкладом у `routes/console.php`, воркери черги, конфіги supervisor, скрипти резервного копіювання, вебхуки платіжних систем. Саме тут успадковані застосунки ховають сюрпризи і саме тут мовчазна помилка може лишатися непоміченою місяцями.

Не рефакторте першого тижня. Полагодьте розгортання, підніміть тестову копію, підключіть збір помилок і резервну копію, яку ви бодай раз відновлювали. І лише потім беріться за код — маленькими комітами, з тестом навколо всього, що змінюєте. Довіру клієнта будують робоче розгортання і передбачувані релізи, а не переписування з нуля.

Завершіть приймання письмовою картою: як розгортати, де логи, що робить cron, які частини коду крихкі й за що братися першим. Якщо попередня команда такого документа не лишила — а зазвичай не лишає, — ви щойно створили артефакт, який зробить наступну передачу дешевою.