Pair programming wzmacnia motywację, zacieśnia więzi w zespole i pozwala stworzyć jak najlepszy kod. Wywiad z Magdą Szumny

– W trakcie pair programmingu czujemy pozytywną presję, żeby się wykazać i nie zawieść naszego partnera. Obie osoby biorą odpowiedzialność za dany fragment kodu i razem pracują, żeby był on jak najlepszy — mówi Magdalena Szumny, Inżynierka Rozwoju Oprogramowania w ASSA ABLOY, która w takim modelu pracuje już od wielu lat. Komu poleca pair programming i dlaczego?

Czym jest pair programming? Kiedy po raz pierwszy zetknęłaś się z takim podejściem do pracy developerskiej?

Pair programming to technika rozwoju oprogramowania, w której dwie osoby pracują razem nad tym samym zagadnieniem programistycznym. Spotkałam się z takim modelem pracy już na początku mojej ścieżki zawodowej, czyli około 10 lat temu, ale wtedy nie wiedziałam, że jest to jakaś szczególna metodologia i ma swoją nazwę. W naturalny sposób przy bardziej skomplikowanym zagadnieniu lub przy większych problemach dwie osoby siadały do jednego komputera i próbowały wymyślić rozwiązanie albo naprawić problem. 

W tamtych czasach pair programming nie był moją główną techniką pracy – raczej zdarzał się od czasu do czasu w razie potrzeby. W tym momencie regularnie pracuję w tym modelu, ale w innej formie niż to miało miejsce na początku.

Czy pair programming zmieniał się jakoś na przestrzeni ostatnich lat? Mam tu głównie na myśli wybuch pandemii i powszechną pracę zdalną, która może utrudniać pracę w parach.

W klasycznym pair programmingu dwie osoby fizycznie znajdują się przy jednym komputerze. Jedna z osób pełni rolę drivera, czyli osoby piszącej kod, a druga obserwatora/nawigatora, który sprawdza kod w trakcie jego pisania. Role zazwyczaj nie są na stałe przypisane do danej osoby. W ten sposób pair programming wyglądał w czasach przed powszechnością pracy zdalnej.

Takie klasyczne wydanie w większości sytuacji straciło już rację bytu, ponieważ rzadziej spotykamy się w biurach, a gdy  już jesteśmy w biurze, to zespoły poświęcają ten czas na spotkania, które warto odbyć osobiście, uzgodnienia, czy po prostu integrację zespołu.

W tym momencie w trakcie pair programmingu każda z osób zazwyczaj przebywa w swoim własnym domowym biurze, a wspólną pracę umożliwiają rozszerzenia do popularnych IDE. Dzięki dostępnym narzędziom dwie osoby (lub nawet więcej) mogą w tym samym czasie pisać kod, więc klasyczny podział na role ma mniejszy sens. Oczywiście dalej można się umówić, że jedna z osób głównie pisze, a druga sprawdza kod, ale bardziej elastyczne podejście ma zazwyczaj więcej sensu. 

Nie musimy w danym momencie pracować nad dokładnie tym samym fragmentem kodu. Może się okazać, że wiemy dokładnie, jaki kod ma powstać, więc każda z osób może pracować przykładowo nad innym plikiem lub funkcją i konsultować się tylko w razie potrzeby (oczywiście będąc cały czas w trakcie sesji pair-programmingowej). 

Możemy stwierdzić, że dany fragment kodu jest skomplikowany i chcemy go pisać razem, ale już bez konkretnego podziału na role. A może na razie dopiero sprawdzamy, jakie mamy możliwości? W tym przypadku możemy przeglądać kod razem albo podążać różnymi ścieżkami i tylko w razie znalezienia jakiegoś tropu „zawołać” (większość narzędzi umożliwia coś takiego) drugą osobę do danego fragmentu kodu.

A czy zdalny pair programming ma w ogóle sens? Czy też może sprawdza się znacznie lepiej od kodowania ramię w ramię, w biurze?

Moim zdaniem dostępne narzędzia do zdalnego pair programmingu dają nam o wiele więcej możliwości, niż praca ramię w ramię w biurze. W trakcie klasycznego pair programmingu często słyszało się: „czy mógłbyś/mogłabyś przescrollować w górę?”, „jeszcze średnik”, „o, tutaj masz literówkę” (i wskazywanie palcem na ekran). W tym momencie możemy scrollować sami, zaznaczyć jakiś tekst, dodać średnik i poprawić literówkę nawet bez wspominania o tym.

Poza tym podczas pracy zdalnej wiele osób może mieć problem z motywacją. W trakcie pair programmingu czujemy pozytywną presję, żeby się wykazać i nie zawieść naszego partnera. Obie osoby biorą odpowiedzialność za dany fragment kodu i razem pracują, żeby był on jak najlepszy.

Ponadto w trakcie pair programmingu mamy znacznie lepszy kontakt z drugą osobą, więc w dobie pracy zdalnej może to zaspokoić nasze potrzeby społeczne. Oprócz samej pracy możemy przecież porozmawiać o tym, jak minął weekend, jaki ciekawy serial ostatnio oglądaliśmy albo pochwalimy się zdjęciem naszego psa 😉

Jakie narzędzia mogą ułatwić organizację pracy w ramach pair programmingu?

To np. Live Share w VS Code, Replit, Code Together. Ja osobiście korzystam z wtyczki Live Share w VS Code, więc jej możliwości znam najlepiej. Jedna z osób (nazwijmy ją hostem) tworzy za pomocą Live Share sesję i generuje link, który partner może wykorzystać do dołączenia do sesji. Nie trzeba posiadać zainstalowanego VS Code – można też użyć wersji przeglądarkowej. 

