Code review dnes dělá skoro každá softwarová firma. Málokterá ale ví, kolik ji stojí. Pull request čeká dva dny na recenzenta, pak přijde dvacet komentářů k pojmenování proměnných, autor mezitím rozdělal jinou práci a celý cyklus se opakuje. Šéf firmy vidí jen výsledek: funkce, která měla být hotová v úterý, jde k zákazníkovi až příští týden. Podívejme se, co o code review říkají velké studie a jak ho nastavit, aby chránilo kvalitu a přitom tým nebrzdilo.
Jak vypadá rychlé code review: data z Googlu
Google používá code review už desítky let. Studie Modern Code Review: A Case Study at Google (Sadowski a kol., 2018) prošla záznamy o 9 milionech recenzovaných změn a doplnila je rozhovory a průzkumem mezi vývojáři. Výsledky jsou pro většinu firem překvapivé:
- medián doby celého review je pod 4 hodinami, na první reakci u malé změny čeká autor v mediánu méně než hodinu,
- medián změny mění 24 řádků, přes 35 % změn mění jediný soubor a přes 10 % jediný řádek,
- medián počtu recenzentů je 1, víc než jednoho recenzenta má méně než 25 % změn,
- přes 80 % změn projde nejvýš jedním kolem připomínek a 97 % vývojářů je s procesem spokojeno.
Klíč není v tom, že by Google měl lepší vývojáře. Klíč je ve velikosti změn. Malou změnu přečte recenzent za pár minut mezi dvěma úkoly, velkou odkládá, až „bude mít čas“ – a ten nepřijde. Vývojáři Googlu podle studie stráví recenzováním v průměru 3,2 hodiny týdně (medián 2,6 hodiny), tedy zhruba půl dne z pracovního týdne.
Co review skutečně přináší (a co ne)
Většina týmů zdůvodňuje review tím, že „chytá chyby“. Výzkumníci Microsoftu Alberto Bacchelli a Christian Bird se proto podívali, co review dělá doopravdy. Pozorovali a zpovídali vývojáře, rozeslali dotazník (odpovědělo 873 vývojářů a testerů a 165 manažerů) a ručně roztřídili 570 komentářů z review.
- 44 % vývojářů a testerů uvedlo hledání chyb jako hlavní důvod, proč review dělají,
- jen 14 % komentářů se ale chyb skutečně týkalo,
- nejčastější kategorií (29 %) byla zlepšení kódu – čitelnost, pojmenování, struktura.
To neznamená, že je review k ničemu. Přináší sdílení znalostí, povědomí týmu o tom, co se v kódu mění, a lepší čitelnost kódu do budoucna. Pro šéfa z toho plynou dvě věci. Za prvé: review není náhrada testů. Chyby mají chytat automatické testy a CI, review má hlídat návrh, čitelnost a to, jestli změna dělá, co měla. Za druhé: studie jako největší potíž recenzentů uvádí pochopit, proč se změna vůbec dělá. Když pull request neodkazuje na zadání, recenzent tráví čas rekonstrukcí záměru místo hodnocení řešení.
Proč na rychlosti review záleží
Google ve svých veřejných pravidlech pro recenzenty (Google Engineering Practices) říká jasně: nejdelší přípustná doba na odpověď na review je jeden pracovní den. Zároveň ale nechce, aby vývojář kvůli review přerušoval soustředěnou práci – má počkat na přirozenou pauzu, třeba po dokončení úkolu nebo po obědě. A pokud dostane obrovskou změnu, nemá ji týden odkládat, ale požádat autora o rozdělení na menší.
Že to není jen pohodlí, potvrzuje výzkum DORA. Nathen Harvey, který program DORA v Googlu vede, k výsledkům zprávy za rok 2023 řekl, že zrychlení code review vedlo k o 50 % vyššímu výkonu doručování softwaru. Dodal ale důležitou věc: pokud už máte review rychlé, nesnažte se ho zrychlovat dál. Velká příležitost je tam, kde je review pomalé.
Kolik kódu najednou: pravidla z praxe
Užitečná čísla pro samotné čtení kódu shrnul SmartBear ve svých doporučeních pro peer review:
- 200–400 řádků najednou – nad 400 řádků schopnost najít chyby klesá,
- pod 500 řádků za hodinu – při rychlejším čtení výrazně klesá počet nalezených chyb,
- nejvýš 60 minut v kuse – pak pozornost recenzenta klesá,
- review 200–400 řádků za 60–90 minut by podle SmartBear mělo najít 70–90 % chyb.
Jak nastavit code review ve firmě: šest kroků
- Malé úkoly, malé pull requesty. Největší páka na rychlost review je velikost změny. Rozdělte práci na úkoly, které se dají dokončit a zrecenzovat zvlášť.
- Každý PR odkazuje na zadání. Recenzent musí vědět proč, ne jen co. Ideálně má úkol akceptační kritéria, podle kterých se změna hodnotí.
- Chyby chytají testy, ne lidé. Formátování a styl nechte na linteru, regrese na testech a CI. Člověk se má soustředit na návrh a smysl změny.
- Dohodněte si lhůtu. Odpověď do jednoho pracovního dne je rozumný strop. Review dělejte v přirozených pauzách, ne na úkor soustředěné práce.
- Stačí jeden recenzent. Google si v mediánu vystačí s jedním. Víc lidí na každý PR násobí čekání, ne kvalitu.
- Měřte čekání. Sledujte, jak dlouho leží PR od otevření do první reakce a do merge. Bez čísla se o „pomalém review“ jen diskutuje.
Jak s tím pomůže mcptask.online
V mcptask.online rozdělíte práci na Epic → Story → Task se scrum pointy, ze kterých se automaticky počítá odhad hodin, takže malé úkoly s akceptačními kritérii jsou výchozí stav, ne výjimka. Webhook z GitHubu nebo GitLabu páruje commity a pull requesty s úkoly, commit s referencí zaloguje čas a merge PR může úkol rovnou dokončit – recenzent tak má zadání vždy po ruce a vy vidíte, kde práce stojí. Úkoly z Jiry, Trella nebo Redmine převezmete importem.
Stejnou frontu úkolů může zpracovávat i autonomní AI vývojář (runner). Z úkolu udělá větev, napíše kód i testy, spustí je a otevře pull request. V manuálním režimu PR zůstane otevřený pro vaše review a runner umí zapracovat i připomínky z něj; v režimu auto-squash se mergne až po zelených testech a kontrolách. Vaši vývojáři pak recenzují malé, otestované změny s jasným zadáním – přesně ten typ review, který podle dat funguje nejlépe.
Chcete mít review rychlé a práci přehlednou? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.
Zdroje
- Modern Code Review: A Case Study at Google, Caitlin Sadowski a kol., ICSE SEIP 2018 (PDF)
- Expectations, Outcomes, and Challenges of Modern Code Review, Alberto Bacchelli, Christian Bird (Microsoft Research), ICSE 2013
- Speed of Code Reviews, Google Engineering Practices
- 2023 DORA Report, komentář Nathena Harveyho (DORA, Google) v newsletteru DX
- Best Practices for Code Review, SmartBear