Pair programming

Co to w zasadzie jest pair programming?

Pojęcie pair programming odnosi się do tworzenia jednego projektu IT lub jego fragmentów w parach. Jeden z programistów pisze kolejne wiersze kodu, podczas gdy ten drugi śledzi kod na ekranie monitora i zwraca uwagę na ewentualne błędy. Takie działanie w parach w układzie tzw. driver & navigator jest czynnością wymienną. Oznacza to, że deweloperzy zamieniają się co określoną jednostkę czasu wykonywanym rolami.

Skąd się wzięło?

Metodyką z jakiej wywodzi się Pair Programming jest Extreme Programming, czyli programowanie ekstremalne. Opiera się ono na kilku prostych zasadach, z której każda ma strategiczne znaczenie dla projektu: • simple code - polega na tworzeniu tylko takiego kodu, który jest rzeczywiście potrzebny czy zaplanowany. Nie ma tu miejsca na przypadkowość czy autorskie kombinacje drivera, dzięki czemu uzyskać można bardziej zrozumiały i zwarty kod • sprawna komunikacja - zespół, w którym role są zamienne, potrafi komunikować się ze sobą jasno i zwięźle. • wspólna motywacja - programista w zespole posiada porównywalny poziom wiedzy jak partner. Uzupełniają się zatem, ale też wymagają od siebie nawzajem rzetelnie wykonanej i sprawnej pracy

Jak to działa w praktyce?

Wykorzystując doświadczenie dwóch osób przy kodowaniu jednego zadania, łatwiej eliminuje się błędne założenia już na etapie tworzenia kodu. Szybciej można wykryć i naprawić błędy logiczne oraz reagować ad hoc przy tzw. literówkach. Ponadto istnieje tu wyraźny podział ról, zatem driver, który tworzy kod, skupia się na implementacji danego fragmentu kodu. Nawigator czuwa w tym czasie nad prawidłowym kierunkiem procesu tworzenia kodu. Trochę jak kierowca rajdowy który prowadzi auto i jego pilot który podpowiada mu wszystkie niezbędne informacje o trasie którą pokonują.

Pair programming to nie nowość!

Historia tego rozwiązania jest datowana na 1953 rok, ale dopiero wiele lat później bo w 1992 roku zostało stworzone określenie “Dynamic Duo” opisujące tworzenie kodu przez jedną osobę, pod kontrola drugiej. Kolejne lata przynoszą dalsze publikacje dotyczące kodowania w parach, które wykorzystywano w poszczególnych technologiach. Oznacza to, że pair programming sprawdza się od kilkudziesięciu lat i był wykorzystywany przy realizacji niezliczonych i różnorodnych projektów.

Jakie korzyści przynosi pair programming?

Bezsprzecznie wzrasta code quality, czyli jakość wytwarzanego kodu. Wykrywanie błędów w kodzie już na etapie jego tworzenia to znaczna optymalizacja późniejszych kosztów jego utrzymania. Unika się wtedy wielogodzinnych testów oraz poprawek, gdy po pewnym czasie od napisania jakiegoś fragmentu kodu trzeba do niego wrócić i od nowa go prześledzić, aby znaleźć nieprawidłowości. Rozproszenie wiedzy o fragmentach systemu pomiędzy dwie osoby zamiast jednej, powoduje że wiedza ta nie ulegnie tak szybko zapomnieniu i może zostać szybciej przekazana dalej gdy programiści zmienią się w inne pary przy następnych zadaniach. Zauważalnym wynikiem badań było też zwiększenie efektywności wykonanej pracy w stosunku do czasu w jakim została ona wykonana. Te same zadania realizowane przez dwóch programistów osobno zajmowały więcej czasu niż gdy pracowali oni w parze. Zatem realizacja projektu jest o wiele krótsza, a efektywność pracy większa, dzięki czemu nowy kod jest gotowy do oddania do w krótszym czasie. Zwiększa się zaangażowanie zespołu, który realizuje projekt, dzięki czemu skuteczniej eliminuje on zagrożenia i błędy, co gwarantuje lepszą jakość wytwarzanego oprogramowania. Dzisiejszy zwinny software development wymaga szybkiego reagowania na wszystkie zmiany. Pair programming zmniejsza nakład na komunikację i koordynację o połowę. Obok korzyści dla projektu występują także zalety w zakresie personalnym: • deweloper może zastąpić partnera bez straty dla projektu, np. w przypadku urlopu czy choroby • na etapie rekrutacji nowego pracownika, doświadczony stażem w danej firmie programista, łatwo sprawdzi kompetencje dewelopera wykorzystując pair programming • w prosty sposób następuje wdrożenie nowego programisty, ponieważ zespół pracuje nad wspólnym projektem dlatego przystosowanie się nowego pracownika jest wspólną motywacją

Co na to deweloperzy?

Komfort pracy to jedna z wytycznych jakimi kierują się programiści. Obok ergonomii pracy ważne jest też samo wykonywanie działań w sposób nie nastręczający problemów. Na przestrzeni lat przeprowadzono wiele badań, wywiadów i ankiet wśród programistów. Podsumowując i uśredniając wyniki tych badań, można stwierdzić, że znaczącym dla pracownika aspektem jest większe poczucie pewności, że projekt nie ma błędów, oraz poczucie że odpowiedzialność za projekt lub jego fragment (tzw. code ownership) nie spoczywa tylko na jednej osobie.

Czy pair programming ma wady?

Przy tak wielu korzyściach dla realizacji projektu IT, jego późniejszego rozwoju i utrzymania, trzeba jasno nakreślić jedną istotną kwestię, która przez wiele osób może być odbierana jako wada. Inwestycja jaką trzeba ponieść na początku realizacji projektu przy zastosowaniu programowania w parach to zatrudnienie dwóch osób, zamiast jednej. Pair programming nie sprawdzi się gdy w zespole pojawią się jakieś problemy na tle osobistym. Nie wszyscy w zespole muszą za sobą przepadać - takie pary nie będą pracować efektywnie. Niestety nie działa wtedy ani "pair" ani "programming" a tym bardziej "code quality". Takie problemy należy rozwiązać w pierwszej kolejności! Bezsprzecznie wyższa jakość kodu w długofalowym ujęciu zmniejsza koszty utrzymania projektu i powoduje że inwestycja zwraca się z nawiązką w późniejszym życiu projektu.

Konkluzja

Pair programming jest rozwiązaniem znacznie efektywniejszym i korzystniejszym niż praca pojedynczego dewelopera.