Programowanie parami

Programowanie parami
Polecane artykuły
Mob programming Burza mózgów Test driven development Refactoring Mikroserwisy Teamware Struktura zespołów projektowych Etapy tworzenia zespołu INVEST

Programowanie w parach jest jedną z podstawowych technik wytwarzania kodu w programowaniu ekstremalnym. Stosujące je zespoły organizują pracę w dwuosobowych grupach składających się z programistów, którzy siedzą przy jednej stacji roboczej. Zazwyczaj jeden z nich pisze kod a drugi przygląda się temu procesowi. Obaj cały czas debatują na temat kodu. Pozwala to na redukcje błędów (cały czas dwie pary oczu szukają nieprawidłowości) oraz zmęczenia (gdy jeden programista poczuje znużenie, drugi może przejąć pisanie kodu). Tryb pracy w parach pozwala również na zwiększenie efektywności poprzez ciągłe omawianie pomysłów, co w efekcie powoduje nieustanną burze mózgów. Dodatkową korzyścią jest wzajemna kontrola pod kątem korzystania z dobrych praktyk (jednej osobie łatwiej jest podjąć decyzje o zastosowaniu nieeleganckiego rozwiązania - na pewno zrezygnuje z niego jeśli inny programista patrzy na jego kod).

TL;DR

Programowanie w parach to technika polegająca na pracy dwuosobowych grupach programistów, którzy debatują na temat kodu. Ma wiele korzyści, takich jak redukcja błędów, zmniejszenie zmęczenia i zwiększenie efektywności. Rotacja członków zespołów oraz odpowiednio zorganizowana przestrzeń pracy są ważne dla sukcesu tej metody. Tworzenie par może być oparte na różnych konfiguracjach, zależnie od poziomu doświadczenia programistów. Istnieją również trudności związane z pracą w parach, takie jak niezgodność charakterów czy preferencje pracy samodzielnej.

Historia

Programowanie parami wywodzi się z naturalnego procesu tworzenia oprogramowania, w którym jedni programiści prosili innych o ocenę ich pracy. Wynikało to ze świadomości ludzi, że nikt nie jest bezbłędny. W roku 1953 Fred Brooks zdał sobie sprawę z zalet programowania w parach, kiedy wraz z Williamem Wrightem, jego kolegą ze studiów, napisał około 1500 linii kodu, które działały poprawnie za pierwszym razem i nie były obarczone błędami. Z biegiem lat większa liczba osób zgłębiała to pojęcie aż do roku 1995, kiedy to Larry Constantine wprowadził termin "Dynamic Duos" a Jim Coplien napisał o programowaniu w parach. Termin przyjął się powszechnie od momentu pojawienia się manifestu agile..

Rotacja członków zespołów

Rotacja par jest często używaną praktyką w projektach ze średnimi lub dużymi zespołami. W niektórych przypadkach bardziej wydajnym sposobem jest podział na programistę wiodącego, który cały czas zajmuje się tym samym zadaniem oraz programistę pomocnika, który przesiada się co jakiś czas do innych programistów wiodących (te role także, po zakończeniu zadania, można zamieniać). Zaletami takiego podejścia są:

• dzielenie się wiedzą oraz doświadczeniem przez programistów,
• pokrycie wielu obszarów wymagających programowania przez wielu deweloperów (unikane jest wtedy tworzenie tzw. programistów dziedzinowych, znających tylko jeden obszar rozwijanego systemu),
• budowa zaufania oraz integracja zespołów.

Przestrzeń pracy

Programowanie w parach jest efektywne tylko w przypadku, kiedy przestrzeń pracy zorganizowana według poniższych wytycznych:

• swobodna i komfortowa możliwość obsługi klawiatury oraz myszki przez jednego programistę, podczas gdy obaj programiści tak samo dobrą widoczność na kod. Zaleczany jest taki układ, który w przypadku zmiany programisty wiodącego pozwala na podanie klawiatury i myszki a nie wymusza przesiadanie się,
• przestrzeń prowokująca kontakt pomiędzy parami programistycznymi (jest to efekt oczekiwany) - w takiej sytuacji układ stanowisk pracy ułatwia kontakt wizualny oraz głosowy bez potrzeby przemieszczenia się

