Приймання 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.