Pair programming: zasady i etykieta

26 czerwca
Alexey Mironenko
Pair programming: zasady i etykieta
Alexey Mironenko, doświadczony programista Java, kieruje rozproszonymi zespołami technicznymi od 8 lat. Uważa, że programowanie łączy ludzi, ale tylko gdy programiści kontrolują procesy robocze i tworzone przez nich oprogramowanie. Technika  pair programming  jest aktywnie wykorzystywana w projekcie, nad którym obecnie pracuje. W artykule Alexey dzieli się swoimi przemyśleniami na temat tego, kiedy i jak programiści powinni korzystać z tej metody.

Programowanie w parach jest jedną z technik określonych w metodyce programowania ekstremalnego. Ta technika jest znana od lat 80. XX wieku, ale teraz zyskuje popularność ze względu na rozwój mikrousług i związane z tym zmiany w komunikacji między programistami.

Podstawy techniki pair programming

Sama technika polega na tym, że dwóch (czasem nawet więcej) programistów jednocześnie rozwiązuje wspólne zadanie, pracując na tym samym stanowisku roboczym. Ponieważ jest tylko jedna klawiatura, jeden z programistów odgrywa wiodącą rolę i nazywa się “driverem”. Inny programista (“navigator” lub “observer”) wykonuje funkcje nawigacyjne. Obserwator określa kierunek pracy na bardziej abstrakcyjnym poziomie i stale monitoruje kod stworzony przez swojego kolegę lub koleżankę.

Widziałem sześcioosobowy zespół piszący kod przy jednym monitorze, ale z pewnością jest to wyjątkowy przypadek. Mimo to, role niewiele się zmieniają, ponieważ wciąż jest jeden driver (ten, który używa klawiatury i myszy) i ci, którzy pomagają w nawigacji. Oczywiście role nie są stałe: członkowie zespołu mogą w razie potrzeby zajmować pozycję lidera jeden po drugim, w zależności od bieżącego zadania.

Istnieje odmiana pair programming, znana jako ping-pong, która została dostosowana do test-driven development. Jeśli chodzi o mnie, jestem biegły w tradycyjnym scenariuszu, w którym jedna osoba tworzy kod, a druga prowadzi ją, i wskazuje, w którym kierunku należy podążać.

Pair programming zdalnie

Ta odmiana techniki programowania w parach wymaga pracy zdalnej za pomocą narzędzi umożliwiających wspólną edycję kodu. Kiedy nie ma możliwości nawiązywania bezpośredniego kontaktu, umiejętności komunikacyjne stają się szczególnie istotne. W takim przypadku trudniej jest zsynchronizować się i upewnić, że osoba po drugiej stronie dotrzymuje tempa bezpośredniej interakcji z kodem. Łatwiej jest, jeśli programiści pracują za pomocą udostępniania ekranu. W przeciwnym razie zaangażowane strony mogą odczuwać nieprzyjemne „opóźnienie”, kiedy zmiany są wprowadzone, ale widzisz je na monitorze kilka sekund później. Opóźnienie sieci może również powodować pewne problemy podczas tworzenia zrzutu ekranu. Można jednak uniknąć większości kłopotów, przestrzegając stosunkowo prostej etykiety komunikacji zdalnej.

Kiedy warto używać programowania w parach?

Trudno mi wskazać precyzyjnie, kiedy powinno się zastosować technikę pair programming. W każdym razie zdecydowanie polecam korzystanie z niej, gdy opanowujesz w czasie rzeczywistym nieznaną dziedzinę lub technologię wymaganą w projekcie. Programowanie w parach znacznie przyspiesza wymianę wiedzy i pozwala członkowi zespołu, który wie najwięcej na konkretny temat na przekazywanie tych informacji wszystkim jednocześnie, zamiast objaśniać pewne kwestie każdemu z osobna.

Drugi idealny przypadek użycia programowania w parach to moment, w którym tworzymy coś naprawdę kluczowego. Ta technika pozwala nie wysyłać kodu wiele razy do różnych osób w celu weryfikacji wraz z towarzyszącą mu korespondencją zawierającą złożone pytania. Tworzycie kod razem, a następnie przeglądacie go wspólnie. To szczególnie skuteczne podejście przy tworzeniu krytycznych części systemów.

