Czym jest programowanie ekstremalne?

Pamiętam swoją reakcję, gdy usłyszałem po raz pierwszy określenie extreme programming. „Serio? Jakaś banda nerdów chce pewnie od rana do nocy (a najlepiej od nocy do rana) programować i mieć resztę gdzieś? Kto w ogóle wymyślił tę nazwę?”.

Dopiero parę lat później, przeglądając książki w bibliotece, obok „TDD” Kenta Becka, trafiłem na inną książkę jego autorstwa, o tym właśnie tytule. Dodatkowo pisanym przez duże X, jak na koniec zeszłego wieku przystało (wydana w 2000 roku).

Z powodu małej objętości tej książki (niecałe 200 stron) i braku lepszej lektury, postanowiłem dać jej szansę.

XP to nie tylko Windows

No więc czym jest programowanie ekstremalne? Przede wszystkim nietrafioną nazwą. Ma ona więcej sensu, gdy zna się jej wyjaśnienie [1], niemniej wciąż budzi mieszane skojarzenia. Przechodząc nad nią do porządku dziennego, jest to jeden ze sposobów organizacji pracy, „podpadający” pod metodyki zwinne (Agile). W związku z tym ma wiele wspólnego z popularnym Scrumem, jednak wyróżnia się większym zdyscyplinowaniem, skupieniem na współpracy i wspólnym pisaniu oprogramowania.

XP wskazuje cztery główne aktywności, które powinni wykonywać developerzy. Są to: pisanie kodu, testowanie, słuchanie i projektowanie. Jedna z nich zdaje się nie pasować do innych.

Słuchanie

Co na liście robi słuchanie? W zamyśle programiści powinni słuchać tego, co mówi klient i rozumieć nie tylko techniczne aspekty projektu, ale również jego zaplecze fachowe, wiedzieć, jak ich system jest używany i dlaczego klient podjął taką, a nie inną decyzję odnośnie nowej funkcjonalności.

Uwagę przykuwa ilość i bezpośredniość komunikacji między zespołem programistycznym a klientem. Tutaj nie tylko architekt rozmawia z klientem, czy product ownerem, ale robi to regularnie cały zespół. De facto jedną z zasad XP [2] jest ciągła obecność przedstawiciela klienta przy zespole programistycznym, jego wspólne uczestniczenie we wszystkich spotkaniach i bycie gotowym do odpowiedzi na pytania, które powstaną w trakcie developmentu.

Głównym tego celem, jak i w przypadku innych zasad i aktywności, jest skrócenie przestojów wywołanych niepewnością i skrócenie pętli iteracji, co pozwala na przyspieszenie tempa pisania i wydawania kodu.

Testowanie

Mając z głowy naszą „kaczkę dziwaczkę”, jaką jest słuchanie na tej liście zadań, każdy programista chciałby przystąpić do kodowania. Jednak pierwsza zasada kodowania w XP nakazuje zacząć od testu, więc podążając za jej duchem i my tak zrobimy.

Testowanie jest nieodłączną częścią programowania ekstremalnego. Jak wspomniałem powyżej, każda implementacja zaczyna się od testu. W ten sposób budujemy odwagę w zespole oraz sprawdzamy, czy dobrze rozumiemy wymagania. Gdy mamy jasno sprecyzowane docelowe zachowanie naszego systemu w formie testu, łatwo jest pisać i poprawiać kod. Programiści nie muszą się bać, iż przez przypadek wprowadzą niechciane zachowanie, albo zmienią inną funkcjonalność, bo mają swoją siatkę bezpieczeństwa w postaci testów.

Dodatkowo programowanie z nastawieniem „test first” pomaga dzielić system na mniejsze komponenty i dodatkowo go refaktorować. Ciężko napisać test dla naszej funkcjonalności? Może należy więc wyodrębnić tę zmianę do nowego komponentu, zamiast rozszerzać stary?

W tym miejscu czas na małą autoreklamę i wzmiankę o Cucumberze, czyli narzędziu, które umożliwia pisanie testów behawioralnych w bardzo prosty i przyjazny sposób. BDD (ang. behaviour driven development) stanowi bardzo dobre uzupełnienie TDD (ang. test driven development), które z kolei jest podstawą testowania w XP. Wzorzec „red-green-refactor” jest czymś, co po pewnym czasie wręcz staje się nawykiem. Uzupełnienie tej pętli o testy behawioralne pozwala łatwiej definiować ogólne zachowanie systemu (testy jednostkowe są… no cóż, jednostkowe), ale również zaangażować klienta i/lub product ownera.

Warstwa opisowa Cucumbera jest pisana po angielsku i nie wymaga umiejętności programowania. Pomaga jednak opisać system w pewien usystematyzowany sposób, co z kolei ułatwia jego zrozumienie i poznanie. Nowi w projekcie, gdy zaczną od takiego opisu, będą wam dziękować.

