Pair Programming

Czym jest Pair Programming

Pair Programming ewoluował przez dekady, zyskał jednak na popularności dzięki metodologii Extreme Programming (XP), która została sformalizowana przez Kenta Becka w książce „Extreme Programming Explained: Embrace Change”. Istnieje kilka technik programowania w parach, a każda
z nich charakteryzuje się innymi założeniami. Uogólniając, całość polega na współpracy dwóch programistów, współdzielących jedną stację roboczą, którzy razem pracują nad rozwiązaniem danego problemu programistycznego. Programista aktualnie piszący kod to tzw. driver, drugi to navigator, zwany również obserwatorem – on także aktywnie uczestniczy w procesie twórczym, jednak skupia się bardziej na ogólnym kierunku oraz na ciągłej weryfikacji kodu napisanego przez „kierowcę”.

Korzyści programowania w parach

Z moich obserwacji wynika, że programiści pracujący w parach wzajemnie wywierają na siebie pewnego rodzaju presję. Zdają sobie oni sprawę, jak cenny jest czas ich partnerów, przez co chcą go maksymalnie wydajnie wykorzystać. W zależności od zastosowanej techniki (opowiem o nich w dalszej części artykułu) korzyści programowania w parach mogą być następujące:

• lepsza jakość kodu, przy czym istotne jest, aby osoba pisząca aktualnie kod formułowała swoje myśli na głos – często pozwala to rozwiązać dany problem, nawet bez znacznej ingerencji drugiej strony,
• łatwiejsze dzielenie się wiedzą domenową między członkami zespołu,
• szybszy rozwój mniej doświadczonych programistów dzięki parowaniu ich z tymi bardziej doświadczonymi,
• potencjalnie większa odporność na zewnętrzne zakłócenia – jedna osoba z pary zawsze może pozostawać skupiona na zadaniu, podczas gdy druga może np. uczestniczyć w zewnętrznej dyskusji z pozostałymi członkami zespołu.

Należy jednak pamiętać, że programowanie w parach jest trudne, bywa wyczerpujące, wymaga samodyscypliny i pokory, a także umiejętności udzielania i dawania feedbacku. Często już sama świadomość, że ktoś przez część dnia będzie nam zaglądał przez ramię i oceniał to, co robimy, może zdezorganizować wewnętrzny spokój. No bo kto nie lubi czasem założyć słuchawek, odciąć się od otoczenia i zanurzyć w jakimś ciekawym problemie?

Programowanie w parach – techniki

Dobre praktyki

Zanim opiszę poszczególne techniki programowania w parach, rzecz najistotniejsza, niezależna od stosowanej techniki: chodzi o robienie przerw oraz oraz nieprzeznaczanie na programowanie w parach zbyt dużo czasu w ciągu dnia – celem jest tu utrzymanie wydajności. Zaczynając od krótkich sesji (1-2 godz.), z czasem można zwiększać liczbę godzin poświęconych na Pair Programming, jednak według mnie dobrze jest nigdy nie przekraczać 5-6 godz. Jak wspomniałem wcześniej, do wyboru mamy kilka technik, każda z nich ma swoje wady i zalety. Daną technikę należy dobierać do konkretnej sytuacji. Proces programowania w parach będzie wyglądał inaczej, jeżeli planujemy przekazać wiedzę lub przeprowadzić onboarding nowej osoby w zespole, a inaczej, jeżeli chcemy zaimplementować jakąś skomplikowaną funkcjonalność. Poniżej opiszę te, z którymi ja się spotkałem i które – według mnie – powinny znaleźć się w arsenale każdego szanującego się programisty.

Backseat navigator

Prawdopodobnie najpopularniejsza metoda, stosowana zazwyczaj instynktownie. Jest wykorzystywana w sytuacji, gdy rozwiązując jakiś problem, doszliśmy do ściany. Bywa, że tak bardzo skupiamy się na znalezieniu rozwiązania, że nie widzimy alternatywnych możliwości, dochodzimy do ślepej uliczki i koniec. W takim wypadku prosimy innego programistę o wsparcie – taka osoba będzie zdolna spojrzeć na naszą zagwozdkę z innej perspektywy. Z drugiej strony, wariant ten jest idealny dla mniej doświadczonych programistów pod kątem nauki nowych umiejętności. Mamy wtedy do czynienia z relacją nowicjusz – ekspert. Jedna strona pisze kod (nowicjusz), druga natomiast pełni rolę wsparcia / mentora (ekspert).

Driver-navigator