Udowodniono, że programowanie równoległe znacznie podnosi jakość kodu (o około 15%), choć powodzenie projektu będzie zależeć przede wszystkim od samych programistów i ich doświadczenia w stosowaniu tej techniki. Myślę, że jakość kodu wzrasta głównie dlatego, że nie tylko otrzymujemy większą ilość danych do analizy kodu, ale także robimy to na znacznie wcześniejszym etapie rozwoju rozwiązań.

Kiedy pair programming nie działa?

Jasne, że nie da się używać pair programming przez osiem godzin ciągłej pracy. W krytycznym czasie, programowanie w parach nie sprawdzi się, ze względu na zwiększone tempo pracy. Kiedy masz do czynienia z kodem napisanym w pośpiechu, całkiem wygodnie jest go przefiltrować parami, dopracowując go do formy, która byłaby akceptowalna dla zespołu. Ale nie będzie dobrym pomysłem pisanie go poprawnie od zera z dwiema osobami jednocześnie.

Pair programming to technika kładąca nacisk na komunikację, więc nie zadziała tak dobrze w sytuacji, gdy ludzie są zbyt przyzwyczajeni do hierarchizacji. Osobliwością wypływającą z charakteru ludzkiej komunikacji jest to, że jeśli jedna z par zajmuje rolę seniora, druga, pod warunkiem braku konfliktu, automatycznie przyjmuje rolę juniora, niezależnie od umiejętności i doświadczenia. Z perspektywy projektu przynosi to efekt przeciwny do zamierzonego, więc, aby uniknąć takiej sytuacji, wszystkie pary/grupy muszą na początku być ściśle monitorowane, by zachować równość.

Efekty uboczne

Dodatkowym pozytywnym aspektem programowania w parach jest możliwość zminimalizowania liczby aktywnych zadań. Ogólnie rzecz biorąc, zespół będzie bardziej skoncentrowany na projekcie zamiast skakać z jednego zadania do drugiego i ostatecznie zaoszczędzi czas. Może będą przetwarzać mniej zadań jednocześnie, ale ogólna jakość wzrośnie i trudniej utknąć w martwym punkcie. Wszyscy znamy sytuacje, w których zadanie zajmujące rutynowo zajmuje 30 minut dziennie, gubi się w  gąszczu pilnych przypadków i z czasem staje się nieaktualne.

Budowanie komunikacji

Skoro komunikacja podczas pair programming jest złożonym zagadnieniem, właściwie zorganizowany proces pozwala lepiej ułożyć relacje w zespole niż tradycyjne code review. Z mojego doświadczenia wynika, że doświadczeni programiści, którzy niedawno dołączyli do nowego zespołu, często traktują komentarze na temat kodu, który napisali jako osobisty afront. Nadając takiej ocenie interaktywną formę, możemy uniknąć konfliktów, ponieważ ludzie są mniej skłonni do negatywnych interpretacji komentarzy innych, kiedy komunikują się osobiście.

Technika pair programming stale przypomina, że twój partner rozumie bieżące zadanie. Wszelkie wątpliwości można wyrazić natychmiast, a pojawiające się problemy można rozwiązać natychmiast. Poczucie pewności, które podczas bliskiej współpracy jest budowane szybciej, pozwala nie obawiać się, że twoje komentarze mogą wydawać się innym głupie lub że odpowiedź na jakieś pytanie jest zbyt prosta. Jednocześnie rzeczy, które wydają się oczywiste dla jednego z programistów, mogą być błędne.

Zasady komunikacji

Oczywiście nie ma tutaj żadnych ścisłych zasad, ale mam kilka rekomendacji, które bardzo pomagają w codziennej pracy:

  • nie bój się mówić na głos, co myślisz;
  • bądź uprzejmy i przyjazny;
  • nie bądź apodyktyczny/a, kiedy coś tłumaczysz.

Polecam zastosować prostą technikę. Jeśli zauważysz, że osoba siedząca obok ciebie robi coś źle, po prostu odetchnij i policz do 10. Natychmiastowa reakcja na błąd może frustrować twojego partnera lub partnerkę. Całkiem możliwe, że po osiągnięciu końca linii zauważy problem, powróci na początek i poprawi niedociągnięcia. Jeśli nie, dopiero wtedy wskaż błąd.

