Před několika lety jsem spolu s kolegou vyvíjel jeden docela obsáhlý program. Byla to úspěšná aplikace, která se dodnes používá, udržuje a dále rozvíjí. Když se podívám do zdrojových kódů, dodnes v nich najdu kódy napsané v mém vlastním stylu. Možná si říkáte, že bych měl být hrdý a všem tvrdit, jak jsem umění programování zvádl svým jedinečným stylem. Není tomu tak, po přečtení tohoto článku budete vědět proč.

Code Review je revize kódů někým jiným než autorem. Nevím, kde a kdy Code Review vzniklo, Wikipedia mlčí. Předpokládám, že tam, kde jde doslova o život, což napovídá stránka zaznamenáníhodných chyb na wikipedii. Obzvlášť zajímavá je známá chyba v záměně desetinné tečky a čárky v jazyce Forth v kosmické sondě Mariner 1. Dá se říci, že kdyby NASA dělala Code Review, tak by sonda dopadla lépe…

(Fotografie ze startu jmenované sondy byla převzata odsud.)

Kdo a jak může revidovat

Přístup, kdy kódy po autorovi ještě někdo kontroluje, se určitě vyplatí i při běžném programování. Na první pohled se zdá, že nejlepší je pověřit revizemi kódu toho nejschopnějšího programátora, vždyť přece kdo jiný by mohl být větší autoritou v týmu? Jsem toho názoru, že v době agilního programování je tento postup nevhodný – na revizích kódu by měli pracovat všichni. Proč? Inu proto, protože když někdo dokáže kód napsat, tak také dokáže posoudit správnost kódu někoho jiného…

Nahradit expertní (autoritativní) přístup ke Code Review agilním (demokratickým) přístupem má několik výhod:

• komunikace s kolegou nad správným řešením mě naučí nové věci
• lidé v týmu jsou lépe zastupitelní
• znalost cizích kódů mi dodá odvahu využívat knihovní kódy ostatních (DRY)
• nový zaměstnanec (resp. nový člen týmu) se snáze zapracuje (i když na začátku Code Review dělat nebude)

Jak revidovat

Je několik možností, jak praktikovat revize, nejprve tedy co revidovat:

1. revize každého commitu – výhodou je to, že se nestane to, že by nějaký kus kódu neprošel revizí. Nevýhodou je vyšší pracnost. Tento přístup se také nehodí pro počáteční fáze vývoje, kdy se do repository dostávají rozpracované kódy.
2. revize po funkcionalitách – výhodou je větší „přirozená logika práce“. Bohužel při tomto přístupu dost velké procento kódu revizí neprojde.

Dalším dilematem je kam psát nalezené problémy v kódech, na internetu jsem našel několik možností:

1. Psát připomínky do bug tracking systému (nepraktické – špatně se zaznamenává konkrétní soubor, číslo řádku a číslo revize).
2. Psát připomínky přímo do kódu (například do sekce TODO – vývojové prostředí dokáže vypsat za celý projekt)
3. Poslat opravy jako DIFF mailem (prý se používá v Google a při vývoji Open Source)
4. Specializovaný software (má jen jednu nevýhodu: cenu)

Co revidovat

Revize kódu by neměly nahrazovat testování, jejich podstatou by nemělo být ověření specifikace ani přemítání nad architekturou aplikace. Revize kódu by se měla zaměřit „překvapivě“ na kód. Některé aspekty kódu lze ověřit automaticky (kódové konvence pomocí CheckStyle, statická analýza pomocí FindBugs), některé musí být ověřeny ručně (dostatečně podrobný a srozumitelný JavaDoc). Neměli bychom ani zapomínat na firemní best practices…

A kdy revize nedělat? Pokud na projektu pracuje jen jeden programátor. Pokud jde o velmi úzkou vrstvu aplikace, ve které nemůže být chyba (nebo tam chyba nevadí nebo nemůže mít velké škody – například zobrazovací vrstva webu psaná v šablonách). Pokud pracujete v časové tísni… I když, nemá to cenu i v těchto případech?

Co je cílem

Cílem Code Review je kvalitnější kód. To znamená rychlejší, efektivnější, méně chybový, kratší, přehlednější, optimalizovaný… Pod pojmem „kvalitnější“ si lze představit mnohá, někdy i protichůdná kritéria. Vyjmenuji tedy další dva body, které můžeme také považovat za cíl nebo nebo alespoň za vedlejší efekt.

Podle jméno názoru je cílem revizí, aby aplikační kód byl standardizovaně „nudný“. To znamená čitelný, pochopitelný, snad až by se dalo říct „estetický“, ve kterém je „osobní styl“ kódování na závadu. Také to znamená, že v celé aplikaci jsou použity typické postupy pro řešení typických problémů.

Druhým cílem či vedlejším efektem je sdílené vlastnictví kódu. O výhodách sdíleného vlastnictví se dočtete v agilních metodikách…

Závěr

Code Review považuji za užitečnou činnost, která by měla být zavedena vždy, když na projektu pracuje víc než jeden člověk. Pokud se vám to podaří v projektu nasadit (vyžaduje podporu u programátorů i u vedení), určitě to bude ku prospěchu věci. A to i přes to, že jazyk Forth u vás nepoužíváte…