Pull request review - jak na code review

Code review je něco co dělám denně. Někdy to je otrava, někdy najdu bug co by šel do produkce. Tady jsou praktiky co mi fungují.

Proč to dělat

• Čtyři oči - kolega vidí co já ne
• Učení - z cizího kódu se toho naučím víc než z dokumentace
• Konzistence - tým píše podobně
• Prevence - chytit bug před mergem je levnější než v produkci
• Historie - PR slouží jako dokumentace proč se co změnilo

Jak vypadá dobrý PR

Jako reviewer poznám špatný PR okamžitě - prázdný popis, tisíc řádků změn, commit message "fix stuff". Tady je co pomáhá.

Název a popis

feat(auth): Add two-factor authentication support

## Popis změn
Přidána podpora pro 2FA pomocí TOTP (Time-based One-Time Password).
Uživatelé si mohou aktivovat 2FA v nastavení účtu.

## Typ změny
- [x] Nová funkce
- [ ] Bug fix
- [ ] Refaktoring
- [ ] Dokumentace

## Testování
- Manuálně otestováno na dev prostředí
- Přidány unit testy pro AuthService
- E2E testy pro aktivaci 2FA

## Screenshoty
[obrázky UI změn]

## Checklist
- [x] Kód prošel lintem
- [x] Testy prochází
- [x] Dokumentace aktualizována

Velikost pull requestu

Optimální velikost: 200-400 řádků změn

Menší PR jsou:

• Snáze pochopitelné
• Rychleji reviewovatelné
• Méně náchylné k chybám při review
• Snazší pro revert v případě problémů

Pravidlo: Pokud PR obsahuje více než 500 řádků, zvažte rozdělení na menší logické celky.

Atomické commity

Každý commit by měl reprezentovat jednu logickou změnu:

# Špatně - jeden obří commit
git commit -m "Add authentication, fix bugs, update styles"

# Dobře - atomické commity
git commit -m "feat(auth): Add login form component"
git commit -m "feat(auth): Implement JWT token handling"
git commit -m "test(auth): Add unit tests for auth service"
git commit -m "style(auth): Update login form styling"

Checklist pro code review

1. Funkčnost

• Řeší kód správně popsaný problém?
• Jsou ošetřeny všechny edge cases?
• Funguje kód správně pro různé vstupy?
• Jsou správně ošetřeny chybové stavy?

2. Design a architektura

• Zapadá změna do celkové architektury projektu?
• Je kód na správném místě (správný modul/komponenta)?
• Není příliš těsně svázaný s jinými částmi?
• Je respektován princip single responsibility?

3. Čitelnost a udržovatelnost

• Je kód snadno pochopitelný?
• Jsou názvy proměnných a funkcí popisné?
• Jsou složité části okomentovány?
• Je dodržen coding style projektu?

4. Výkon

• Není zbytečně neefektivní algoritmus?
• Nejsou zbytečné databázové dotazy?
• Je správně použito cachování?
• Není memory leak?

5. Bezpečnost

• Je správně validován uživatelský vstup?
• Není SQL injection riziko?
• Jsou citlivá data správně chráněna?
• Je správně implementována autorizace?

6. Testy

• Jsou přidány relevantní testy?
• Pokrývají testy edge cases?
• Jsou testy srozumitelné a udržovatelné?
• Prochází všechny existující testy?

Jak píšu komentáře

Tón komentářů ovlivňuje jak je tým ochotný přijímat feedback. Naučil jsem se to z vlastních chyb.

Dobrý vs. špatný komentář

Špatně:

"Tohle je úplně špatně. Proč jsi to napsal takhle?"

Dobře:

"Tento přístup by mohl způsobit race condition při současném přístupu více uživatelů. Co kdybychom použili mutex nebo optimistic locking?"

Typy komentářů

1. Blocker (musí být opraveno)

🔴 [BLOCKER] Zde chybí validace vstupu, což může vést k SQL injection.

2. Suggestion (návrh na zlepšení)

