Code Review — що це, як працює перегляд коду та перевірка PR

Що таке Code Review

Code review — це систематична перевірка коду колегами перед його інтеграцією. У контексті Git це означає: розробник створює pull request зі змінами, призначає рев'юверів, і ті вивчають diff, залишають коментарі та виносять вердикт. Рев'ювер може запитати зміни (Request Changes), схвалити PR (Approve) або залишити загальний коментар.

Code review переслідує п'ять цілей: підвищення якості коду (пошук дефектів до потрапляння в production), поширення знань (рев'ювер дізнається про нові підходи, автор отримує зворотний зв'язок), дотримання стандартів (перевірка відповідності code style та архітектурним рішенням), зниження bus factor (код знає не один розробник) та побудова культури відповідальності (автор пише акуратніше, знаючи, що код будуть перевіряти).

Протилежність code review — blind commit: розробник пушить зміни в загальну гілку без рев'ю. Такий підхід допустимий лише в однокористувацьких проектах або для термінових hotfix з подальшим рев'ю постфактум. У професійній командній розробці code review — обов'язковий етап для будь-якої зміни, включаючи правки документації та конфігурації.

Що перевіряти в Code Review

Code review має бути систематичним, а не хаотичним. Досвідчені рев'ювери перевіряють код у певному порядку: спочатку архітектура та логіка, потім тести, потім безпека та продуктивність, і тільки в кінці — стиль та naming. Такий порядок гарантує, що критичні проблеми будуть помічені до того, як рев'ювер втомиться.

Архітектура та логіка: чи вирішує код задачу, чи немає надлишкових абстракцій, чи дотримані принципи SOLID та DRY. Складний код, який важко зрозуміти з першого прочитання — сигнал, що потрібен рефакторинг. Рев'ювер має переконатися, що код робить саме те, що вказано в задачі, і не має побічних ефектів за межами своєї відповідальності.

Тести: чи покривають нові тести всі сценарії — позитивні, негативні, граничні випадки. Чи проходять існуючі тести після змін. Чи немає flaky-тестів, які падають нестабільно. Безпека: відсутність SQL-ін'єкцій, XSS, витоків чутливих даних через логи або відповіді API. Продуктивність: ефективність алгоритмів, надлишкові запити до БД, витоки ресурсів.

• Архітектура — коректність рішення, дотримання SOLID, відсутність over-engineering.
• Логіка — обробка всіх сценаріїв, включаючи помилки та граничні випадки.
• Тести — покриття нових змін, відсутність зламаних старих тестів.
• Безпека — ін'єкції, XSS, CSRF, витоки даних через логи.
• Продуктивність — складність алгоритмів, N+1 запити, витоки пам'яті.

Розмір рев'ю: чому 400 рядків — максимум

Обмеження розміру PR — найважливіша метрика ефективності code review. Дослідження Cisco (2015) та подальші експерименти SmartBear і Google показали: при обсязі рев'ю більше 400 рядків різко падає здатність рев'ювера знаходити дефекти. Якщо PR перевищує 400 рядків, помилки в ньому виявляються з ймовірністю не вище випадкової.

Оптимальний розмір: 200–400 рядків на один PR. Такий обсяг рев'ювер може перевірити за 30–60 хвилин, зберігаючи концентрацію. Google рекомендує не більше 200 рядків за один раунд рев'ю з повною концентрацією. Якщо зміни більші — задачу потрібно декомпозувати на кілька послідовних PR, кожен з яких вносить логічно завершену зміну.

Час рев'ю: протягом 24 годин з моменту створення PR. Якщо рев'ю затягується на кілька днів, контекст задачі втрачається, і автору доводиться витрачати час на відновлення контексту при відповіді на коментарі. Команди з високою культурою code review встановлюють SLA на рев'ю: наприклад, 4 години для критичних змін і 24 години для звичайних.

Як правильно писати коментарі до рев'ю

Тон коментарів — критично важливий для ефективності code review. Коментар «Це невірно» викликає захисну реакцію та не дає автору корисної інформації. Краща формулювання — запитання-пропозиція: «Що думаєш про такий підхід?», «Тут може бути NPE, якщо user == nil. Може, додати guard?». Запитання менше тиснуть і стимулюють обговорення.