Klasyczny Pair Programming, zderzenie dwóch różnych perspektyw na kod. „Kierowca” (ang. driver) zajmuje się pisaniem kodu, skupia się na detalach implementacyjnych, nawigator (ang. navigator) natomiast myśli o rozwiązaniu bardziej ogólnie, jest partnerem do dyskusji, decyduje o kierunku, wychwytuje braki w implementacji oraz przypadkach testowych (real-time code review). Według mnie technika ta jest idealna do rozwiązywania złożonych problemów, gdzie mnogość reguł biznesowych znacząco wydłużyłaby samodzielne próby rozwiązania problemu.

Ping-pong

Bywa, że od początku znamy kierunek, w którym powinniśmy pójść, a dany problem nie jest dla nas wyzwaniem. Takie arcynudne zadania również wymagają od nas profesjonalnego podejścia. Jeżeli TDD (Test-Driven Development) nie jest nam obce, to ta technika sprawdzi się idealnie. Całość polega na naprzemiennym pisaniu testów oraz implementacji. Ping – pierwszy programista pisze nieprzechodzący test, pong – drugi programista pisze implementację, sprawiając, że test zaczyna przechodzić. Po tym następuje faza refaktoryzacji i cały proces rozpoczyna się od nowa.

Czy to faktycznie działa?

Teoria teorią, ale czy Pair Programming faktycznie jest tak wyjątkowy i zawsze da nam oczekiwane efekty?

Jak zwykle, to zależy. Osobiście miałem okazję stosować głównie dwie pierwsze techniki, niestety – rzadziej, niż bym chciał. Spowodowane jest to faktem, że w świecie IT mamy wokół siebie wielu ludzi, często świetnych specjalistów, jednak różnica charakterów jest czynnikiem, który znacząco ogranicza powodzenie wspólnego programowania.

Trzeba pamiętać, że przynoszący rezultaty Pair Programming to przede wszystkim budowanie relacji
z członkami zespołu oraz przełamywanie wszelkich barier komunikacyjnych. Poniżej przedstawię kilka wniosków z mojej przygody z Pair Programming, które według mnie poprawiają efektywność całego procesu:

• dobrze jest określić cel sesji, który będzie można zweryfikować po jej zakończeniu,
• innym ważnym aspektem jest ustalenie przerw oraz częstotliwość zmian,
• jeżeli rozwiązujemy jakiś skomplikowany problem, pierwsza w rolę nawigatora niech wcieli się osoba z większą wiedzą domenową. W przypadku zadania typowo technicznego, niech to będzie osoba z większym doświadczeniem / umiejętnościami,
• będąc w roli drivera, komunikujmy na głos wszystko, co robimy – niejednokrotnie samo mówienie na głos o danym problemie pozwoliło mi znaleźć rozwiązanie.

Te rzeczy sprawdziły się u mnie, jednak zdecydowanie jestem daleki od twierdzenia, że takie podejście jest idealne. Moja sugestia jest taka, aby po prostu zacząć, wyciągać wnioski i próbować usprawniać cały proces tak, aby czuć się komfortowo i czerpać z tego satysfakcję.

Pair Programming online

Pytanie, które pojawia się często w kontekście zdalnego programowanie w parach, brzmi: czy to w ogóle ma sens?

Odpowiedź brzmi: zdecydowanie tak. O ile nasz zespół nie pracuje w sposób asynchroniczny, to według mnie zdalny Pair Programming nie różni się w zasadzie niczym od tego standardowego, przeprowadzanego w biurze. Co więcej, w dzisiejszych czasach, kiedy wszyscy przenieśliśmy się z biur do domów, może nieść za sobą ogrom korzyści, wymusza bowiem kontakt z innymi członkami zespołu, który z reguły jest bardziej naturalny w środowisku biurowym – rozmawiamy w pokoju, na korytarzu czy w kuchni. Jeżeli chodzi o narzędzia, istnieje ich wiele i tak naprawdę to, które wybierzemy, zależy od osobistych preferencji. Jednym wystarczy Google Meet, Skype czy jakiekolwiek inne narzędzie z opcją udostępniania ekranu, inni natomiast, chcąc ze zdalnego programowania w parach wyciągnąć jak najwięcej, skorzystają w tym celu z dedykowanego narzędzia. W zależności od preferowanego edytora kodu będą to Floobits, Saros, Live Share czy Teamhub.

Podsumowanie

Niestety, pomimo tego, że większość osób zajmujących się zawodowo programowaniem słyszała o programowaniu w parach, to ciągle można zauważyć, że jest ono traktowane po macoszemu. Moim zdaniem wynika to poniekąd z faktu, że korzyści z jego stosowania nie zawsze są widoczne od razu. Jest to umiejętność, która wymaga systematycznego stosowania, dlatego warto regularnie poświęcać jej część czasu przeznaczonego na kodowanie. Po zakończonej sesji wskazane jest spisać to, co poszło dobrze, a co nie zadziałało, dać sobie nawzajem feedback, tak aby kolejne sesje były lepsze od poprzednich.