Programowanie w parach jest prostym i starym pomysłem, kojarzonym z technikami zwinnymi, w szczególności z extreme programming. Posiada sporo zalet, a mimo to obecnie jest omal nieużywane w projektach zdominowanych przez scrum. Czy słusznie?
Nie trzeba chyba pisać, że programowanie w parach polega na programowaniu w parach. Dwóch programistów siada przed jednym komputerem i razem pracują nad fragmentem kodu. Zwykle jeden więcej pisze, a drugi komentuje, ale nic nie stoi oczywiście na przeszkodzie, by wymieniać się klawiaturą i myszą od czasu do czasu. Co w tym takiego interesującego? Otóż ciekawe rzeczy dzieją się, kiedy posadzi się dwóch koderów obok siebie…
Po zerowe – rosną koszty “w Excelu”. Dwóch programistów siedzi nad jednym zadaniem! Toż to przecież jakby dwóch glazurników, dwóch hydraulików sobie rury, kafelki podawało i jeszcze gawędziło przy tym, zamiast robić równolegle. Koszmarna strata czasu, z perspektywy zarządzających, którzy nie dość dobrze znają specyfikę pracy programistów. Tylko, że jednak nie do końca tak jest, bo kodząc w parach programiści…
…obserwują się wzajemnie podczas pracy. To znaczy, że się uczą. Czasami rzeczy przydatnych, czasami trików. Swego czasu z kolegą w jednej z firm programowałem w parze. Zauważył on, że zamykam okno w Windows dwoma kliknięciami w lewy górny róg. Tak go to zaskoczyło, że zaczął chodzić po biurze i pytać innych, czy znali ten sposób. Co dla mnie dziwne niewiele osób go kojarzyło, co tym mocniej zachęcało go do odwiedzania kolejnych biurek. Nie jest to rzecz jasna przykład chwalebny, ale anegdota pokazująca, że pracując nawet wiele lat z jakimś narzędziem możemy nie czegoś nie dostrzegać. Wielokrotnie miałem okazję coś u kolegów i koleżanek podpatrzyć. I zawsze wpływało to pozytywnie na moje umiejętności.
Obserwowanie własnej pracy to nie tylko uczenie się trików. To także korygowanie szkodliwych nawyków. Sami możemy nie zauważyć, jak wiele czasu marnujemy na pewne czynności, dopóki ktoś inny nie zwróci nam uwagi, że można to zrobić lepiej, szybciej, prościej, wydajniej. Programując w parach uczymy się sprawności w działaniu, korygujemy się wzajemnie. To wielka wartość. Naprawdę. Programowanie to nie pisanie literek na klawiaturze, ale myślenie i nauka. Dlatego im szybsza edukacja, tym lepszy programista, tym sprawniejszy zespół.
Po drugie (pierwsze było po zerowym oczywiście) co dwie głowy to nie jedna i szybciej można wyłapać błąd. Błąd to taki nowotwór jest. Jak jest mały, no dwie komórki, trzy linie kodu, to cyk skalpelem, dwa kliknięcia, spacja i po kłopocie. Jednak jeśli się rozrośnie, jak poczekamy dwa lata to już będzie nie lada operacja. A jak przetrwa piętnaście lat, to już nikt go nie ubije, tego buga, za to bug może ubić produkt, czyli nosiciela. Po to robimy zresztą code review – żeby szybko bugi ubić. Jednak nic nie ubija buga szybciej, niż zauważenie go w momencie pisania kodu. Do tego trzeba jednak pisać kod we dwójkę.
Po trzecie kod jest jak podręcznik. Nikt nie lubi niezrozumiałych, bełkotliwych książek, z których nie idzie się dowiedzieć o co chodzi. Tak samo programiści nie lubią kodu, którego nie można zrozumieć po pierwszej lekturze, ale trzeba nad nim ślęczeć jak na wierszami Norwida. Jak mamy akurat Cypriana w zespole, to trzeba go okiełznać, bo się za pół roku nie połapiemy i będziemy jęczeć, że ideał naszego kodziku sięgnął bruku. Oczywiście code review da radę, ale można tam dyskutować dniami i sprintami, a we dwójkę przy kawie i jednej klawiaturze jest szybciej.
Po czwarte motywacja. Miałem w jednej pracy kolegę, który opanował do mistrzostwa sztukę zasypiania na siedząco. Oczywiście trzeba być empatycznym i jak ktoś ma akurat małe dziecko albo problemy życiowe, to niech śpi, na zdrowie, ale akurat ów koder był dość młody, bezdzietny i jego problemy polegały na grze do późna na plejce. Generalnie ciężko jest spać, jak ktoś siedzi przy naszym biurku. Ciężko też oglądać filmiki na YouTube, kupować na OtoMoto auto, a już najciężej wysyłać CV, bo i to podobno niektórzy robią. Programowanie w parach motywuje. Chcemy się wykazać, nie możemy się obijać – działamy sprawniej. Dlatego też zresztą trzeba stosować z umiarem, a nie osiem godzin dziennie, bo każdy potrzebuje odrobiny samotności w tłumie openspace’u przy własnym biurku. Natomiast godzina, dwie, może trzy dziennie mogą być zdrowo pobudzające.
Dużo zalet, mówiąc krótko. Czemu tak mało popularna ta technika? Sądzę, że scrum ma tu coś do rzeczy – nie można się choćby o ile mi wiadomo przypisać we dwójkę do jednego zadania. Również perspektywa nietechnicznego product ownera może być negatywna – z pozoru we dwójkę programiści zrobią więcej. Praktyka pokazuje, że zrobią więcej, ale bugów, ale to już ciężko zauważyć nie będąc na linii frontu. Wydaje się także, że sami programiści często nie przepadają za pracą w parach – boją się konfrontacji, nie chce im się tak aktywnie spędzać czasu, nie widzą takiej potrzeby, nie lubią tego. W sumie przywykliśmy wszyscy do pisania w pojedynkę. Osobiście jednak zachęcam, gorąco zachęcam do programowania w parach. Daje to zaskakująco wiele i zdecydowanie warto jest przynajmniej spróbować.