Структура хорошого коментаря включає три частини: що не так, чому це проблема і як виправити. Приклад: «У цьому циклі використовується O(n²) через вкладений contains, що може гальмувати при 10k+ записів. Спробуй замінити на Set для O(1) пошуку». Таке формулювання одночасно вказує проблему, пояснює її важливість і пропонує рішення — автору не потрібно домислювати.

GitHub і GitLab підтримують suggestions — вбудовані пропозиції змін коду. Рев'ювер може написати: «```suggestion Filter empty strings before processing```» — і автор застосує зміну одним кліком. Це прискорює дрібні правки та знижує кількість раундів рев'ю. Для великих правок краще написати загальний коментар, ніж вбудовувати великі блоки в suggestion.

# Шаблон гарного коментаря code review

# ПОГАНО: "This code is wrong"
# ДОБРЕ: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Синтаксис пропозиції GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review в команді

Ефективний workflow рев'ю будується на чотирьох етапах. Перший — автор готує PR: пише зрозумілу назву (наприклад, «feat: add password reset screen»), додає опис змін, посилання на задачу в трекері та інструкції з тестування. Другий — автор призначає рев'юверів через auto-assign (на основі CODEOWNERS) або вручну.

Третій етап — рев'ювер перевіряє код і залишає коментарі. Четвертий — автор вносить правки, відповідає на коментарі та запитує повторне рев'ю. Цикл повторюється до отримання апрува. Після апрува автор виконує merge (або merge виконує бот). Автоматизація через Mergify або GitHub Auto-merge прискорює фінальний етап.

Важливий елемент workflow — stale PR management. Якщо PR висить без рев'ю більше 3 днів, процес блокується. Рішення: ротація рев'юверів (якщо призначений недоступний), сповіщення через Slack/Teams, ліміт часу для рев'ю (SLA). У деяких командах PR без рев'ю більше 7 днів автоматично закривається, і автор створює новий після синхронізації з main.

• Створення PR — зрозуміла назва, опис, посилання на задачу, скріншоти при UI-змінах.
• Призначення — auto-assign через CODEOWNERS або ручний вибір 1–2 рев'юверів.
• Рев'ю — перевірка в порядку: архітектура → логіка → тести → безпека → стиль.
• Правки — автор відповідає на всі коментарі, виправляє blocking issues, запитує re-review.
• Merge — після апрува та зеленого CI автор або бот виконує злиття.

Типові помилки code review

Перша помилка — поверхневе рев'ю. Рев'ювер побіжно переглядає diff, не вникаючи в логіку, і натискає Approve. Причини: великий PR, deadline, втома. Наслідки: баги потрапляють у production. Рішення: якщо немає часу на якісне рев'ю — чесно напишіть «Не можу перевірити сьогодні, перенесіть на завтра» замість формального апрува.

Друга помилка — надмірна критика (nitpicking). Рев'ювер залишає десятки коментарів щодо стилю форматування, іменування змінних, тривіальних деталей. Це демотивує автора та затягує рев'ю. Рішення: StyleGuide та лінтери мають перевіряти стиль автоматично. Людина в рев'ю перевіряє логіку, архітектуру та безпеку.

Третя помилка — рев'ю без запитань. Якщо рев'ювер ставить тільки Request Changes та Approve, але не задає запитань, він упускає можливість навчитися чомусь новому. Найкращий індикатор здоров'я code review — наявність обговорень, у яких обидві сторони дізнаються нове. Якщо рев'ю — це монолог одного з учасників, процес зламано.

• Поверхневе рев'ю — Approve без занурення. Рішення: не рев'ювати, якщо немає часу.
• Nitpicking — критика стилю, який перевіряється лінтером. Рішення: автоматизувати style checks.
• Особисте сприйняття — «я б написав інакше». Рішення: код має бути робочим, а не подобатися рев'юверу.
• Затягування — рев'ю довше 24 годин. Рішення: SLA на рев'ю, ескалація при порушенні.
• Ігнорування контексту — рев'ю коду без розуміння задачі. Рішення: читати опис PR перед diff.