Blog | Jak funguje párové programování?

Jak funguje párové programování?

Přestože je tento fenomén známý asi každému vývojáři, když si u studentů ověřuju, jak párovému programování rozumí, obvykle se dozvím, že nemají vůbec zkušenost. Při školení testování to často bývá jejich první zkušenost s párovým programováním. Proto tento článek.

Jak to tedy funguje?

  • vývojáři vytvoří dvojice
  • tyto dvojice se v čase mění, neděje se to, aby 2 lidé spolu párovali dlouhodobě
  • párování trvá od doby na 1 kratší úkol až po cca 5 hodin (garantuju, že už po 4 hodinách párování budete pořádně vyčerpaní)
  • některé týmy párují pořád, daleko častější ale je, že se páruje u složitějších situací (a bohužel úplně nejčastější je, že se nepáruje vůbec)

Poznámka: Párové programování není nic nového, nejstarší zmínka, kterou jsem o párovém programování našel, je z doby mezi 1953–1956, kdy Fred Brooks a Bill Wright zkusili párové programování a napsali 1500 řádek kódu, který běžel na první pokus.

Další zmínky najdete v knize Pair Programming Illuminated od Laurieho Williamse a Roberta R. Kesslera.


V okamžiku, kdy vznikla dvojice, která ví, jaký má úkol, existuje několik možností, jak postupovat. Já tu ukážu 3, ale způsobů párového programování jsou více a nejspíš by nebyl problém vymyslet si svůj, nový postup.

1) Ping pong pair programming

Tento postup vnímám jako nejlepší, ale vyžaduje Test Driven Development. Vývojář, který začne, napíše selhávající test a dá klávesnici kolegovi. Ten napíše takové řešení, které projde testy a bude jednoduché. Kolega zatím kouká, hlídá zapomenuté středníky, špatně pojmenované proměnné apod. Jakmile vývojář napíše kód, který prošel testem od kolegy, napíše i tento vývojář test. V tu chvíli se prohodí.

Postup tedy je:

Osoba A: napiš neprocházející test Osoba B: napiš kód – napiš neprocházející test Osoba A: napiš kód – napiš neprocházející test Osoba B: napiš kód – napiš neprocházející test Osoba A: napiš kód – napiš neprocházející test atd.

Postupuje se tak dlouho, dokud není úkol hotov.

Na tomto způsobu, který jsem zkoušel třeba s Michalem Tillem, je v tom, že se rychle střídáte, práce je svižná, hodně se naučíte. Tento postup nutí neustále komunikovat – někdo by to mohl vnímat negativně (zejména při párování v místnosti plné vývojářů, kteří si myslí na svoje).

2) Implementátor – Architekt

Další postup je ten, který jsem za svůj život dělal nejčastěji. Dá se totiž dělat i u kódů, kde testy nejsou (ne všude jsem měl vždy testy a ne všude je mám i dnes).

V tomto postupu se vývojáři u klávesnice střídají v dohodnutém intervalu (inklinovali jsme k času kolem 30–45 minut, ale nedělal bych z toho pravidlo).

V tomto postupu si vývojář vymyslí myšlenku, popíše ji partnerovi a implementuje ji. Partner sleduje architekturu, syntax, dává připomínky pro rychlejší kód atd. Když se člověk zastaví, protože neví, co dál psát, vzájemně se probírá, co dál. Probíhá kontinuální code review.

Po 30–45 minutách se prohodí. Za tuto dobu se dá implementovat obvykle 3–5 myšlenek.

Tento způsob vývoje je nejtišší, když ten u klávesnice ví, co má dělat, druhý má jen pár připomínek do minuty (malých). V tomto způsobu si ten druhý i trochu odpočine a dá se takhle fungovat i třeba těch 5 hodin, u ostatních způsobů budete unavení dřív.

3) Hlava – ruce

V tomto způsobu ten, kdo vymýšlí řešení, není ten, kdo program píše. Jeden z lidí má za úkol myslet, druhý má za úkol to zapsat. Postup funguje tak, že si jeden vymyslí myšlenku a popíše ji druhému tak, aby ji dokázal implementovat. U implementace ho vede, říká mu, co kam má dát, ale nesmí sám nic zapisovat.

Tento způsob vede k nejvyššímu vyjasnění si, co se má dít. Zároveň je to naprostý extrém v objemu komunikace.

Na to vyzkoušet ho v praxi teprve čekám. Což mě tak napadá, že bych mohl i dnes.

Paralelní programování

Dalsí postup, který není úplně párové programování, ale který jsem už mnohokrát podnikl, je něco, co bych pojmenoval paralelní programaování.

Vývojáři mají monitory hned vedle sebe, dá se říct tak blízko, že se dotýkají. Sedí tak blízko, že se téměř dotýkají lokty. V jednu chvíli si pokud možno berou podobné úkoly. Kdykoliv se zastaví a neví, konzultují problém s kolegou.

Tento postup lze považovat za určitou vstupenku, mezistupeň, který bude akceptovatelný pro šéfy, než si prosadíte plnohodnotné párové programování.

Ekonomická stránka

Párové programování se vyplatí, vyvinout vlastnost agregátně trvá o trochu víc člověkohodin, ale výsledkem je kvalitnější kód. Vývojářům na SprintPeople jsem nastavil proces následovně: můžete testovat, jak chcete, můžete refaktorovat, jak potřebujete, párovat, jak se vám bude hodit.

Přesvěčte i vy své šéfy, že to má smysl, důkazy o tom, že se to vyplatí existují.

Agile

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek
Následující článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích