Приймання Laravel-проєкту: чек-лист першого тижня

Застосунок у вас уже є. Наступну функцію теж уже чекають. Складнощі починаються в той момент, коли попередній розробник відходить убік. Доступи не зібрані. Проєкт піднімається лише в однієї людини. Оплати, черги та релізи ніхто нормально не описав. Через це навіть дрібна зміна розтягується на дні.

Нормальне приймання дає відповіді ще до старту нової роботи. Чи контролюєте ви все, за що платите? Чи зможе інший розробник запустити застосунок із репозиторію? Які сценарії можна чіпати без ризику для входу, оплат і роботи клієнтів? Саме в такому порядку й варто перевіряти проєкт. Це не розмова про переписування. Це перевірка того, що у вас уже є.

1. З’ясуйте, що вам справді належить

Найчастіше передають код, але не контроль. Один архів із файлами не дає випустити виправлення, продовжити сертифікат, змінити 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 проходить разом із вами по реальному репозиторію, хостингу та чергах. Якщо хочете розібрати репозиторій, хостинг і сценарій, який вас турбує, напишіть мені.