Pair programming – jak się do niego przygotować?

Co to jest pair programming

Jest to dosłownie programowanie w parze, podczas którego dwóch programistów korzysta z jednego komputera i pracuje nad jednym zagadnieniem. Przyjmują oni jednak dwie różne role: nawigatora (ang. navigator) i kierowcy (ang. driver).

Nazwy nie są przypadkowe. Podział ról rzeczywiście nawiązuje do rajdu samochodowego – nawigator-pilot pilnuje trasy, ostrzega przed trudniejszymi momentami. Kierowca – słucha pilota i reaguje na to, co ma przed sobą.

Podział ról podczas programowania w parze

Kierowca – to on trzyma kierownicę, czyli klawiaturę i myszkę, i tylko on jest odpowiedzialny za pisanie kodu. Do jego obowiązków należy:

• słuchanie poleceń nawigatora, który jest „mózgiem operacji”
• tworzenie kodu opisywanego przez partnera
• czujność – zgłaszanie wątpliwości i odrębnego zdania
• dopytywanie, gdy wytyczne są niejasne lub gdy kierowca gubi się w logice zaplanowanej przez nawigatora
• ufanie partnerowi – to nawigator planuje logikę implementowanego rozwiązania i kierowca, choć ma prawo głosu, nie może stale kwestionować drogi obranej przez partnera.

Nawigator – jak już wspomniałem, to „mózg operacji”. Do niego należy planowanie logiki i przewidywanie kolejnych kroków. Jego rolą jest:

• komunikowanie kierowcy kolejnych elementów kodu, który ten ma napisać
• śledzenie kodu – wyłapywanie błędów w kodzie i informowanie o tym partnera
• kontrolowanie efektów implementowanego rozwiązania (outputu w konsoli czy w przeglądarce)
• notowanie uwag, pomysłów i zadań, które nie są związane z aktualnie tworzonym kodem, ale które należy poruszyć później
• cierpliwe oczekiwanie – nawigator nie może rozpraszać kierowcy i wszystkie uwagi co do refaktoryzacji czy nowych wytycznych musi wstrzymać do momentu ukończenia zadań przed kierowcę.

Dodatkowo obaj programiści powinni jasno się komunikować i reagować, gdy druga strona milczy, oraz być otwarci na pomoc swojego partnera: dopytywać o niejasne zagadnienia czy prosić o radę.

Organizacja sesji pair programmingu

Jeżeli jesteś już członkiem zespołu developerów i czeka Cię pierwsza sesja programowania w parze – zapytaj kolegę, team leadera lub managera, czy macie już jakieś przyjęte praktyki dla pair programmingu. To pozwoli Ci się lepiej przygotować.

Przed przystąpieniem do pair programmingu

W każdej firmie przygotowanie do sesji może być bardziej lub mniej szczegółowe. Może tylko omówicie swoje spojrzenie na problem, może rozpiszecie go na samoprzylepnych kartkach, a może wrzucicie taski na tablicę kanban.

Tak czy inaczej, warto zaplanować sobie pracę:

• wyznaczyć zakres zadania – aby „nie odpłynąć” od głównego celu i nie rozpraszać się mniej istotnymi zadaniami
• ustalić wspólną wizję – dzięki temu będzie większa szansa, że podczas programowania driver nie pogubi się w planach nawigatora, a po zamianie ról „nowy” nawigator bez przeszkód będzie kontynuować rozpoczęty przez poprzednika sposób działania
• podzielić zadanie na mniejsze taski – w ten sposób zaoszczędzimy czas i nie będziemy się rozpraszać dyskusją o tym, co jeszcze należy zrobić (dobrze, by nawigator mógł już tylko określać to, „jak” coś ma być zaimplementowane, a nie decydować na szybko, „co” należy zrobić).

Czas pracy i czas przerwy

Podstawą programowania w parze są 2 elementy:

