Mnoho softwarových firem dnes používá pull requesty, zejména v té podobě, jak je zavedl github, jako standardní mechanismus pro sdílení informací o kódu mezi vývojáři.
Typicky to vypadá třeba tak, že programátor Jirka píše kód celý den (dejme tomu 5 hodin čistého času) a až mu připadá, že je “hotov”, pošle kód skrze příslušný nástroj jinému programátorovi, Ondrovi, který se na kód podívá. Věnuje tomu typicky řádově kratší čas, dejme tomu půl hodiny neboli 10%.
Pull Requesty
Pull Requesty mají vlastně dvě složky smíchané dohromady:
- vynucená feature branch
- asynchronní revize kódu (code review)
O tom, co způsobují feature branche si napíšeme jindy, dnes se věnujme druhému aspektu – revize kódu.
Pull Requesty mají několik výhod. Kód, na který se podívají 2 programátoři je opravdu kvalitnější než kód, který napíše jediný programátor. O provedené revizi je písemný záznam. Revize se dá dělat jindy než psaní původního kódu.
Má to ale několik háčků. Neříkám, že se všechny stanou vždycky a určitě se nestanou všechny najednou, ale viděl jsem je dost často na to, aby to byla náhoda.
- Ondra má svoje úkoly, které jsou pro něho důležitější, takže revizi kódu věnuje jenom tolik času, aby to tyto úkoly neohrozilo, typicky těch 10 procent. Dá se vlastně říct, že ten kód viděli ne 2 programátoři, ale jenom 1,1 programátora.
- Za ten krátký čas Ondra není schopen pochopit, co Jirka napsal (pokud není velmi seniorní). Takže se soustředí na drobnosti – nedodržení konvencí, chybějící kontroly chyb, apod.
- Ondra vidí jenom výsledek Jirkova myšlenkového postupu a ne myšlenkový postup samotný. Nevidí, které cesty Jirka zavrhl a proč.
- Díky všem předchozím bodům se Ondra málokdy něco nového naučí. A jelikož programátoři se učí rádi a často, je to další důvod, proč považují code review za nudnou součást své práce, kterou se snaží omezit na nezbytné minimum.
- Pokud se Ondra a Jirka předtím dobře neznají, tak se ani nepoznají, rozhodně se nijak neprohloubí jejich sociální vazby.
- Ondra ví, že Jirka do kódu už investoval značné množství času (řádově víc než on), takže pokud se mu vůbec nelíbí přístup, jaký Jirka zvolil, má větší bariéru kód zamítnout – vždyť by to přece znamenalo, že se to musí celé předělat.
Všechny tyto háčky obvykle převáží výhody získané tím, že jeden kód vidí více lidí. Existuje způsob, jak tyto nevýhody eliminovat? Ano. Technik pro revizi kódu je samozřejmě víc, my si dnes povíme něco o tzv. mob programming.
Týmové programování
Mob programming, neboli ensemble programming, česky něco jako týmové programování je technika, při které se naplno využívají znalosti a schopnosti celého týmu. Funguje tak, že jeden člen týmu sedí u klávesnice (říká se mu driver neboli řidič) a zapisuje do kódu myšlenky ostatních členů týmu (navigátorů). Členové týmu se týmu se pravidelně střídají na místě řidiče, typicky po 10 – 15 minutách.
Pokud vám to připomíná párové programování, které možná znáte z extrémního programování, tak ano, je to zobecnění párového programování. Proti párovému programování má tu výhodu, že nevyžaduje od všech členů týmu maximální soustředění 100% času. Je úplně běžné, že jeden člen týmu se na chvíli odpojí, vyřídí si telefonický hovor nebo si dá biologickou přestávku.
Výhody týmového programování
Jaké jsou ale výhody týmového programování obecně, zejména ve srovnání s asynchronní revizí kódu, kterou známe z pull requestu?
- Všichni členové týmu jsou plně soustředěni na kód, který se právě píše. Má-li tým 5 členů, kód vidí 5 programátorů, každý z trochu jiné perspektivy a každý do něho dodá to nejlepší, co umí.
- Všichni věnují psaní kódu plný čas, takže mají čas pochopit, co se v kódu přesně děje.
- Všichni jsou přítomni celému myšlenkovému procesu, takže chápou nejenom to, co v kódu napsáno je, ale i to, co tam napsáno není, například slepé uličky a zavržené alternativy.
- Zpětná vazba probíhá hned, takže nehrozí, že by se jeden člověk vydal celý den nebo dokonce několik dní špatným směrem.
- Lidé jsou ve stejné místnosti (nebo virtuální místnosti) a tím pádem se poznávají nejenom jako odborníci, ale i jako lidé.Někomu doma štěká pes. Někdo má na pozadí monitoru obrázek z Pána prstenů.
- Do psaní kódu se mohou zapojit i lidé, kteří nejsou úplní odborníci. Jako řidiči jenom zapisují kód, který vymýšlejí navigátoři (jeden kolega použil výraz “průtokový ohřívač myšlenek”). Jako navigátoři mohou přispět svou troškou, když se na to cítí a nestojí na nich celá váha obtížného úkolu.
- Perlička na závěr: jako vedlejší efekt se lidé často naučí drobné technické triky, které používají ostatní. Virtuální plocha ve Windows – poprvé jsem viděl u jednoho vývojáře při mobu. jiná kolegyně byla zase fascinována tím, že blok kódu se dá pomocí klávesové zkratky nejenom posunout celý doprava (odsadit), ale i posunout celý doleva.
Obecně má týmové programování pozitivní krátkodobé i dlouhodobé efekty. Krátkodobě vám zlepšuje náladu z toho, že se vám povedlo vyřešit složitý problém v týmu podobně naladěných lidí. Dlouhodobě působí efekt postupného učení, který dělá z členů týmu větší a větší odborníky na větší a větší části kódu.
Zdánlivé nevýhody
Na první pohled je hlavní nevýhodou týmového programování větší investice do vývoje, která je způsobená tím, že celý tým lidí řeší jeden problém, zatímco zdánlivě by mohl řešit více problémů najednou. Nenechte se tím zmást, mohli byste dopadnout jako manažer v tomto rozhovoru:
Coach: “Proč nepoužíváte týmové programování”?
Manažer: “Protože individuálně jsou lidé produktivnější”
Coach: “Aha, a proč potom máte code review? A testery?”
Manažer: “Abychom zachytili chyby”
Coach: “A jak u vás vznikají chyby?”
Manažer: “Náš produkt je moc složitý, jeden člověk mu nemůže rozumět”
Závěr
Pull request byl vymyšlen pro určitou situaci – skupina lidí, která se vzájemně nezná a nevěří si, si kontroluje svou práci. Moderní firmy jsou v jiné situaci – jejich zaměstnanci tvoří týmy lidí, kteří si vzájemně důvěřují.
Používat pull requesty je lepší než nedělat žádnou revizi kódu. Ale proč je používat, když znám lepší nástroj?
Mít nějaké světlo je lepší než sedět ve tmě. Ale přece nebudu svítit petrolejkou, když existuje elektřina.
Pokud se vám článek líbil, sledujte mě na LinkedIn nebo Twitter.
