Code Review — podstata, pravidla a jak provádět revizi v týmu

Co je Code Review?

Code Review — proces kontroly zdrojového kódu jedním nebo více vývojáři před jeho integrací do hlavní větve projektu. Cílem revize není pouze hledání chyb, ale také zlepšení architektury, soulad se standardy týmu a šíření znalostí. Na rozdíl od automatické analýzy (linterů) je code review prováděno člověkem a hodnotí čitelnost, logiku a architektonická rozhodnutí.

Podle Google Engineering Practices, 2024 se Code Review dělí na dva rovnocenné cíle: ochrana kódové základny před defekty a školení vývojářů prostřednictvím zpětné vazby. V mobilních projektech revize povinně zahrnuje kontrolu frameworků (UIKit, SwiftUI, Jetpack Compose), správy paměti a práce se síťovými požadavky.

Code Review v GitLabu a GitHubu je organizováno prostřednictvím Merge Request a Pull Request. Každý MR/PR obsahuje diff, komentáře k řádkům, diskuze a stavy kontrol. Podle výzkumu Microsoft Research (2023) týmy, které praktikují pravidelnou revizi, vypouštějí o 40 % méně kritických chyb do produkce.

Historie Code Review: od formálních inspekcí k asynchronním PR

První formální Code Review se objevilo v IBM v 70. letech 20. století jako „strukturované inspekce" s podrobnými kontrolními seznamy a protokolem. V 21. století s rozšířením Gitu a distribuovaných týmů se revize vyvinula do asynchronního formátu prostřednictvím Pull Request. GitHub (2008) udělal z PR masový fenomén. Moderní Code Review je neformální, asynchronní proces s důrazem na rychlost a učení, nikoli na byrokracii.

Typy Code Review: formální a neformální přístupy

Code Review se klasifikuje do čtyř hlavních typů v závislosti na procesu a zapojení účastníků. Formální (Asynchronous Review) — kontrola přes MR/PR bez synchronní komunikace, nejrozšířenější v distribuovaných týmech. Neformální — quick CR, když jeden vývojář přijde k druhému a požádá o kontrolu kódu do 5 minut.

Podle Microsoft Research, 2023 je párové programování (Pair Programming) — dva vývojáři pracují u jedné obrazovky, každý kód je psán v reálném čase s revizí „za běhu". Over-the-shoulder — jeden vývojář se dívá na obrazovku druhého a komentuje kód bez formálního procesu. Walkthrough — autor kódu provádí skupinu vývojářů změnami a vysvětluje každé rozhodnutí.

Kontrolní seznam Code Review: co kontrolovat v kódu

Kontrolní seznam Code Review pomáhá recenzentovi nepropásnout kriticky důležité aspekty. První kategorie — správnost a architektura: odpovídá řešení zadanému úkolu, není zde nadměrná složitost, jsou vzory (MVP, MVVM, Clean Architecture) správně zvoleny. Druhá kategorie — styl a formátování: dodržuje se kódový styl týmu (Kotlin Code Style, Swift Style Guide).

Podle Thoughtbot Code Review Guide, 2024 je třetím blokem testování: jsou napsány unit testy, pokrývají okrajové případy, nerozbily existující testy. Čtvrtý — zabezpečení: nejsou zde pevně zakódované tokeny, API klíče, SQL injekce, úniky paměti. Pátý — výkon: jsou správně použity corutiny/RxJava, není blokováno vlákno UI, nadměrné alokace.

• Logika — správnost algoritmu, zpracování okrajových případů a chyb
• Architektura — dodržování Clean Architecture, MVVM, oddělení odpovědností
• Kódový styl — pojmenování, formátování, konzistence s projektem
• Testy — existence unit testů, jejich úplnost a zelený status

Jak provádět Code Review: pravidla pro recenzenta

Code Review vyžaduje od recenzenta rovnováhu mezi důkladností a rychlostí. Hlavní pravidlo — kontrolovat kód v malých dávkách. Optimální objem — 200–400 řádků změn v jedné relaci. Podle Google Research (2022) ztrácí revize nad 500 řádků účinnost: počet přehlédnutých defektů roste lineárně s objemem změn. Druhé pravidlo — začněte architekturou, pak logikou, pak detaily.

Podle SmartBear, 2025 by komentáře měly být konkrétní: ne „to je špatně", ale „tato metoda porušuje SRP — přesuňte validační logiku do samostatné třídy". Každý komentář je návrh na zlepšení, nikoli kritika. Pokud je kód správný, ale styl neodpovídá preferencím recenzenta — ponechte bez komentáře. Recenzent by měl schválit správné řešení, i když by ho sám napsal jinak.

Jak přijímat Code Review: rady pro autora

Přijímání Code Review — dovednost neméně důležitá než schopnost kontrolovat kód. Autor by měl přistupovat k připomínkám otevřeně a považovat je za příležitost ke zlepšení řešení. První pravidlo — nebrat komentáře jako osobní kritiku. Code Review kontroluje kód, nikoli vývojáře. Druhé — pokud je komentář nejasný, požádejte o vysvětlení, neopravujte hned.