💡 [SUGGESTION] Tento cyklus by se dal zjednodušit pomocí `.map()`.
Není to nutné, ale zlepší to čitelnost.

3. Question (dotaz)

❓ [QUESTION] Proč jsi zvolil tento přístup místo použití existující utility?
Možná mi něco uniká.

4. Nitpick (drobnost)

🔍 [NITPICK] Zde by podle našeho style guide měla být mezera.
Neboj, jen drobnost.

5. Praise (pochvala)

✨ [PRAISE] Skvělé řešení! Tento pattern se mi líbí, budu ho používat.

Pravidla pro psaní komentářů

1. Buďte konkrétní – Místo "tohle je špatně" řekněte, co přesně a proč
2. Navrhněte řešení – Pokud kritizujete, nabídněte alternativu
3. Ptejte se – Místo domněnek se zeptejte na záměr autora
4. Používejte "my" – "Mohli bychom..." místo "Měl bys..."
5. Oddělte důležité od kosmetických – Označte, co je blocker a co drobnost

GitHub code review workflow

Zahájení review

1. Přečtěte si popis PR – Pochopte kontext a záměr
2. Zkontrolujte CI status – Prochází testy a linting?
3. Prohlédněte si změněné soubory – Získejte přehled o rozsahu

Procházení změn

# Klávesové zkratky na GitHubu
j/k     - Další/předchozí soubor
n/p     - Další/předchozí diff chunk
b       - Toggle blame view
t       - Toggle file tree

Typy review rozhodnutí

Comment – Zpětná vazba bez explicitního schválení nebo zamítnutí

Approve – Schválení změn, PR může být mergnut

Request changes – Požadavek na změny před merge

Multi-line komentáře

Pro komentování více řádků:

1. Klikněte na číslo prvního řádku
2. Držte Shift a klikněte na poslední řádek
3. Klikněte na modré + a napište komentář

Suggestion feature

GitHub umožňuje navrhovat konkrétní změny kódu:

const result = items.filter(item => item.active).map(item => item.name);

Autor může návrh přijmout jedním kliknutím.

Automatizace code review

CI/CD integrace

Automatizujte rutinní kontroly:

# .github/workflows/pr-check.yml
name: PR Check

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run ESLint
        run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

  type-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: TypeScript check
        run: npm run type-check

Povinní revieweři

# .github/CODEOWNERS
# Globální vlastníci
* @team-lead @senior-dev

# Specifické oblasti
/src/auth/ @security-team
/src/api/ @backend-team
/src/components/ @frontend-team

PR šablony

<!-- .github/pull_request_template.md -->
## Popis změn
<!-- Popište, co tato změna dělá -->

## Typ změny
- [ ] 🐛 Bug fix
- [ ] ✨ Nová funkce
- [ ] 🔨 Refaktoring
- [ ] 📝 Dokumentace
- [ ] 🎨 Styling

## Testování
<!-- Jak jste změnu otestovali? -->

## Checklist
- [ ] Kód prošel self-review
- [ ] Přidány/aktualizovány testy
- [ ] Dokumentace aktualizována
- [ ] Změny nemají breaking changes

Automatické přiřazení reviewerů

# .github/workflows/auto-assign.yml
name: Auto Assign

on:
  pull_request:
    types: [opened, ready_for_review]

jobs:
  assign:
    runs-on: ubuntu-latest
    steps:
      - uses: kentaro-m/auto-assign-action@v1.2.5
        with:
          configuration-path: '.github/auto-assign.yml'

Best practices pro reviewery

1. Reagujte rychle

• Cíl: První reakce do 24 hodin
• Pokud nemáte čas na plné review, napište komentář
• Blokující PR demotivuje autora a zpomaluje tým

2. Reviewujte v celku

• Nechte všechny komentáře najednou
• Vyhněte se "salámové metodě" (postupné odhalování problémů)
• Autor neví, kdy je review kompletní

3. Zaměřte se na důležité věci

Prioritizujte:

