Zavádění code review 5/5: Zhodnocení

V tomto posledním článku série o zavádění code review zazní naše zhodnocení, které jsme s odstupem 4 měsíců provedli, a také spousta postřehů a tipů, které se nevešly jinam.

 

Jak to dopadlo u nás?

Dali jsme evaluační období 4 měsíců a kritérium „dotazníkového“ subjektivního šetření, zda došlo v souvislosti s danými problémy ke zlepšení. Období a metodu měření jsme zvolili především z důvodu poměrně malé velikosti našeho týmu a malé byrokratičnosti vývoje, kvůli které by nebylo například kritérium počtu nových bugů za určité období zcela vypovídající.

 

Kolik času trávíme na code review dle odhadu vývojářů:

10 % (střední hodnota, minimum 5 %, maximum 15 %)

 

Kolik času jsme trávili na code review podle Redmine (open source software pro řízení projektů) v době vyhodnocení:

4-13 % v závislosti na projektu

 

Kolik času jsme trávili na code review podle Redmine v roce 2018:

3-12 % v závislosti na projektu

 

Nejčastější dojmy:

• Zadržuje vyloženě odpadní kód.
• Výrazně minimalizuje rozbití buildu.
• Sdílená znalost usnadňuje komunikaci napříč týmem.
• Kvalita zamergovaného kódu je lepší.

Dál jsme měli sadu předpřipravených otázek:

• Zabírá příliš mnoho času: spíše nesouhlas
• Nenachází chyby: nesouhlas
• Není dostatečné pro předcházení chybám či defektům: přibližně půl na půl
• Zvyšuje kvalitu návrhu: spíše souhlas
• Zvyšuje kvalitu kódu, dodržení code style: souhlas
• Snižuje výskyt chyb: souhlas
• Zvyšuje povědomí o práci ostatních, o společném kódu: souhlas
• Příliš se řeší filozofické věci: spíše nesouhlas
• Vzniká příliš mnoho týmových konfliktů: nesouhlas
• Často se cítím příliš dotčen komentáři: spíše nesouhlas

Z dotazníku jsme si odnesli, že zavedení code review bylo přínosné, subjektivně to řeší velkou část našich problémů. Obávané filozofování nad správným řešením se spíše neděje, stejně jako velké týmové konflikty. Chyby proces odhaluje, byť dle subjektivního vidění ne všechny, což ale není překvapením, protože jsme od code review nechtěli, aby byl kompletním testováním.

V code review tedy pokračujeme i nadále. Postupně jsme zvládli zavést i další automatizované nástroje od PHP Code Snifferu, PHPStanu, PHPUnitu a dalších, což celkově vedlo ke snížení objemu komentářů, a implementující se tak mohli lépe soustředit na to podstatné.

 

Postřehy k zavádění

• Na schůzku představující code review chcete pozvat i ostatní členy týmu, kteří s ním nějak interagují, od manažerů, analytiků, designerů až po testery... Všichni budou přicházet do styku s frází „code review“ a měli by vědět, co znamená, jaké je její místo a jaká je její důležitost.
• Neomezte prezentaci pouze na proces code review, dejte vývojářům kontext, jaké problémy to řeší z pohledu firmy, jaké očekáváte přínosy...
• Po prezentaci si dejte s týmem dostatek času na diskusi a nalezení konsenzu, jak to dělat. Je ale důležité nezapomenout, že opravdu nemusíte mít na začátku proces, který bude bezchybný a každý hraniční případ bude mít řešení. Nezapomeňte na pravidlo 80:20, zbytek vyřešte intuitivně a ad hoc. Lpění na 100% správném řešení je typický způsob, jak zabránit uskutečnění čehokoliv.
• Nebylo úplně jasné, na jaký typ činnosti vykazovat dodatečné práce na řešení code review, nakonec se to u nás ustálilo tak, že drobné opravy a vyřešení komentářů dáváme jako Code review, větší předělávky pak samozřejmě jako Vývoj.
• U malých úkolů má code review klidně i 100% režii, protože je potřeba porozumět zadání, nastavit prostředí atd. I na malých úkolech se však dá hodně pokazit!

 

