Код-рев’ю “як у проді” — це не про прискіпливість. Це про те, щоб PR не заніс у систему приховані проблеми, які потім коштують дорого: витік даних, поламана авторизація, N+1 і падіння швидкодії, дублі через queue, або просто нечитаємий код, який через місяць ніхто не зможе нормально змінити. У навчанні це критично: рев’ю формує дисципліну, коли людина думає не тільки “щоб працювало”, а “щоб було безпечно, швидко і підтримувано”.
Починайте рев’ю завжди з трьох питань: що змінюється (поведінка), що може зламатися (ризики), як це буде підтримуватися (простота). Якщо PR додає фільтр — ризик у доступах і в запитах. Якщо PR додає статус — ризик у переходах станів і валідації. Якщо PR додає медіа — ризик у безпеці файлів і чергах. Це задає рамку: ви дивитесь не “все підряд”, а найнебезпечніші місця.
Далі — чотири осі перевірки, які ти запросив: стиль, безпека, продуктивність, читабельність.
Стиль у продакшені — це про консистентність, а не “краса”. Ви дивитесь: чи однакова структура файлів, чи іменування не випадкове, чи методи короткі, чи немає копіпасту, чи не з’явилися “магічні числа/рядки” в коді. У Laravel стиль ще й про шарування: контролер не варить бізнес-логіку, сервіс не залежить від HTTP, Blade не містить SQL/складної логіки. Якщо PR порушує ці межі — це мінус, бо через 3–4 PR ви отримаєте спагеті.
Безпека — перший реальний блок. Тут рев’ю має бути жорстким. Перевіряєте авторизацію: чи є policy/middleware, чи не зняли існуючі обмеження, чи фільтри не розширюють доступ. Дуже частий баг: додають orWhere і відкривають записи, які не мали бути видимими. Другий баг: у контролері беруть модель через find($id) без scope видимості — і користувач може підглянути чужий запис, підставивши ID. Третій баг: масове присвоєння — якщо модель має неправильні fillable/guarded, можна підсунути поля, які не можна змінювати (status, user_id, account_id). На рев’ю ви дивитесь, що FormRequest відсікає зайве, а сервіс приймає тільки validated дані. Також дивитесь на файли: upload має мати валідацію типу/розміру, безпечні імена, заборону виконуваних типів, правильні права доступу.
Продуктивність — друга зона, яка “вистрілює” пізніше, але виправляти її після релізу боляче. На рев’ю ви шукаєте: N+1 (цикл + доступ до relationship), ->get() без пагінації на списках, важкі підрахунки в циклі (count()/exists() на кожному рядку), сортування без індексу, “LIKE %term%” на великих таблицях без плану. Якщо PR додає фільтри — ви дивитесь, чи є індекси під ці фільтри, чи не зламана пагінація, чи запит будується через when() і не тягне зайві колонки. Якщо PR додає eager loading — перевіряєте, чи не тягнуть зайві hasMany на список. Якщо PR додає кеш — чи є інвалідація, чи ключі не “загальні”.
Читабельність — те, що в проді економить найбільше часу. Читабельний код — це коли за 30 секунд ясно: що робить метод, які входи/виходи, де правила, де транзакція, що буде при помилці. На рев’ю ви дивитесь на структуру: методи в сервісі мають бути короткі і названі дією (publish, approve, archive, create, update). Не повинно бути “гігантського методу на 200 рядків”. Якщо логіка складна — вона розбивається на приватні кроки з назвами, або на окремі сервіси. Коментарі не мають пояснювати очевидне, але мають пояснювати “чому так”, якщо рішення неочевидне (наприклад, обхід дедлоку, reason для індексу).
Тепер — практичний чек-лист продакшен-рев’ю для Laravel-модуля, який можна застосовувати щоразу.
Перше: маршрути і доступи. Чи routes згруповані логічно, чи використовуються middleware, чи є policy, чи authorize викликається в потрібних місцях. Чи не з’явився новий endpoint без захисту. Чи не дозволили “зайве” через query params. Чи обмеження account/company присутні всюди.
Друге: контролер. Він має бути тонким. В контролері має бути мінімум: параметри, authorize, виклик сервісу, відповідь. Якщо у контролері є SQL, транзакції, логування activity, складні обчислення — це сигнал переробити.
Третє: сервіс. Чи є транзакція там, де 2+ таблиці. Чи є чіткі методи, чи немає “GodService”. Чи є нормалізація даних (типи, trim). Чи є інваріанти (заборони редагування posted/published). Чи робляться побічні ефекти (нотифікації) через queue, а не синхронно в запиті.
Четверте: запити. Чи є eager loading там, де в Blade використовуються зв’язки. Чи немає N+1. Чи пагінація використовується для списків. Чи select() не тягне важкі поля без потреби. Чи додані потрібні індекси (міграція) під нові фільтри/сортування.
П’яте: Blade/UI. Чи partials/components використовуються для повторів, чи не з’явився копіпаст. Чи форма показує errors, чи old() працює. Чи фільтри зберігаються в query string при пагінації. Чи немає небезпечного виводу (неекранований HTML там, де не треба). Чи кнопки дій узгоджені з policy (@can).
Шосте: activity log і аудит. Чи логуються ключові події, чи не логуються “дрібниці”. Чи actor і entity однозначні. Чи немає дублікатів при retries (особливо якщо лог пишуть з job).
Сьоме: тести. Чи є тести на критичні гілки: доступи (403), видимість (не бачить чужого), валідація (не пише в БД), статуси (дозволено/заборонено), фільтри (працюють і не розширюють доступ). Тести — це вимога продакшен-рівня, без них PR вважається ризиковим.
І ще одне: якість PR як артефакту. У проді не приймають PR на 40 файлів “бо я тут ще трошки почистив”. Зміни мають бути сфокусовані. Якщо потрібен рефакторинг — окремий PR. Якщо додали фічу — тільки пов’язані файли. Це зменшує шанс “протягнути” випадкові поломки.
Висновок: продакшен-код-рев’ю — це дисципліна, яка тримає систему живою. Ви дивитесь на шарування (тонкий контролер, товстий сервіс), на безпеку (policy, scoping, mass assignment), на продуктивність (N+1, пагінація, індекси), на читабельність (зрозумілі методи, малі блоки), і на тести (критичні гілки). Якщо цей підхід застосовувати з першого “повного модуля”, людина починає писати код так, що його можна підтримувати роками, а не до першої пожежі.