Taka sesja umożliwia nam wspólne przeglądanie i edycję kodu hosta. Każda z osób może otwierać pliki, edytować kod. Widzimy kursory współuczestników sesji, a także możemy ustawić opcję, że chcemy podążać za daną osobą lub zawołać kogoś innego do kodu, nad którym teraz pracujemy. Funkcjonalność debuggowa VS Code jest dostępna także dla gościa sesji, czyli może podglądać wartości zmiennych, stack trace, czy też korzystać z konsoli. 

Oczywiście prawa edycji kodu lub dostępu do konsoli nadaje host. Dane takiej sesji są zaszyfrowane end-to-end. Do uwierzytelniania korzysta się z konta Microsoft lub GitHub.

Jakie są Twoje doświadczenia z takim modelem pracy?

Mam bardzo pozytywne doświadczenia, ale wiem też, że nie jest to dla każdego. Na pewno ważne jest znalezienie partnera, z którym dobrze nam się pracuje i którego po prostu lubimy. Warto zadbać o robienie regularnych przerw, ponieważ taka praca jest w moim odczucia bardziej wyczerpująca. Poza tym, że piszemy kod, to jeszcze mamy na niego różne pomysły i przedyskutowanie ich i zrozumienie na pewno zabiera część naszych sił i zasobów.

Co Ci się najbardziej podoba w pair programmingu? A może ma on też jakieś wady?

Moją ulubioną rzeczą w pair programmingu jest to, że możemy zobaczyć, jakie różne pomysły na ten sam fragment kodu mogą mieć dwie osoby. Bardzo lubię konstruktywne dyskusje nad strukturą kodu na poziomie funkcji, plików i całych komponentów. W trakcie takiej pracy można się bardzo wiele nauczyć, a także przekazać swoją wiedzę innym. 

Wspaniale pracuje się w gronie osób z doświadczeniem, ale myślę, że pair programming może mieć także wielką wartość dla osób początkujących pracujących w parze z doświadczoną osobą.

Główną wadą dla mnie jest mniej elastyczny czas pracy. Musimy dostosować się do czasu pracy drugiej osoby i uzgodnić czas na przerwy. Ponadto proces samego tworzenia kodu jest wolniejszy, ponieważ więcej czasu spędzamy na dyskusji na temat podejścia, ale moim zdaniem skutkuje to o wiele lepszą jakością kodu i zdecydowanie skróca czas poświęcony na review kodu.

W jaki sposób pair programming może się wpasować w procesy danej firmy? Jak dopasować choćby czas rzeczywisty takiej pracy?

Warto przedyskutować w zespole, jakie zmiany wprowadzić w procesie, żeby dopasować go lepiej do pair programmingu. Jeśli mamy sformalizowany proces review, to skoro dwie osoby pracowały nad danym kodem, może w tym przypadku warto ten krok ominąć?

Kolejna rzecz, która warto rozważyć to prawa autorskie. W wielu firmach mamy możliwość skorzystania z autorskich kosztów uzyskania przychodu, ale najczęściej wymaga to przechowywania próbek lub całości naszego kodu. Jak przy pair programmingu określić autora? Na pewno warto się nad tym zastanowić.

W trakcie estymowania czasu pracy nad danym zadaniem warto wziąć pod uwagę to, że faza tworzenia kodu może potrwać dłużej, ale zyskujemy za to jakość i krótszy czas review.

Pair programming może być także sposobem na szybsze wdrożenie nowych pracowników albo przekazanie kodu.

Na pewno ważne z perspektywy zespołu i utrzymania kodu jest to, że daną część kodu znają bardzo dobrze co najmniej dwie osoby.

Co jeszcze w IT można robić w parach, oprócz samego kodowania? 🙂

Myślę, że ciekawej odpowiedzi udzieliłby mój kolega z zespołu (Tomek, pozdrawiam) 🙂 A tak na serio, oprócz samego kodowania w parach (lub w większym gronie) można debuggować, przekazywać swój kod do innego zespołu, wdrażać nowych członków zespołu, czy też organizować sesje przekazania wiedzy. Myślę, że ciekawym zespołem do debuggowania mógłby być zespół stworzony z programisty i testera. 

Kolejnym interesującym sposobem na przekazanie naszego kodu do innego zespołu (lub firmy) byłoby stworzenie interaktywnej sesji, podczas której możemy wytłumaczyć nasz kod, a może nawet napisać podczas takiej sesji krótki program wykorzystujący ten kod? Myślę, że możliwości jest bardzo wiele.

Podsumowując: kiedy, gdzie i komu poleciłabyś wdrożenie pair programmingu?

Myślę, że większość zespołów bardzo by zyskała na wprowadzeniu pair programmingu, o ile podejdziemy do tego typu narzędzi elastycznie i wpasujemy w istniejący proces i pracę zespołu. Oczywiście nie jest to optymalne rozwiązanie dla wszystkich członków zespołu, więc warto, żeby pracowali tak tylko chętni. 

Może warto wprowadzić pair programming tylko dla zadań skomplikowanych lub o wysokim priorytecie? A może ktoś chciałby pracować tak na co dzień? Opcji jest dużo.

---

Magdalena Szumny. Inżynierka Rozwoju Oprogramowania w ASSA ABLOY – liderze w zakresie rozwiązań kontroli dostępu. Od 10 lat programuje systemy wbudowanie w C. W wolnym czasie zajmuje się planowaniem podróży.

Zdjęcie główne pochodzi z Envato Elements.