Tworzenie par

Każdy z programistów może zostać sklasyfikowany jako ekspert lub początkujący. W zależności od konfiguracji stwarza to pewne szanse oraz ryzyka:

• Początkujący - Początkujący - Jest zalecany do stworzenia łatwej części kodu. Pozwala na naukę dla obu programistów - tym bardziej efektywną im bardziej odległe są obszary, które programiści pokrywają swoją wiedzą. Jest to metoda pozwalająca na ograniczenie nadzoru nad wdrażającymi i uczącymi się programistami, ale nie na jego eliminację.
• Ekspert - Początkujący - Jest najlepszym sposobem na wdrożenie nowego programisty oraz szybkim sposobem podnoszenia jego kwalifikacji. Często postrzegana jest jako marnotrawienie czasu eksperta, natomiast im częściej początkujący wskazuje możliwe błędy eksperta, ten zaczyna przekonywać się do takiej formy pary. Dodatkowo początkujący może wprowadzić świeże spojrzenie na prace, która musi zostać wykonana. Warunkami, pod jakimi taka para ma możliwość zadziałać są: cierpliwość oraz chęć nauczania eksperta, nieprzerośnięte ego eksperta, które pozwala na słuchanie początkującego. Z drugiej jednak strony, początkujący programista może być za mało pewny siebie.
• Ekspert - Ekspert - Jest to najlepszy wybór w przypadku skomplikowanych problemów lub takich, w przypadku których defekt kodu powoduje błędy krytyczne. Ten rodzaj pary powoduje znaczne przyśpieszenie procesu tworzenia kodu, ponieważ posiada bardzo mały udział wyjaśniania tworzonego kodu w całym procesie jego tworzenia. Istnieje również bardzo niskie prawdopodobieństwo "zablokowania" się programistów w przypadku napotkania na trudny problem.

Problemy

Poza korzyściami wynikającymi ze stosowania programowania w parach istnieją trudności związane z takim podejściem, takie jak:

• zsynchronizowanie czasu dwóch programistów na wspólne zadanie,
• niezgodność charakterów współpracujących programistów - może ona powodować trudności komunikacyjne oraz rozbieżność w poglądzie na problem a w konsekwencji niemożność znalezienia wspólnego rozwiązania,
• niektórzy pracownicy preferują pracę samodzielną - wtedy albo znajdą oni sposób na poradzenie sobie z programowaniem w parach, albo manager nie powinien zmuszać ich do takiego tryby pracy,
• przyzwyczajenie programistów do pracy w parach, co powoduje, że przy pracy w pojedynkę programista taki może utknąć przy prostym problemie - można powiedzieć, że niejako rozleniwił się przy programowaniu parami przez co ciężko znaleźć mu motywację do pracy samemu.

Bibliografia

• Andrew Stellman, Jennifer Greene (2015). Agile. Przewodnik po zwinnych metodykach programowania, Wydawnictwo Helion, Gliwice, s. 169
• Gerardus Blokdyk (2018). Pair Programming Second Edition, Wydawnictwo Emereo Publishing
• Ines Coimbra Morgado, Luis Miguel Rocha, Dr. Roberto Frias (2015). Pair Programming, Universidade do Porto, Porto
• Kai Spohrer (2016). Collaborative Quality Assurance in Information Systems Development, Wydawnictwo Springer
• Laura Plonka, Helen Sharp, Janet van der Linden, Yvonne Dittrich (2015), Knowledge transfer in pair programming: An in-depth analysis, International Journal of Human-Computer Studies nr 73, s 66-78
• Sook Young Choi (2018), Design of an Instructional Model based on Pair Programming for Improving Novice Programmers' mental models, Information nr 21, s 351-358

Autor: Joanna Szarlej