1. Stosowanie przerw – ponieważ zarówno rola nawigatora, jak i kierowcy wymaga pełnego skupienia, przerwy są niezwykle ważne. Bez nich nich programowanie nie będzie efektywne. Zadaniem obu developerów jest przestrzeganie czasu wyznaczonego dla poszczególnych sesji (wbrew pozorom czasem trudno oprzeć się „jeszcze tej małej poprawce”, która w efekcie zajmuje kolejne 20 minut).
2. Zamiana ról – role kierowcy i nawigatora wymagają innego trybu pracy, innego punktu widzenia. Ponieważ każdy z nas się różni, takie odmienne spojrzenie na zadanie pozwala wyłapać więcej nieścisłości, błędów, luk oraz zaproponować takie elementy implementacji, na które mógł nie wpaść nawigator „z pierwszej zmiany”.

Ilość sesji, czas jednej sesji i przerwy ustala się zależnie od preferencji developerów lub zasad panujących w zespole. Programowanie w parze, jeśli poświęcamy się swojej roli w 100%, jest dość wyczerpujące: wymaga nieustannego skupienia, ciągłej komunikacji i czujności. Dlatego początkujący programiści pewnie lepiej odnajdą się w krótszych okresach.

Do regulowania czasu można wykorzystać technikę Pomodoro, czyli system:

• 25 minut kodowania
• 5 minut przerwy i zmiana ról
• 25 minut kodowania.

Gdy programiści są doświadczeni, mogą wydłużyć czas sesji nawet dwukrotnie: 50-10-50.

Sposób współpracy i komunikacji developerów

Podział na role, zwłaszcza gdy programujemy w parze zdalnie i mamy dostęp do edycji kodu w tym samym czasie co partner (np. dzięki rozszerzeniu do VS Code – Live Share Extension Pack), rodzi co najmniej dwie pokusy:

• dla nawigatora – by zacząć samodzielnie pisać kod
• dla kierowcy – by przerywać nawigatorowi i proponować własne rozwiązania (choć rozwiązania nawigatora są równie dobre).

Dlatego programowanie w parze może być frustrujące i na pewno nie każdy się do niego nadaje. Wymaga samodyscypliny: trzymania języka za zębami i rąk przy sobie 😉

Główne zasady komunikacji między developerami

Dla nawigatora:

• Wydawaj precyzyjne polecenia, ale nie dyktuj kodu – kierowca też jest programistą i doskonale wie, jak np. zaimportować jakiś zasób. Wystarczy więc polecenie „Zaimportuj teraz plik icon.svg” (a nie: „Na górze dokumentu napisz import, otwórz cudzysłów, napisz kropka, kropka, ukośnik, icon, kropka svg…”).
• Nie stosuj skrótów myślowych – o ile kierowca na pewno zrozumie polecenie „Zadeklaruj funkcję o nazwie startTimer”, o tyle może nie domyślić się, że chodzi Ci o wyrażenie funkcyjne z funkcją strzałkową.
• Nie rozpraszaj kierowcy „planami na przyszłość” – jeśli wpadłeś na jakiś nowy pomysł do późniejszej realizacji, zachowaj go dla siebie i po prostu zanotuj.

Dla kierowcy:

• Pytaj partnera o zgodę, gdy chcesz coś zasugerować – być może nawigator jest właśnie w trakcie jakiegoś procesu myślowego i jego przerwanie wydłuży czas Waszej pracy.
• Dopytuj, gdy nie rozumiesz – to szybsze niż ciągłe kasowanie nieprawidłowo napisanego kodu.

Dla obu partnerów:

• Nie rozpraszajcie się nieistotnymi dla zadania uwagami (np. „To dokładnie jak w tym memie…”).
• Szanujcie rolę partnera, a na swojej skupcie się w 100%.

Pair programming – zarzuty i korzyści

Programowanie w parze ma działać w myśl zasady „co dwie głowy to nie jedna”, by zwiększyć wydajność tworzenia sprawnego oprogramowania i zmniejszyć ryzyko powstania błędów. Ale czy rzeczywiście jest to optymalny sposób pracy?

Wielu developerom, którzy od samego początku kodują „sam na sam z komputerem”, może nie mieścić się w głowie programowanie w parze. I tak jak wyżej napisałem: nie każdy będzie się do tego nadawał.

Często powtarzanym zarzutem dla pair programmingu jest brak swobody pisania kodu: programiści są przyzwyczajeni do tego, że sami planują, analizują i piszą kod – a nie: dyktują go, czy odtwarzają to, co dyktuje osoba obok.