Jeśli sprawisz, że druga osoba straci wątek, ryzykujesz, że jakość pracy natychmiast spadnie. Jeśli tak się już stało, najważniejsze jest, aby jak najszybciej powrócić do normalnej komunikacji. Na przykład: możesz szybko omówić powstały problem, a następnie dać feedback: dowiedz się, w jakiej formie twój kolega lub koleżanka chciałby otrzymywać informacje zwrotne. Ten temat wykracza poza pair programming, ale jest bardzo istotny dla funkcjonowania zespołu. Ogólnie rzecz biorąc, najbardziej produktywnym podejściem do feedbacku jest zaakceptowanie go i traktowanie go jak prezent, chociaż trzeba się tego nauczyć. Należy pamiętać, że każdy, kto odważy się wypowiedzieć krytykę, ryzykuje z punktu widzenia współpracy powstaniem konfliktu, czyli czymś, czego nikt nie lubi i zasługuje na wdzięczność.

Odrzucenie niepotrzebnych przypuszczeń to kolejna umiejętność, którą trudno opanować. Kiedy rozmawiamy z innymi ludźmi, często popełniamy błąd komunikacyjny: myślimy, że wiemy, co zamierzają zrobić lub powiedzieć. Takie domysły często przesłaniają oczywiste fakty, które powinny służyć jako punkt wyjścia do konstruktywnej rozmowy. Na przykład, jeśli przeszkodzono ci, prawdopodobnie nie powinieneś odpowiadać „Och, myślisz, że jesteś taki/a mądry/a?!”. O wiele bardziej użyteczne jest powiedzenie: „Zamierzałem skorygować tę linię za dwie sekundy. Zauważyłeś ważny błąd, ale czy nie sądzisz, że mi przeszkodziłeś/aś? ”.

Z perspektywy rozwoju

Moim zdaniem ciągłe szkolenie się w obszarze umiejętności komunikacyjnych sprawia, że ​​programista zaangażowany w pair programming jest dobrym technicznym liderem w przyszłości. Nie wspominając o tym, że intensywna wymiana wiedzy jest doskonałą okazją do szybkiego rozwoju technicznego. Ponadto, zwykłe code review często nie ujawnia najdrobniejszych błędów. Nawiasem mówiąc, pierwsi programiści, którzy pracowali przy budowie komputera Eniac, programowali w parach. Uznali, że to jedyny sposób na szybkie opanowanie go i bez wątpienia byli inteligentni.

Z perspektywy klienta

Jeśli IT nie jest głównym obszarem działalności twojego klienta, może mu być trudno uwierzyć, że jakość kodu, która jest bardzo trudna do zmierzenia, jest warta dodatkowego wysiłku. W przypadku firm z innej branży, pojęcie jakości może być abstrakcją. Oznacza to, że oczywiste ryzyko związane z użyciem nowej metodologii ma dla nich niejasne zalety, sugerując oszustwo

.

Jeśli masz pewność, że zastosowanie pair programming jest uzasadnione, przedstaw klientowi jasną ofertę, wprowadzając wskaźniki do podjęcia decyzji. Pomóc może analiza statyczna kodu i, jeśli to możliwe, audyt zewnętrzny. Programowanie w parach może być korzystne dla klienta, jeśli produkt będzie wymagał mniej zasobów do obsługi lub dodawania nowych funkcji w przyszłości. Zamiast mówić „chcemy stworzyć elegancki kod”, powiedz „chcemy obniżyć koszty roczne, ponoszone przez was za wsparcie rozwiązania”. Z perspektywy firmy pytanie, dlaczego dwie osoby wykonują zadanie, które każda z nich wykonałaby samodzielnie ma sens.

Łatwiej jest zaoferować technikę pair programming, gdy pracujesz na systemach krytycznych, w obszarach wysokiego ryzyka lub ściśle monitorowanych przez organy regulacyjne. Jeśli klient jest zainteresowany długoterminową perspektywą projektu, przekonanie go będzie łatwiejsze. Jedną z zalet jest to, że wdrożenie programowania w parach nie polega tak naprawdę na inwestycjach, ale na zaufaniu do zespołu. pair programming zmniejsza liczbę zadań, nad którymi pracuje się w tym samym czasie, a na koniec nie kosztuje więcej i nie działa wolniej niż bardziej popularne metody programowania, czyli całkowicie się opłaca. Najtrudniejszą rzeczą jest wyjaśnienie, dlaczego dwóch programistów stojących za jednym monitorem to dobry pomysł. Ale na szczęście na ratunek przychodzą badania i mierzalne dane - na przykład liczba wad systemowych wykrytych przez klienta.