Zrevidovat — co to je, jak funguje code review a kontrola PR

Co je code review

Code review — je systematická kontrola kódu kolegy před jeho integrací. V kontextu Gitu to znamená: vývojář vytvoří pull request se změnami, jmenuje recenzenty a ti studují diff, zanechávají komentáře a vynášejí verdikt. Recenzent může požadovat změny (Request Changes), schválit PR (Approve) nebo zanechat obecný komentář.

Code review má pět cílů: zlepšení kvality kódu (odhalování defektů před tím, než se dostanou do produkce), šíření znalostí (recenzent se dozvídá o nových přístupech, autor dostává zpětnou vazbu), dodržování standardů (kontrola souladu s code style a architektonickými rozhodnutími), snížení bus factor (kód nezná jen jeden vývojář) a budování kultury odpovědnosti (autor píše pečlivěji, protože ví, že kód bude kontrolován).

Opakem code review je blind commit: vývojář tlačí změny do společné větve bez review. Tento přístup je povolen pouze v projektech pro jednoho uživatele nebo pro naléhavé hotfixy s následným review. V profesionálním týmovém vývoji je code review povinnou fází pro každou změnu, včetně oprav dokumentace a konfigurace.

Co kontrolovat v code review

Code review by mělo být systematické, ne chaotické. Zkušení recenzenti kontrolují kód v určitém pořadí: nejprve architektura a logika, poté testy, pak bezpečnost a výkon, a nakonec — styl a pojmenování. Toto pořadí zaručuje, že kritické problémy budou zaznamenány dříve, než se recenzent unaví.

Architektura a logika: řeší kód úlohu, existují zbytečné abstrakce, jsou dodržovány principy SOLID a DRY. Složitý kód, který je při prvním čtení obtížné pochopit — signál, že vyžaduje refaktorování. Recenzent se musí ujistit, že kód dělá přesně to, co je uvedeno v úkolu, a nemá vedlejší účinky mimo svou oblast odpovědnosti.

Testy: pokrývají nové testy všechny scénáře — pozitivní, negativní, okrajové případy. Procházejí stávající testy po změnách. Existují flaky testy, které nestabilně padají. Bezpečnost: absence SQL injekcí, XSS, úniků citlivých dat přes logy nebo API odpovědi. Výkon: účinnost algoritmů, nadbytečné dotazy do databáze, úniky zdrojů.

• Architektura — správnost řešení, dodržování SOLID, absence over-engineeringu.
• Logika — zpracování všech scénářů, včetně chyb a okrajových případů.
• Testy — pokrytí nových změn, absence rozbitých starých testů.
• Bezpečnost — injekce, XSS, CSRF, úniky dat přes logy.
• Výkon — složitost algoritmů, N+1 dotazy, úniky paměti.

Velikost review: proč je 400 řádků maximum

Omezení velikosti PR — nejdůležitější metrika účinnosti code review. Výzkum Cisco (2015) a následné experimenty SmartBear a Google ukázaly: při objemu review přes 400 řádků schopnost recenzenta odhalovat defekty prudce klesá. Pokud PR přesahuje 400 řádků, chyby jsou odhalovány s pravděpodobností ne vyšší než náhodnou.

Optimální velikost: 200-400 řádků na jeden PR. Takový objem může recenzent zkontrolovat za 30-60 minut, při zachování koncentrace. Google doporučuje ne více než 200 řádků na jedno kolo review s plnou koncentrací. Pokud je změn více — úkol by měl být rozložen do několika po sobě jdoucích PR, z nichž každý přináší logicky dokončenou změnu.

Čas review: do 24 hodin od okamžiku vytvoření PR. Pokud se review protáhne na několik dní, kontext úkolu se ztrácí a autor musí trávit čas obnovováním kontextu při odpovídání na komentáře. Týmy s vysokou kulturou code review stanovují SLA pro review: například 4 hodiny pro kritické změny a 24 hodin pro běžné.

Jak správně psát komentáře k review

Tón komentářů — je klíčový pro účinnost code review. Komentář "Toto je nesprávné" vyvolává obrannou reakci a neposkytuje autorovi užitečné informace. Nejlepší formulace je otázka-návrh: "Co si myslíš o tomto přístupu?", "Zde může dojít k NPE, pokud user == nil. Možná přidat guard?". Otázky méně tlačí a stimulují diskusi.

