Mám poměrně jasnou předs­tavu, jak by měla vypadat organi­zace softwa­rového projektu. Mimo jiné dokola přesvědč­uji, že je potřeba psát testy a insta­luju nástroje na statickou analýzu kódu. Už to mám nacvič­ené. Ovšem čím dál tím víc mi chybí code review. Ještě jsem toto téma zatím uspoko­jivě neucho­pil, ale minimálně jsem se zamys­lel, jak bych z toho chtěl vybřed­nout, ačkoliv jsem tak ještě neuči­nil.

Autoři knih mají korek­tory, účetní zase auditory, jen programátoři si myslí, že jsou bohové. Code review by mělo zachytit chyby (i když nemůžete čekat, že se podaří najít všech­ny). Dále kontro­luje, že nový člen týmu chápe správně archi­tek­turu, používá správné kompo­nenty, dodržuje konvence… V neposlední řadě se programátoři navzájem učí a to nejenom o samotném software, který píší, ale i o progra­mování jako takovém.

Sáhl jsem po knize Best Kept Secrets of Peer Code Review - zdarma poskytla firma SmartBear, která stojí mimo jiné za SoapUI. Nejspíš to berou jako podporu prodeje jejich nástroje na code review Collaborator.

Druhy code review

Podle nich lze rozdělit code review na několik typů:

  • formální kontrola
  • přes rameno
  • e-mail
  • s podporou nástrojů
  • párové programování

Doposud jsem dělal review přes rameno, ad hoc, a cítil, že tomu něco chybí. Chybí tomu metriky a reporty, nelze ho procesně vynutit, můžete při něm přehléd­nout změnu a v neposlední řadě se neověřuje oprava. S code review přes e-mail se nejspíš setkáte v open-source projek­tech. Největší nevýhodou je, že zabere třeba 5 dní místo 30 mi­nut. Za code review lze považovat i párové progra­mování. Dochází při něm k důkladné kontrole, ale chybí odstup, protože se oba na řešení podíleli. Zato formální kontrola vyžaduje svolat mítink, nicméně ostatní typy zvládnou odhalit stejné množství chyb za méně času. Oproti tomu code review s podporou nástrojů zavádí automa­tické metriky, eviduje historii… a především je proces vynuti­telný. Každé má svoje - ovšem lepší něco než nic.

Chyba je něco, co chce ten, kdo dělá review, změnit. Chyby jsou dobré, ne špatné; neříkají nic o úrovni programátora (spíš o komplex­nosti úlohy). Metriky by se neměly používat k hodno­cení odměn, nikdo je pak pocho­pi­telně nebude hlásit. Code review přináší do progra­mování emoce, konkrétně pozitivní stres a úzkost, zda jsem napsal dost javadocu či zda jsem nemohl připsat test. Takový ego efekt, který vás ihned učiní lepším programátorem.

Čísla

Ve zmiňo­vané knize Best Kept Secrets of Peer Code Review je uvedená přípa­dová studie z firmy Cisco a z ní několik zajímavých čísel: Code review je efektivní dělat nanejvýš hodinu, ale minimálně pět minut, i kdyby na jediný řádek. Za onu hodinu byste neměli kontro­lovat víc jak 200 řádek kódu. Vychází 32 chyb na 1000 řádek. Měli byste mít kontrolní seznam, na co se při kontrole zaměřit (což mi připomíná, že si chci přečíst knihu The Check­list Manifesto).

Pro code review hovoří i to, že chyby při něm odhalené, je levnější opravit, než chyby, které se dostanou do QA či dokonce až k zákaz­níkovi. Smart­Bear má na webu pěknou kalku­lačku ROI (Return of investment).

Code review a SCM


Pro Git, Scott Chacon (CC) BY-NC-SA 3.0

Největší bolest je pro mne to, že code review přichází zpětně, když už je kód v repositáři a lidem se už nechce měnit. Bez code review nemůže být úloha označena za naprog­ra­mo­vanou a předána testerům. Na druhou stranu chcete, aby kód byl někde verzo­vaný, ne jen v něčím works­pace. Jenže toho s SVN těžko dosáh­nete. Tím se dostáváme k distri­buo­vaným systémům, ve kterých potřebné workflow lze realizovat. Pomůžou vám v tom nástroje jako třeba Gerrit pro Git. Existuje obdoba pro Mercurial?

Jak děláte code review vy?