Trápení agilních vývojových týmů: Pull Requests

Code Review: The Big Deal

Při vývoji našeho produktu Jerboo jsme pátrali po trablích, které pravidelně zažívají vývojáři v agilních týmech. Nejen že nás zajímalo, jak můžeme přizpůsobit naše řešení tak, aby jim co nejvíce pomohlo, ale také jsme si vyslechli řadu opakujících se zkušeností, které lidé z různých IT pozic opakovaně zmiňovali. Po dvacátém pátém rozhovoru s team leadem nebo vývojářem jsme byli schopni celkem s jistotou říct, že odbavování Pull Requestů je jeden z nejproblematičtějších úkolů každého sprintu. Tím máme na mysli tzv. code review, kdy vývojář naprogramuje řešení, které po něm (před mergování do vývojové větve) zkontroluje aspoň jeden z jiných vývojářů. V rámci této kontroly se komentuje vzniklý kód, navrhuje zlepšení, které pak autor zapracuje a vytvoří vylepšenou verzi. Code review je obecně velmi dobrá praxe: pomáhá udržovat čistý kód, odchytí chyby, kterých si původní vývojář nevšiml a zároveň se vývojáři navzájem od sebe učí, jak lépe a čistěji programovat. Pro nevývojáře uvádíme malý příklad. První vývojář řeší technologický problém, na který je již hotová knihovna, případně je takové řešení zakomponováno do samotného jazyka. Může jít například o vyhledávání elementu v poli podle konkrétní hodnoty v jazyku Java. Juniorní vývojář si na to napíše vlastní kód, jeho zkušenější kolega mu na to napíše, že má použít již existující funkcionalitu v Javě. Vývojář kód opraví, pošle novou verzi a výsledkem je čistější kód. A bonusem k tomu je skvělá věc: přenos know how :-)

Opakující se problém 

Nicméně to celé má jeden nepříjemný problém. Zkušenost mnoha vývojářů a team leadů , se kterými jsme hovořili, se většinově přiklání k pravidelnému zasekávání týmu právě na odbavování pull requestů. To vede ke zpoždění s dokončením změny, častého upomínání a tříštění pozornosti vývojářů. Z aktivit spojených s review Pull Requestů je tak notorická, částečně manuální a někdy i ponižující činnost (“Karle, prosimtě, dneska už se prosím na ten pull request opravdu podívej, už to potřebuji zavřít.”). 

Nakonec to směřuje k tomu, že se tasky (úlohy ve sprintu) zpožďují a velmi často právě ani nedodají. Na konci sprintu se většinou všichni na poslední chvíli začnou intenzivně věnovat odbavováním pull requestů. A to sebou nese dva nové problémy. Jedním je mergováním kódu. Každý pull request je totiž změnou proti původnímu kódu. Když je ale těchto pull requestů například 5 a všechny mění stejný kód, pak se zmergováním prvního Pull Requestu změní i aktuální kód. Zbylé pull requesty se v dosti případech musejí manuálně přepsat tak, aby byly změny relevantní. Dochází tam k nepříjemnému rebasování kódu, což pro vývojáře také není žádná radost (představte si, že přijdete ke svému 10 dní starému kódu, vše je najednou jinak a vymýšlíte některé části od začátku).

Druhý problém je ten, že po úspěšném review následují (měly by následovat) další činnosti, které nejsou vždy triviální. Je potřeba změnu otestovat na testovacím prostředí, probrat s testerem, případně opravit. To samé by mělo proběhnout například s Product Ownerem, případně jiným business zadavatelem. A pokud sprint končí tím, že jsou změny nasazené na produkci, následuje úspěšně dostat změnu do živého prostředí a ozkoušet. Připravit demo pro review s businessem je dalším krokem. Bohužel na všechno toto již nezbývá ve spoustě případů čas, a tak se testování společně s  diskuzí se zadavatelem smrskne jen do rychlého formálního kroku - čímž trpí výsledná kvalita dodané změny.

Na každý problém existuje řešení