Postřehy ke code review

• Dejte vývojářům dobré a efektivní nástroje, které zapadnou do jejich pracovních návyků, provedení code review by tedy nemělo být náročné na čas a množství s ním spojených úkonů.
• Výstupy (poznámky) z code review by se neměly míchat s úkoly (backlogem), znemožňuje to další práci s daty (analýzy), bude jich příliš mnoho a bude příliš náročné je přidávat. Ideální je používat komentáře v MR v GitLabu či obdobné nástroje.
• Řešit návrhové věci až při code review je pozdě, tomu se chcete vyhnout, protože předělání celé odvedené práce stojí dost úsilí (a peněz). Je tedy potřeba stanovit v týmu hranici, kdy si návrh, jak něco implementovat, nechám raději zkontrolovat předem, než s čímkoliv začnu. Pokud přeci jen dojde k diskuzi o návrhové otázce při code review a musí být řešena, pak typicky řešíme v rámci code review jen to, jestli je „good enough for now“ a zbytek odsunujeme do retrospektivy a případného refaktoringu, aby to nezastavilo celý tým.
• Je důležité psát dobrá zadání, reviewující je další člověk, který musí pochopit, o co jde, špatně či osobně provedená zadání nejsou z pohledu code review časově ani kvalitativně vhodná.
• Původně jsme na kontrolu code style a statickou analýzu používali Sonar, nepodařilo se nám ho ale smysluplně nahradit do našeho workflow, takže jsme místo něj začali používat GitLab s PHP Code Snifferem a PHPStanem.
• Code review je a vždy bude živnou půdou pro konflikty, snažte se vždy pomoci najít řešení, umožněte týmu vydechnout, podporujte řešení pro celek a nezastávejte se jednotlivců, ale lpěte na cílech, kterých má být dosaženo.
• Kontrolní seznam jsem sice v rámci přípravy na code review připravil, není však úplně používaný, je převážně jen high-level, ale projekty by ho typicky potřebovaly přímo použitelný, navíc jeho použití je ošemetné, protože vytváří zdání, že po jeho projití už není potřeba nic dalšího kontrolovat.
• Nová technologie znamená, že se minimálně po nějaký čas stane code review méně efektivním, protože vývojáři nebudou mít technologii natolik pod kůží, aby jim rychle a intuitivně docházelo, kde by mohl nastat problém, co jsou hraniční případy atp.
• Code review velkých úkolů (nad hodinu a půl) jsou problém, klesá u nich efektivita a mají tendenci vyčerpávat reviewera. Ideálním řešením je dělit úkoly na menší a provádět code review na nich, ne vždy je to ale pro nejistotu při implementaci možné, pak nezbyde než si dělat dlouhé přestávky mezi částmi code review a meditovat pro zachování svého duševního zdraví.
• Dává smysl zavádět code review i na dost rozjetých projektech, protože vám to umožňuje kontrolovat kvalitu nového a zároveň více vývojářů získává informaci, kde je technický dluh, což je nezbytný předpoklad pro každý refaktoring.

 

Co si přečíst dále

Při zavádění code review jsme čerpali z řady článků, výběr z těch nejlepších sdílíme níže.

1. Atlassian: Why code reviews matter (and actually save time!)
2. 11 proven practices for more effective, efficient peer code review
3. Code review v praxi
4. Five types of review (delší PDF k typům review)
5. How to implement code review process that developers don't hate (diskuze o zkušenostech)
6. Code review checklist

 

Tímto série o zavádění code review končí. Osobně jsem rád, že jsem jeho zavedení ve firmě přežil a že i nadále po více než roce provozu ke všeobecné spokojenosti stále funguje.