Kodowanie

Koniec autoreklamy. Czas na kodowanie. Zacznijcie od znalezienia swojego dzisiejszego „współkodera”. W XP bowiem każdy fragment kodu jest pisany przez (co najmniej) dwie osoby.

Pair programming jest kolejnym ważnym elementem tej układanki. Pisanie kodu we dwójkę pozwala na ciągłe „odbijanie piłeczki” od partnera w celu dojścia do najlepszego rozwiązania. W swojej książce Beck maluje obraz dwóch programistów siedzących przy jednym komputerze i wymieniających się klawiaturą. Może i budzi to dzisiaj uśmiech na twarzy, ale z pomocą przychodzi nam technologia. Zoom, MS Teams i inne narzędzia do wideorozmów, które mają funkcję udostępniania ekranu, bardzo dobrze nadają się do tego typu programowania, a na dodatek każdy może mieć swoją klawiaturę.

Ważne jest też, aby w trakcie programowania regularnie się zmieniać (jednym ze sposobów może być pisanie testu przez jedną osobę, a implementacji przez drugą) oraz aktywny udział obu osób w pisaniu kodu. Osoba, która akurat nie pisze kodu na klawiaturze, również nad nim pracuje. Może sugerować lepsze rozwiązania, usprawnienia, sprawdzać, czy podążamy zgodnie z obranym kierunkiem projektu, czy wreszcie robić „live code review”. Ułatwia to również transfer wiedzy pomiędzy członkami zespołu. Zarówno tej odnośnie codziennych zadań, które akurat robiła inna para, jak i wprowadzania nowych ludzi do zespołu.

Tutaj możemy nawiązać z powrotem do testowania. Dlaczego robimy te wszystkie rzeczy? Zaczynanie od testów, dwóch ludzi programujących to samo, klient dostępny na wyciągnięcie ręki. Po co to wszystko? Celem XP jest jak największe skrócenie czasu od sprecyzowania wymagania do jego wdrożenia. Dlatego też XP bardzo często łączy się z CI/CD oraz tzw. trunk based development. Commitowanie kodu bezpośrednio do maina może być na początku straszne, ale właśnie dlatego zaczynamy od testu, a nie implementacji. Z drugiej strony — jeżeli coś zepsujecie, gwałtownie można zcommitować hotfixa.

Projektowanie

Na koniec wspomnijmy jeszcze o projektowaniu. W teorii nie powinno być ono potrzebne. Skoro na bieżąco konsultujemy wszystkie sprawy z klientem, mamy testy i ciągle ktoś ocenia jakość kodu, to dlaczego potrzebowalibyśmy osobno skupiać się na projektowaniu?

Niestety nie działa to w ten sposób. Każdy system będzie powoli rozjeżdżał się ze swoim projektem, jeżeli zarówno system, jak i projekt nie będą regularnie rewidowane. jeżeli ten punkt zostanie zaniedbany, mogą np. powstać zależności pomiędzy różnymi modułami, które w znacznym stopniu utrudnią i spowolnią pracę nad systemem. Dobry projekt systemu, jego logiczny podział i regularne „sprzątanie” pozwoli zachować tempo pracy i przy okazji zadowolenie developerów.

Podsumowanie

Programowanie ekstremalne jest dla programistów czymś nietypowym, czymś, do czego nie są przyzwyczajeni. Jest to poniekąd inny sposób myślenia o naszej pracy. Na początku zmiana może się wydawać trudna, a z perspektywy product ownera wręcz nieakceptowalna („Dwa razy mniej osób piszących kod!? To do sprintu weźmiecie dwa razy mniej story pointów!”).

Nie jest to rozwiązanie dla wszystkich i nie oszukujmy się, iż sprawdzi się w każdej sytuacji. Jednak moim zdaniem jest warte wypróbowania jeżeli macie taką możliwość. A i przekonanie PO nie jest takie trudne jeżeli macie dobre argumenty i słyszycie, czego tak naprawdę się boi (patrz punkt pierwszy — słuchanie).

1. Nazwa pochodzi od tego, iż Kent Beck próbował zsyntezować te praktyki programowania, które wg niego działały (prowadziły do udanych projektów) i wyciągnąć je „do ekstremum”. Przykładowo, jeżeli testy zapewniają jakość kodu, to miejmy testy na wszystko. Skoro takie programowanie składa się z ekstremalnych praktyk, to samo zostało ochrzczone mianem programowania ekstremalnego.
2. Kent Beck wyróżnia i precyzuje aktywności, wartości, zasady i praktyki (ang. Activities, Values, Rules & Principles, Practices). Stała obecność przedstawiciela klienta przy zespole jest jedną z zasad XP. W tym tekście nie będę jednak wypisywał ich wszystkich, skupiając się na aktywnościach i ewentualnie zahaczając o pozostałe.

Zdjęcie główne pochodzi z Unsplash.com.