Proč (ne)dělat code review?

Co firma, to jiný přístup ke code review. V mnoha případech je považováno za přirozenou součást vývoje, zatímco jinde může být na obtíž. Pokud se do problematiky ponoříme více do hloubky, zjistíme, že i kolem zdánlivě jasného tématu existuje řada opomíjených doporučení. Než se na ně podíváme (a to v rámci pokračování článku), pojďme si nejprve připomenout, co code review přesně je a jaké výhody z něj můžete získat vy nebo váš klient.

Dělají vývojáři code review?

V rámci obecného průzkumu jsme se zeptali, zda a proč (ne)děláte code review. Potvrdili jsme si hypotézu, že pro většinu vývojářské komunity se jedná o standard. Přes 90 % respondentů uvedlo, že code review dělá, což je skvělá zpráva.

Našlo se i pár jedinců, kteří uvedli, že buď teprve plánují code review zavést, nebo tuto myšlenku zcela zavrhli. Ano, nedělat code review je taky odpověď. V ideálním případě by však měla být podložena validními argumenty, proč tomu tak je a jaké výhody přináší alternativní řešení (za předpokladu, že nějaké je).

Co je code review?

Code review, neboli revize kódu, je definováno jako proces analýzy zdrojového kódu ostatními členy týmu. K revizi kódu dochází, jakmile jeden z vývojářů změnil či rozšířil stávající kód a chystá se své změny sloučit do jedné z větví repozitáře.

V jednom diskuzním fóru jsem narazila na hezké shrnutí:

Code review neznamená, že nadřízený kontroluje práci podřízeného. Code review je dalším párem očí, které se dívají na to, co bylo uděláno, co nebylo uděláno, jak to bylo provedeno a jak to řeší daný problém, stejně tak, jak to zapadá do současného kódu a dodržuje stávající standardy pro kódování.

Pokud bychom se na věc měli podívat z hlediska procesů, vypadalo by to zhruba takto:

1. Vývojář implementuje změny, které si po sobě následně projde a otestuje (!).
2. Podle příslušného workflow vystaví svůj kód ke code review v podobě pull requestu.
3. Kolegové co nejdříve pull request projdou, zanalyzují kód a vyhodnotí, zda je za ně práce v pořádku, nebo vyžaduje úpravy.
4. Pokud práce vyžaduje úpravy, kolegové své připomínky sepíší k pull requestu.
5. Vývojář projde a zapracuje připomínky od kolegů, případně zdůvodní, proč své řešení považuje za vhodnější.
6. Jakmile je práce kolegy schválena, může vývojář mergnout své změny do cílové větve a podrobit úpravy dalšímu testování.

V čem je code review nenahraditelné?

Mnozí z vás si mohou říct: „K čemu code review, pokud mám napsané testy, které mi pomáhají včas odchytit možné chyby v kódu?“ Náležitě vám patří plusový bod za testy. Efektivní code review se neobejde bez dobře nastavené automatické analýzy kódu. Nicméně…

Ať už se bavíme o statických analyzátorech nebo linterech, tyto nástroje kontrolují pouze strojově zpracovatelné kusy kódu. V žádném případě za vás nepohlídají, jestli:

• je kód dostatečně čitelný i pro ostatní kolegy, kteří s vámi pracují na projektu,
• jste zvolili vhodné řešení,
• kód respektuje všechny standardy a konvence v projektu,
• jste nevědomky nerozbili jinou část aplikace,
• kód neobsahuje překlepy v názvu proměnných nebo sémantické chyby.

Některé z těchto úloh bychom zatím mohli jen horkotěžko řešit automatizovaně, takže v této oblasti ještě stále zůstává člověk nenahraditelný (uff 😉).

Výhody code review

Na přínosy revize kódu se lze dívat z více úhlů pohledu, které spolu úzce souvisí. S přimhouřenýma očima je lze rozdělit do tří pomyslných kategorií, a to benefity z pozice vývojáře, projektového manažera či dokonce klienta.

Ve vývojovém týmu může code review přispět například k tomu, že:

• autor kódu je mnohem víc motivovaný k psaní čitelného a udržitelného kódu, pokud ví, že jeho práci bude někdo kontrolovat,
• od kolegů je možné získat zpětnou vazbu na svou práci a posouvat se tak ve svém oboru,
• vývojáři udržují konzistentní postupy, a to i napříč projekty,
• snižuje riziko konfliktů na projektu a předchází duplicitnímu kódu,
• přispívá k rozvoji soft skills jako jsou komunikační dovednosti, schopnost vyjádřit/přijmout kritiku či analytické myšlení,
• umožňují získat či udělit pochvalu dříve než na hodnotících schůzkách.

Jak zlepšit kvalitu kódu pomocí 5 jednoduchých principů

Vydejte se vstříc udržitelnosti a mějte své projekty na úrovni s využitím Software Design Principles. Nejde přitom o nic jiného než aplikování selského rozumu v programování.

Frontend GardenKateřina Dlouhá

Naopak pro projektového manažera může proces code review:

• snížit chybovost na projektu,
• zlepšit zastupitelnost vývojářů na projektu,
• urychlit onboarding nováčků.

A jaké benefity z toho mohou plynout pro klienta? Lze například uvést, že:

• do budoucna může klientovi ušetřit nemalé množství peněz zbytečně investované do opravy chyb nebo do snížení technického dluhu,
• vývojový tým je dobře informovaný o aktuálním stavu projektu a pokud má adekvátně nastavené procesy, zvládá svou práci odbavovat rychleji a efektivněji.

Kdy se zavedení code review opravdu vyplácí?

Výhody jsou víc než jasné. Téměř každý vlastník projektu může z code review i v malé míře profitovat. Nicméně, v některých týmech se i přes značné výhody s code review nesetkáváme.

Často může být na vině již zažitá firemní kultura, která dosud zavedení tohoto procesu jednoduše nebrala v potaz. Nebo naopak se tým rozhodl přejít na alternativu, která je kompatibilní s řízením projektu stejně tak jako s mindsetem vývojářů.

Vedle ovací pro code review může zaznít řada protiargumentů: nedostatek zdrojů (čas, peníze, vývojáři), naprostá důvěra v testy nebo prostě a jednoduše se vývojářský tým cítí dostatečně seniorní 🙂.

I když se může zdát, že code review by mělo být součástí každého projektu, nutně to tak být nemusí. Proto je vhodné zvážit:

• Jaká je životnost projektu?
• Jaký je rozpočet projektu?
• Jedná se o kritický systém se specifickými nároky na výkon, bezpečnost nebo spolehlivost?
• Jak velký tým vývojářů se na něm bude podílet?
• Jaká je profesní úroveň vývojářů na projektu?

Pokud už teď víte, že se jedná o nemalý projekt s dlouhodobou životností a se specifickými nároky, vězte, že se vyplatí investovat do prostředků, které vám pomůžou s dodáním kvalitního kódu.

Totéž platí v okamžiku, kdy na projektu pracuje větší počet vývojářů a máte navíc ve svém týmu nováčky. Code review může pomoct vývojářům s přehledem o projektu a junioři se můžou lecčemu přiučit od zkušenějších kolegů.

Klíčové otázky

Pokud jste zvážili přínosy code review na svém projektu, pravděpodobně dojdete i k následujícím otázkám. Ty budou předmětem zkoumání v navazujícím článku:

• Kdo všechno by se měl podílet na code review?
  Opravdu je zapotřebí přizvat každého vývojáře z týmu namísto jednoho či dvou stejně zkušených, ne-li zkušenějších kolegů?
• Jak by mělo code review probíhat?
  Jak nastavit procesy, priority, odpovědné osoby i očekávané vstupy a výstupy pro jednotlivé fáze code review?
• Jak důsledně code review provádět?
  Provádět pouze statickou analýzu kódu, nebo změny také testovat?
• Jak se sladit v týmu?
  Jakou formou by měli kolegové mezi sebou komunikovat a za jakou dobu by měla být práce na code review odbavena?
• Jak připravit nástroje?
  Ať už používáte GitLab, GitHub nebo Bitbucket, jak tyto nástroje připravit, abyste je využívali co nejefektivněji?