Nicméně existují týmy, které tento problém nemají - a praxe říká, že za tím stojí jednoduše vysoká disciplína. Když se sejde tým, kde je většina členů disciplinovaných natolik, že si dokáže svůj čas organizovat metodicky, pull request se pak úspěšně dokončují například do 24 hodin. To je ale spíše výjimka, která si navíc žádá týmový přístup. Proč jsou tedy pull requesty stále tak notorický problém pro mnoho týmů? Důvod je ten, že vývojář musí přestat dělat to, co dělá. Většinou náročnou činnost, do které je myšlenkami zabořen a musí se soustředit. A do toho díky pull requests najednou přichází ke komplexnímu problému někoho jiného, musí vše rozdělané pustit z hlavy, pochopit kompletní problematiku svého kolegy, zamyslet se, jak by to on sám řešil, pak projít celé kolegovo řešení a pátrat, zda to takto dává smysl, zda by se to nedalo případně řešit lépe. Správně by měl vyřešit, zda vůbec dotyčný správně pochopil zadání a jeho práce bude dávat businessově smysl. A po úspěšném review se zase vrátit ke svému rozpracovanému problému. Takový “context switch” je pro většinu náročná, téměř “bolestivá” věc. 

Co tedy úspěšným týmům funguje? Ze zkušeností od našich zákazníků a vývojářů bychom doporučili následující. Předem si jasně stanovit čas, kdy budete pull requesty odbavovat. Například ráno po příchodu do práce, kdy lidé mají ještě čerstvou hlavu. Nebo po obědě, případně hodiny před koncem práce. Určitě je vhodné se tomu věnovat v době, kdy vývojář dokončí task.

V týmech se většinou najdou poctivci, co to za ostatní odpracují. To ale není z dlouhodobého hlediska výhodné. Nůžky se totiž v tomto případě pouze rozevírají, v týmu se tvoří pracovití odborníci a pasivní členové, co o projektu tolik nevědí a pouze píší kód. Zde se osvědčuje vytáhnout Pull Requesty na světlo a řešit to jako součást práce každého člena týmu. Nehledět jen na úkoly, které někdo naprogramuje. Je tedy dobré do tohoto dostat všechny lidi z týmu. Pokud se takto tým naučí, už to tak bude fungovat. 

Co jsme se naučili   

Tip z naší zkušenosti - který funguje, ale nejspíš nikoho nepotěší - do této práce je potřeba se  prostě donutit. Proto ta zmiňovaná disciplína, proto to jasné vymezení času na pull requesty. Bohužel je to občas nepříjemné, ale ukazuje se, že jsou úspěšné týmy, které si stanoví své vnitřní pravidlo, kdy chtějí mít pull request odbavený a k tomu se pak navzájem “motivuje”, řekněme. Předcházejí tak potenciálním problémům na konci. Jako úspěšná praxe se také osvědčuje vyžadovat review jen od jednoho kolegy, nikoli dvou. Ačkoli to jistě záleží na konkrétním projektu a prostředí týmu. Jsou případy, kde je opravdu velký důraz na kvalitu a tzv. “dva palce” dávají smysl.

Po opakovaných zkušenostech s tímto problémem nabízí Jerboo metodické řešení: otevřené PR jsou vidět, a to každý den na Daily Boardu. Pokud nejsou vyřešeny do týmem nastaveného času, vzniká upozornění. Je tak jasně všem z týmu na očích, že jsou nezbytnou součástí vývojové práce a lze je rovnou přiřadit vývojářům. Zároveň Jerboo vyhodnocuje, zda na základě aktuálního stavu a předešlých zkušeností se zpožděnými Pull Requesty nevzniká riziko opožděného dodání.

Tato zobrazení a upozornění jsme zhodnotili jako fér přístup, kdy se na volbě shodne celý tým a je vidět, kolik má jaký vývojář PR za sebou za daný sprint. Vše je pod správou týmu samotného, pravidla se vytvářejí a hlídají výhradně napříč týmem, což je zodpovědné a motivující.

Vyzkoušejte si Jerboo řešení i ve svém týmu, napište nám o demo verzi zdarma na miroslav.fuksa@codingbear.com.