Technika programowania w parach – moja opinia

Pierwszy raz z terminem „pair programming” spotkałem się jeszcze na początku studiów, na jednym z teoretycznych wykładów o ogólnej inżynierii oprogramowania. Od razu podaję sprostowanie. Na większości wykładów, mimo iż pewnie były bardzo ciekawe, nie udawało mi się zazwyczaj być. Te pozostałe natomiast, pamiętam bardzo wyraźnie.

Pisanie kodu w dwójkach wydawało mi się wówczas co najmniej dziwne. Widziałem w wyobraźni te bójki o klawiaturę, bo przecież każdy chce coś robić, a nie siedzieć. Z praktycznym zastosowaniem tej techniki spotkałem się dopiero w firmie, w której obecnie pracuję. Wygląda to w ten sposób, ze w danym momencie to jedna ospair_programmingoba pisze kod, natomiast zadaniem drugiej jest baczna obserwacja i analiza tego co powstaje. Na pierwszy rzut oka, wygląda to jakby ta drugą osoba odpoczywała. Owszem, jest to odpoczynek od samego pisania czy projektowania kodu na parę chwil, ale należy uruchomić wówczas drugą półkulę i wybiegać myślami kilka kroków w przód, żeby zdążyć w porę z podpowiedzią osobie piszącej kod.

Jeśli przykładowo widzisz, że druga osoba pisze coś, co Twoim zdaniem skończy się błędem albo masz po prostu lepszy pomysł na dane rozwiązanie, wtrącasz się bez wahania. Pozwalasz oczywiście dokończyć myśl, a następnie grzecznie podpowiadasz lub wyrażasz opinie. Niestety, może to być trudne dla przemądrzałych osób i irytujące dla tych, którym przyjdzie z nimi współpracować. Mówi się, że idealnie powinno się zmieniać co 10 minut, ale w praktyce chodzi o zmianę po zakończeniu pomniejszego fragmentu pracy.
Nawet pracując już w tym modelu, nadal podśmiewałem się z tego, myśląc sobie:

„He he, pracuję praktycznie pół czasu, a płacą mi za całość.”

Przestałem się jednak śmiać w momencie gdy przy tej samej aplikacji, innego dnia, przyszło mi działać w pojedynkę. Po uruchomieniu zmodyfikowanej aplikacji u klienta, okazało się, że brakuje paru drobnych, ale istotnych szczegółów, przez które aplikacja się wysypała. Tutaj właśnie zabrakło tej drugiej nadzorującej osoby, która prawdopodobnie podpowiedziałaby na czas, zwłaszcza jeżeli osoba ta ma większe doświadczenie w biznesie. Samoistnie wówczas pomyślałem, że ta technika ma jednak sens. Nie jest to złoty środek na wszystkie problemy programistów, ale odpowiednio zastosowana daje całkiem nieźle efekty.

5231ed002999949ded6b2969d74f8478

Nie wyobrażam sobie pracować w ten sposób przy mniejszych projektach, takich jak na przykład mini gry. Natomiast w przypadku prac typowo biznesowych (na przykład kalkulacje finansowe), to się po prostu sprawdza. Dokładając do tego Test Driven Development, można działać w ten sposób, że osoba pierwsza pisze test, a zadaniem drugiej jest stworzenie kodu zdającego go, po czym zmiana.

Wniosek z tego jest więc taki, że wszystkiego należy spróbować na własnej skórze, a dopiero potem wyrabiać sobie opinie. Jeżeli masz swoją opinię albo doświadczenie z tą technika, zachęcam do dzielenia się nimi w komentarzach!