Извршити ревизију — шта је то, како функционише 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 синтакса:
# ```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-а.