Struktura dobrého komentáře zahrnuje tři části: co je špatně, proč je to problém a jak to opravit. Příklad: "V této smyčce se používá O(n²) kvůli vnořenému contains, což může zpomalit při 10k+ záznamech. Zkus nahradit Setem pro vyhledávání O(1)". Taková formulace současně ukazuje problém, vysvětluje jeho důležitost a nabízí řešení — autor nemusí hádat.

GitHub a GitLab podporují suggestions — vestavěné návrhy změn kódu. Recenzent může napsat: "```suggestion Filtrovat prázdné řádky před zpracováním```" — a autor aplikuje změnu jedním kliknutím. To zrychluje malé opravy a snižuje počet kol review. Pro velké opravy je lepší napsat obecný komentář než vkládat velké bloky do suggestion.

# Šablona pro dobrý komentář code review

# ŠPATNĚ: „Tento kód je nesprávný“
# DOBŘE: „Můžeme přijít o data při prázdné odpovědi.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Syntaxe návrhu GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review v týmu

Efektivní workflow review je založeno na čtyřech fázích. První — autor připravuje PR: píše srozumitelný název (např. "feat: add password reset screen"), přidává popis změn, odkazy na úkol v trackeru a pokyny pro testování. Druhá — autor jmenuje recenzenty pomocí auto-assign (na základě CODEOWNERS) nebo ručně.

Třetí fáze — recenzent kontroluje kód a zanechává komentáře. Čtvrtá — autor provádí opravy, odpovídá na komentáře a žádá o opakované review. Cyklus se opakuje, dokud není získáno schválení. Po schválení autor provádí merge (nebo merge provádí bot). Automatizace prostřednictvím Mergify nebo GitHub Auto-merge zrychluje závěrečnou fázi.

Důležitý prvek workflow — správa zastaralých PR. Pokud PR visí bez review déle než 3 dny, proces se blokuje. Řešení: rotace recenzentů (pokud je jmenovaný recenzent nedostupný), oznámení přes Slack/Teams, časový limit pro review (SLA). V některých týmech je PR bez review déle než 7 dní automaticky uzavřen a autor vytváří nový po synchronizaci s main.

• Vytvoření PR — srozumitelný název, popis, odkazy na úkol, snímky obrazovky při UI změnách.
• Jmenování — auto-assign přes CODEOWNERS nebo ruční výběr 1-2 recenzentů.
• Review — kontrola v pořadí: architektura → logika → testy → bezpečnost → styl.
• Opravy — autor odpovídá na všechny komentáře, opravuje blocking issues, žádá o re-review.
• Merge — po schválení a zeleném CI autor nebo bot provádí sloučení.

Typické chyby code review

První chyba — povrchní review. Recenzent letmo prohlíží diff, neproniká do logiky a mačká Approve. Příčiny: velký PR, deadline, únava. Důsledky: bugy se dostávají do produkce. Řešení: pokud nemáte čas na kvalitní review — napište upřímně "Dnes nemohu zkontrolovat, přesuňte na zítra" místo formálního schválení.

Druhá chyba — nadměrná kritika (nitpicking). Recenzent zanechává desítky komentářů o stylu formátování, pojmenování proměnných, triviálních detailech. To demotivuje autora a protahuje review. Řešení: StyleGuide a lintery by měly kontrolovat styl automaticky. Člověk v review kontroluje logiku, architekturu a bezpečnost.

Třetí chyba — review bez otázek. Pokud recenzent dává pouze Request Changes a Approve, ale neklade otázky, ztrácí příležitost naučit se něco nového. Nejlepší indikátor zdraví code review je přítomnost diskusí, ve kterých se obě strany učí něco nového. Pokud je review monologem jednoho z účastníků — proces je rozbitý.

• Povrchní review — Approve bez prohloubení. Řešení: nerecenzujte, pokud nemáte čas.
• Nitpicking — kritika stylu, který kontroluje linter. Řešení: automatizujte style checks.
• Osobní vnímání — "já bych to napsal jinak". Řešení: kód má fungovat, ne se líbit recenzentovi.
• Protahování — review déle než 24 hodin. Řešení: SLA pro review, eskalace při porušení.
• Ignorování kontextu — review kódu bez pochopení úkolu. Řešení: číst popis PR před diffem.