Podle LeadDev, 2024 by měl autor před odesláním k revizi zkontrolovat svůj vlastní kód: spustit testy, projít kontrolní seznam, ujistit se, že nejsou žádné debug logy a zakomentovaný kód. MR/PR by měl obsahovat srozumitelný popis s kontextem změn. Čím kvalitnější popis, tím rychlejší a produktivnější bude revize.

Psychologické bezpečí v Code Review

Klíčovým aspektem Code Review je psychologické bezpečí v týmu. Pokud se vývojář bojí ostré kritiky nebo zesměšnění, bude problémy skrývat místo toho, aby je diskutoval. Google Project Aristotle (2017) ukázal: týmy s vysokým psychologickým bezpečím jsou o 25 % produktivnější. Pravidla: kritizujte kód, ne autora; ptejte se místo obviňování; děkujte za dobrá řešení.

Klíčové pravidlo pro autora — nespěchejte s uzavíráním komentářů. Pokud recenzent požádal o změny, musí být provedeny, ne odpovídat „ok" a nechat bez opravy. Po provedení oprav — znovu požádejte o revizi. GitLab a GitHub podporují Re-request Review pro upozornění recenzenta.

Automatizace Code Review: lintery a statická analýza

Automatizace Code Review snižuje zátěž vývojářů tím, že odstraňuje kontrolu formálních pravidel. Lintery (ktlint, SwiftLint, ESLint) kontrolují kódový styl, formátování a základní chyby. Statické analyzátory (Detekt, SonarQube, Infer) nacházejí potenciální chyby, úniky paměti a bezpečnostní problémy dříve, než se kód dostane k lidské revizi.

Podle dokumentace detekt, 2024 jsou v pipeline CI/CD lintery a analyzátory spouštěny automaticky při vytvoření MR/PR. Pokud kontrola neprojde — je MR blokován tlačítkem Merge. To zaručuje, že k lidské revizi se dostane kód, který již prošel základní kontrolou. Recenzent se soustředí na architekturu, logiku a čitelnost, nikoli na mezery a odsazení.

// Příklad konfigurace detekt pro Android projekt
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Nástroje pro Code Review v mobilních projektech

Nástroje pro Code Review v mobilním vývoji se dělí na platformní (GitLab, GitHub, Bitbucket) a specializované (Gerrit, Reviewable, Crucible). GitLab a GitHub poskytují vestavěnou funkcionalitu: porovnání diff, komentáře k řádkům, vlákna, stavy Approve/Changes Requested, integraci s CI/CD. Výběr nástroje závisí na velikosti týmu a politice revize.

Podle GitLab Docs, 2025 poskytuje Gerrit pro velké týmy (50+ vývojářů) přísnější kontrolu: povinnou verifikaci přes CI před sloučením, vážené souhlasy (Verified + Code-Review) a detailní přístupová práva. Pro malé a střední týmy jsou GitLab a GitHub optimální volbou: konfigurace Required Approvals, Code Owners a Merge Checks trvá minuty.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, vestavěný CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests pro Mercurial/Git, Approvals s Diff komentáři
• Gerrit — přísný proces verifikace, vážené hodnocení, integrace s Jenkins

Typické chyby v Code Review

Chyby v Code Review snižují jeho efektivitu a demotivují tým. První — kontrola příliš velkého objemu změn najednou. Když MR obsahuje 2000+ řádků, recenzent přehlédne až 70 % defektů. Druhá — subjektivní připomínky nepodložené kódovým stylem nebo architekturou. Komentáře typu „napsal bych to jinak" bez zdůvodnění nepřinášejí užitek.

Podle Google Engineering Practices, 2024 je třetí chybou ignorování testů. Pokud MR neobsahuje testy nové funkcionality — recenzent by je měl vyžadovat, nikoli schvalovat „na později". Čtvrtá — kontrola na konci dne nebo sprintu, kdy je pozornost roztěkaná. Nejlepší čas na revizi — první polovina dne, vyhrazených 30–60 minut bez přepínání mezi úkoly.

Bezpečnost revize — pátá častá chyba: recenzenti nekontrolují, zda jsou v kódu pevně zakódovaná tajemství, neuzavřené WebView s JavaScriptem, zranitelnosti v knihovnách. V mobilních projektech je to kritické: únik API klíče může vést k ohrožení celého backendu.

Code Review v distribuovaných týmech

Pro vzdálené týmy je Code Review hlavním kanálem předávání znalostí. Doporučuje se asynchronní formát přes MR s jasnými termíny: maximálně 24 hodin na revizi. Používejte záznamy obrazovky (Loom) pro složité architektonické diskuze. V distribuovaných týmech je obzvláště důležité písemné zaznamenávání rozhodnutí v komentářích MR, aby kontext nebyl ztracen při změně časových pásem.