Ревюиране — какво е, как работи code review и проверката на PR

Какво е code review

Code review — е систематична проверка на кода от колеги преди интегрирането му. В контекста на Git това означава: разработчикът създава pull request с промени, назначава рецензенти и те изучават diff-а, оставят коментари и издават присъда. Рецензентът може да поиска промени (Request Changes), да одобри PR (Approve) или да остави общ коментар.

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

Противоположността на code review е blind commit: разработчикът бута промени в общия клон без ревю. Такъв подход е позволен само в еднопотребителски проекти или за спешни hotfix-ове с последващо ревю. В професионалната екипна разработка code review е задължителен етап за всяка промяна, включително корекции на документация и конфигурация.

Какво се проверява в code review

Code review трябва да бъде систематичен, а не хаотичен. Опитните рецензенти проверяват кода в определен ред: първо архитектура и логика, после тестове, след това сигурност и производителност, и накрая — стил и именуване. Този ред гарантира, че критичните проблеми ще бъдат забелязани преди рецензентът да се умори.

Архитектура и логика: решава ли кодът задачата, има ли излишни абстракции, спазват ли се принципите 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 Филтриране на празни редове преди обработка```" — и авторът прилага промяната с едно кликване. Това ускорява малки корекции и намалява броя на рундовете ревю. За големи корекции е по-добре да напишете общ коментар, отколкото да поставяте големи блокове в suggestion.

# Шаблон за добър коментар за code review

# ЛОШО: „Този код е неправилен“
# ДОБРЕ: „Може да загубим данни при празен отговор.
#         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 — управление на остарели PR. Ако 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, умора. Последици: бъгове стигат до продукция. Решение: ако нямате време за качествено ревю — напишете честно "Не мога да проверя днес, преместете за утре" вместо формално одобрение.

Втора грешка — прекомерна критика (nitpicking). Рецензентът оставя десетки коментари относно стила на форматиране, именуване на променливи, тривиални детайли. Това демотивира автора и проточва ревюто. Решение: StyleGuide и линтерите трябва да проверяват стила автоматично. Човекът в ревюто проверява логика, архитектура и сигурност.

Трета грешка — ревю без въпроси. Ако рецензентът поставя само Request Changes и Approve, но не задава въпроси, пропуска възможността да научи нещо ново. Най-добрият индикатор за здравето на code review е наличието на дискусии, в които и двете страни научават нещо ново. Ако ревюто е монолог на един от участниците — процесът е счупен.

• Повърхностно ревю — Approve без задълбочаване. Решение: не ревюирайте, ако нямате време.
• Nitpicking — критика на стил, който се проверява от линтер. Решение: автоматизирайте style checks.
• Лично възприятие — "аз бих написал различно". Решение: кодът трябва да работи, а не да се харесва на рецензента.
• Проточване — ревю повече от 24 часа. Решение: SLA за ревю, ескалация при нарушение.
• Игнориране на контекст — ревю на код без разбиране на задачата. Решение: четете описанието на PR преди diff-а.