1. Chyby a bugy
2. Bezpečnostní problémy
3. Architektonické problémy
4. Čitelnost
5. Stylistické připomínky

4. Buďte konzistentní

• Neměňte názor mezi PR
• Dokumentujte týmové konvence
• Automatizujte, co jde automatizovat

5. Učte se a učte

• Code review je oboustranný proces
• Ptejte se, když něčemu nerozumíte
• Sdílejte znalosti a best practices

Best practices pro autory

1. Self-review před odesláním

• Projděte si vlastní diff
• Zkontrolujte, že nic nechybí
• Ověřte, že testy prochází

2. Malé, časté PR

• Snazší pro review
• Rychlejší feedback
• Menší riziko konfliktů

3. Reagujte na feedback konstruktivně

• Neberte kritiku osobně
• Diskutujte, pokud nesouhlasíte
• Vysvětlete své rozhodnutí

4. Aktualizujte PR průběžně

• Reagujte na komentáře
• Označte vyřešené diskuze
• Pushněte opravy

5. Dokumentujte kontext

• Vysvětlete "proč", ne jen "co"
• Odkazujte na related issues
• Přidejte screenshoty pro UI změny

Metriky code review

Co měřit

1. Cycle time – Čas od vytvoření PR do merge

• Cíl: < 24 hodin pro malé PR

2. Review time – Čas od požádání o review do prvního review

• Cíl: < 4 hodiny

3. Iteration count – Počet kol revizí

• Cíl: 1-2 iterace

4. PR size – Velikost PR v řádcích

• Cíl: < 400 řádků

Nástroje pro metriky

• GitHub Insights – Základní metriky
• LinearB – Pokročilá analytika
• Code Climate – Kvalita kódu
• Waydev – Engineering metrics

Řešení konfliktů v review

Když nesouhlasíte s reviewerem

1. Zeptejte se na důvod – Možná máte různé informace
2. Vysvětlete svůj pohled – S fakty a argumenty
3. Navrhněte kompromis – Hledejte střední cestu
4. Eskalujte, pokud je třeba – Přizvěte třetí stranu

Když jste reviewer a autor nesouhlasí

1. Vyslechněte argumenty – Možná má autor pravdu
2. Rozlište důležité od zbytného – Je to hill worth dying on?
3. Akceptujte jiný pohled – Různé přístupy mohou být validní
4. Dokumentujte rozhodnutí – Pro budoucí reference

Code review v různých prostředích

Malý tým (2-5 lidí)

• Méně formální proces
• Vzájemné review mezi členy
• Rychlá komunikace

Střední tým (5-15 lidí)

• Definované oblasti vlastnictví
• CODEOWNERS pro automatické přiřazení
• Týmové konvence a dokumentace

Velký tým (15+ lidí)

• Specializované review týmy
• Formální proces a SLA
• Automatizace a tooling

Open source projekty

• Přísnější guidelines
• Více dokumentace
• Community reviewers

Nástroje pro efektivní code review

GitHub

• Nativní review funkce
• PR templates
• CODEOWNERS
• Actions pro automatizaci

GitLab

• Merge request approvals
• Code quality reports
• Security scanning

Bitbucket

• Pull request review
• Build status
• Merge checks

Specializované nástroje

ReviewBoard – Self-hosted review tool Crucible – Atlassian code review Gerrit – Google's code review tool Phabricator – Facebook's review tool

Co si z toho odnést

Code review mě naučilo víc než jakýkoliv kurz. Vidím jak ostatní řeší problémy, naučil jsem se psát lepší komentáře, a hlavně - chytil jsem spoustu bugů ještě před produkci.

Malé PR, rychlé reakce, konstruktivní feedback. A automatizace na rutinní věci. To je celé tajemství.

---

Potřebujete rychle porovnat změny v kódu? Náš Code Diff nástroj vám umožní vizuálně porovnat dvě verze kódu přímo v prohlížeči – bez instalace a s podporou 22 programovacích jazyků.