V tomto článku ze série o zavádění code review si povíme něco o samotném procesu code review. Vyjasníme si, o co jde, jak to v teorii probíhá i jaké varianty máme. Pojďme tedy rovnou k jádru věci.

 

„Code review is tool for finding bugs before your customers do.“

 – Programming wisdom –

 

Jde o procesní nástroj, jehož správným používáním dochází ke snižování počtu defektů (a z toho plynoucích chyb, selhání). Při vývoji užíváme řadu nástrojů od kompilátorů, verzovacích systémů či testovacích frameworků po IDE. Procesní nástroj se od nich odlišuje v tom, že nejde o nějaký kus software, ale o sérii více či méně popsaných kroků, které ale v konečném důsledku musí vykonávat člověk, protože je nelze (zcela) automatizovat. Z procesů mívají vývojáři hrůzu, toto je však na rozdíl od procesů manažerů plně v jejich kompetenci (k hrůze oněch manažerů) a při správném provedení bude ve vývojářích představa vývojového procesu bez code review budit takovou hrůzu jako řízení auta se zavázanýma očima.

Sluší se podotknout, že nástrojů pro nacházení chyb dříve, než je najdou vaši zákazníci, je vícero. Patří sem třeba manuální testování, automatizované testování či statická analýza. Všechny mají své opodstatnění a jsou projekty, kdy má smysl je používat dohromady. Oproti těmto nástrojům se code review zabývá výhradně lidskou kontrolou kódu, který má být přidán (typicky do verzovacího systému), a má tak zkontrolovat, že:

  • Byly dodrženy firemní standardy, ať už jde o code style, či architekturu.
  • Kód neobsahuje zjevné chyby a správně zachází s hraničními případy.
  • Kód dostatečně vhodně řeší daný problém.

 

Základní průběh code review je pak přibližně následující:

  1. Vývojář odvede práci a připraví ji k začlenění, o které požádá kolegy.
  2. Proběhne kontrola.
  3. Dojde k opravení nalezených problémů, jsou-li. Pak se znovu celý proces vrátí do bodu 2).
  4. Dojde k začlenění celé opravené práce. (Alternativně může též dojít k zamítnutí/zahození celé práce, pokud se na tom tým shodne.)

 

Taková kontrola může probíhat ve značné řadě variací:

  • Prezentace: Vývojář prezentuje celý kód postupně před celým týmem.
  • Párová prezentace: Vývojář prezentuje celý kód postupně před vybraným vývojářem.
  • Samostatná práce: Přiřazený vývojář projde v klidu sám celý kód.
  • Týmová práce: Vícero vývojářů projde samostatně nebo společně celý kód.

 

Největší smysl pro běžné firemní softwarové projekty dává samostatná práce. Prezentace se hodí, pokud nejde o nic dlouhého a účelem je spíše vyvolat diskuzi. Týmová práce pak má své nezastupitelné místo v případech, že jde o něco se zásadním dopadem (bezpečnost, kritická dostupnost, ...).

 

Jaký je účel code review?

Teď už víme, co code review vlastně je, nyní tedy následuje zamyšlení nad tím, proč code review dělat. Jaké to má výhody? Podívejme se na to pohledem různých zúčastněných.

 

Pohled produktu:

  • udržení vysoké kvality produktu (výsledků, výstupů, kódu, ...)
  • předcházení špatnému návrhu a nesystémovým úpravám
  • nacházení (případně prevence) defektů, které by mohly vést k chybám a selháním

 

Pohled vývojáře:

  • zvýšení povědomí o ostatních částech produktu (co je k dispozici, jak to funguje, o čem produkt vlastně je...)
  • zvýšení produktivity (znalostí okolí, netříštění pozornosti, neopakování funkcionality)
  • snížení nepostradatelnosti jednoho konkrétního vývojáře

 

Pohled projekťáka:

  • předcházení vysoké ceně nové funkcionality a současných i budoucích úprav
  • lepší dohled nad splněním všech požadavků
  • zvýšení řiditelnosti projektů (může poskytovat informace o technickém dluhu)
  • předcházení budoucím nákladům (brzká oprava je levná oprava)

 

Pohled zákazníka:

  • kvalitní produkt, který mohu používat
  • minimum dětských nemocí
  • ušetřené peníze

 

Pohled společnosti:

  • efektivní využití zdrojů (prostředků) společnosti

 

Toto jsou obecné výhody code review, jak jsme je identifikovali u nás v Trigamě po analýze problémů, se kterými jsme se potýkali. Doporučujeme to slepě nepřejímat, ale zanalyzovat si nejprve své vlastní problémy a svědomitě si říct, co je možné adresovat. Výše uvedený seznam nám pak dobře posloužil pro přesvědčování kolegů a vedení pro zavedení code review.

 

To je pro dnešek vše, příště si povíme detaily našeho provedení, dozvíte se, kdy code review iniciujeme, jak vybíráme code reviewera a jaké používáme ke code review podpůrné nástroje.

 

 

 

Autor: Jan Drábek