Як проводити code review: на що дивитися і в якому порядку?

Головна мета рев'ю - покращити здоров'я кодової бази, а не знайти ідеальне рішення. Корисно йти від загального до деталей: немає сенсу обговорювати назву змінної в коді, який узагалі не варто вливати.

Порядок перегляду:

1. Опис і мета - чи зрозуміло, яку проблему розв'язує PR, і чи потрібна ця зміна взагалі;
2. Дизайн - чи правильне місце для коду, чи вписується в архітектуру, чи не надто складно;
3. Тести - чи покривають нову поведінку й крайні випадки, чи падали б вони без зміни;
4. Логіка й коректність - граничні умови, null, порожні колекції, конкурентний доступ, обробка помилок;
5. Безпека й продуктивність - авторизація, валідація вводу, N+1, запити в циклі, великі вибірки без пагінації;
6. Читабельність - назви, зрозумілість, коментарі там, де «чому» неочевидне;
7. Стиль - лише те, що не перевіряє автоматика.

На що звертати особливу увагу в Laravel:

• міграції - чи безпечні на великій таблиці, чи є відкат, чи сумісні зі старою версією коду під час деплою;
• масове присвоєння і $fillable, перевірка прав (Gate, політики) у контролерах і Livewire-діях;
• черги - ідемпотентність задач, що буде при повторі;
• запити - with() для зв'язків, індекси під нові where.

Що віддати автоматиці:

• форматування - Pint;
• типові помилки й типи - PHPStan/Larastan;
• тести - CI.

Людина не повинна писати «тут пробіл» - на це є інструменти, а увага рецензента дорожча.

Чого не робити:

• вимагати переписати під свій смак, якщо рішення автора теж нормальне;
• рев'ювити диф без контексту - іноді треба відкрити весь файл чи запустити гілку локально (gh pr checkout 412);
• затягувати: швидкий відгук важливіший за ідеальний.

Докладніше в документації: Google: що шукати під час code review