Drugi zarzut to zepsucie relacji między partnerami: nie każdy potrafi tolerować „narzucanie mu” sposobu pracy i będzie irytował się w roli kierowcy. Ktoś inny z kolei może słabiej radzić sobie z mówieniem o kodzie i ciągłe precyzowanie poleceń w roli nawigatora będzie go okropnie frustrowało. W obu przypadkach irytacja może się przenieść na programistę z pary.

Trzeci zarzut to oczywiście kwestionowanie opłacalności takiego rozwiązania. Dwóch programistów mogłoby przecież pracować niezależnie od siebie nad dwoma zadaniami, a w pair programmingu – pracują nad jednym zadaniem i każdy z nich nadal otrzymuje swoje wynagrodzenie.

Czy pair programming ma zatem jakieś plusy?

Z pewnością nie ma sensu go stosować zawsze i wszędzie. Jednak daje on oszczędność czasu i większą efektywność pracy. Sprawdzi się więc tam, gdzie musimy coś zrobić szybko i dokładnie. Czyli gdzie? Na przykład gdy goni nas deadline – a wdrażane rozwiązanie wpływa na wydajność całego programu – lub gdy na produkcję przedrze się błąd.

Pair programming może być więc dobrym narzędziem do zażegnywania kryzysów – a takie narzędzie warto znać i umieć z niego korzystać.

Pair programming na rozmowie rekrutacyjnej

Na rozmowie technicznej częściej pewnie spotkasz się z tzw. live codingiem. Live coding to sytuacja, w której kandydat rozwiązuje zadanie, opowiada o swojej koncepcji i na bieżąco omawia tworzony kod, a rekruter obserwuje działania kandydata i zadaje pytania odnośnie do wybranych rozwiązań.

Rekruter może jednak zechcieć sprawdzić Twoje umiejętności z zakresu programowania w parze – zwłaszcza jeśli jest ono często stosowane w zespole.

Jak przygotować się do pair programmingu na rekrutacji

Po lekturze tego artykułu wiesz już, czego wymaga się od roli nawigatora i kierowcy, i prawdopodobnie wyczuwasz, co może sprawić Ci problem.

Ponieważ zwykle jest to komunikacja, to na niej się skupię – zwłaszcza, że przyda Ci się ona także podczas live codingu czy opowiadania o kodzie w którymś z projektów w portfolio. Jak ją ćwiczyć?

Metodą pośrednią jest mówienie do samego siebie czy do gumowej kaczki. Na głos – nie w myślach, nie szeptem. Im lepiej odtworzysz mogącą Cię spotkać sytuację, tym lepiej się w niej odnajdziesz, gdy już nastąpi (tak działa nasz mózg).

Jednak po takich ćwiczeniach nadal będziesz mieć obawy, czy wyrażasz się wystarczająco jasno, czy nie robisz błędów, czy nie sprawiasz wrażenia osoby, która „plącze się w zeznaniach”.

Dlatego najlepszym rozwiązaniem jest znalezienie osoby do współpracy. Dzięki temu:

• odtwarzasz cały proces live codingu lub programowania w parze – przestaje on być dla Ciebie czymś nowym i nie spędza już snu z powiek
• dostajesz cenny feedback od partnera: o swoim podejściu, umiejętnościach i autoprezentacji.

Jeśli masz już kogoś do wspólnych ćwiczeń, ale nie wiesz, jak zorganizować pierwszy pair programming, możesz zainspirować się artykułem o pair programmingu dla początkujących.

Co o pair programmingu mówi programista

🎧 Posłuchaj, co o pair programmingu mówi doświadczony PHP developer w odcinku podcastu „Czym jest pair programming i jak skutecznie go stosować”. Na stronie odcinka znajdziesz również transkrypcję.

Choć pair programming nie jest dla każdego i nie jest do wszystkiego, stanowi cenne narzędzie podczas radzenia sobie z sytuacjami wymagającymi ostrożności, dobrego przewidywania i szybkiej realizacji zadania. Dlatego warto się go nauczyć. Nie musi to być Twój ulubiony sposób programowania, lecz jak można odmówić dobremu narzędziu do zażegnywania kryzysów w projekcie?