Programowanie ekstremalne ( eXtreme Programming, XP ) Piotr

Programowanie ekstremalne ( eXtreme Programming, XP )
Piotr Rdzanek
30-03-2008
XP jest metodologią programowania. Główne założenia sformułował Beck Kent. Swoje założenia Beck
Kent opisał w wydanej w 1999 roku książce "Extreme Programming Explained". Jego zdaniem na
definicję programowania ekstremalnego składa się 12 praktyk: gra planistyczna, krótkie okresy
wydania kolejnych wersji, metafora, prosty projekt systemu, testowanie przed kodowaniem,
refaktoryzacja, programowanie w parach, współwłasność kodu, ciągła integracja, brak nadgodzin, udział
klienta w zespole i standard kodowania. Praktyki te przydzielone są do 4 grup: planowanie i definicję
wymagań, projektowanie, programowanie i testowanie. Do dnia dzisiejszego powstało wiele publikacji
dotyczących programowania ekstremalnego, w których wydzielona jest inna liczba zasad. Zmienna
liczba tych zasad wynika z uszczegóławiania lub uogólniania zasad sformułowanych oryginalnie przez
Becka Kenta.
Ponieważ Programowanie Ekstremalne jest rozległą dziedziną inżynierii oprogramowania, poniższa
publikacja zawiera krótki opis założeń Becka Kenta. Zainteresowanych pogłębieniem wiedzy na temat
XP odsyłam do książki napisanej przez twórcę metodologii1.
Planowanie i definicja wymagań.
Planowanie ma inny zakres niż w standardowych metodykach. W 'XP' planuje się tylko najbliższą
przyszłość - jeden przyrost, lub wydanie oprogramowania.
Gra Planistyczna. Praktyka ta zastępuje, występującą klasycznie, fazę planowania. Celem gry
planistycznej jest zebranie funkcjonalności koniecznej do zaimplementowania w najbliższym wydaniu
oprogramowania. Główne znaczenie ma tu klient. To na podstawie jego "opowieści", tworzona jest lista
funkcji jakie zostaną stworzone. Raz narzucona funkcjonalność nie jest stała, a klient może ją zmieniać,
w trakcie trwania projektu, na miarę swoich potrzeb.
Metafora. Wykorzystanie diagramów przy planowaniu oprogramowania jest zbędne, a jeżeli
występuje, ma charakter wyłącznie poboczny. Ponieważ odbiorcą oprogramowania jest klient, który nie
musi rozumieć języka dziedzinowego, ważne jest wypracowanie komunikacji, która w nieformalny
sposób opisze zachowania systemu.
Udział klienta w zespole. W modelu kaskadowym klient brał udział wyłącznie w początkowym
etapie tworzenia systemu. W 'XP' klient jest włączany do grupy deweloperów. Dzięki temu programiści
w każdym momencie mają dostęp do szczegółowej dokumentacji, jaką niewątpliwie jest odbiorca
oprogramowania. Z drugiej strony obecny klient może szybko reagować na odejście deweloperów od
wymaganej funkcjonalności i powrót na prawidłową drogę działania. Kolejną zaletą jaką otrzymuje
klient po zakończeniu projektu jest doskonała znajomość systemu, co znacznie upraszcza jego
wdrożenie.
Projektowanie.
Projekt powstaje tuż przed rozpoczęciem programowania. Kod programu jest jednocześnie jego
dokumentacją dlatego ważnym jest zachowanie pewnych praktyk. Ne oznacza to, że rozwiązania mają
być banalne, tylko przejrzyste. Bardzo ważne jest aby nie zajmować się programowaniem elementów,
które mogą zostać dodane w przyszłości. implementuje się wyłącznie funkcjonalność wymaganą w
danym momencie.
Prostota projektu. Ważne jest aby projekt przechodził wszystkie testy jednostkowe i
funkcjonalności, kod powinien w czytelny sposób pokazywać zmysł projektu.
Programowanie.
W miarę rozwoju inżynierii oprogramowania, samo programowanie było coraz bardziej zaniedbywane.
Coraz większy nacisk kładziono na modelowanie przyszłego systemu niż na jego implementację. 'XP'
1 Beck Kent “Extreme Programming Explained”, wydawnictwo: Addison-Wesley Professional; 2 edition
(November 26, 2004)
1/3
wraca do korzeni i programowanie staje się najważniejszym etapem.
Częste wydania. Ważne jest aby klient otrzymywał wersje próbne programu w częstych odstępach
czasowych (co 1-3 tygodnie). Po przejściu testów funkcjonalnych klient ocenia, czy oprogramowanie
spełnia jego wymagania. Dzięki temu deweloperzy redukują ryzyko wystąpienia błędnej implementacji
założeń.
Refaktoryzacja. W miarę dodawania kolejnych funkcjonalności, kod staje się coraz mniej
zrozumiały. Dlatego ważne jest częste jego czyszczenie i upraszczanie. Ponieważ w czasie refaktoryzacji
w znaczny sposób zmienia się struktura programu, ważne jest ciągłe przeprowadzanie testów oraz
sprawdzanie czy funkcjonalność nie została zagubiona.
Współwłasność kodu. Bardzo upraszcza to procedurę wprowadzania zmian. Dodatkowo
programista nie musi czekać aż ktoś poprawi swoją część, może zrobić to sam. Dodatkowo ma to zalety
psychologiczne: daje to poczucie wspólnego działania, dzięki czemu nie ma problemów z integracją
zespołu. Ponieważ kod może często przechodzić "z rąk do rąk" ważne jest aby programiści tworzyli kod
w sposób standaryzowany, pomijając swoje nawyki programistyczne. Dodatkowo bardzo ważnym jest
stosowanie systemów zarządzanie wersjami kodu (CVS/SVN), dzięki czemu nie będzie kłopotów z
ewentualnym cofnięciem wprowadzonych zmian.
Ciągła integracja. Kolejne części systemu powinny być w sposób ciągły spajany z całością systemu.
Integracje powinno się wykonywać przynajmniej raz dziennie. Dzięki temu unikamy przypadłości
integracji okazjonalnej, jaką jest potrzeba dopasowywania interfejsów oddzielnych komponentów.
Brak nadgodzin. Ma to znaczenie raczej psychologiczne, ale d doświadczeń wynika, że programiści
mogą pracować wydajnie do 40 godzin w tygodniu. Częste nadgodziny powodują znaczny spadek
morale i efektywności, co z kolei prowadzi do powstawania mało zrozumiałego kodu.
Standard kodowania. Programiści powinni stosować się do narzuconego stylu programowania.
Standard kodowania nie powinien być dokumentem, ale normą, wzorcem według którego powstaje
źródło.
Programowanie w parach. Programiści piszą oprogramowanie w parach. Podczas gdy jeden z nich
programuje, drugi obserwuje powstający kod, zgłasza poprawki, zadaje pytania. Dzięki temu możliwej
jest tworzenie zrozumiałego dla wszystkich kodu (co jest niezwykle ważne przy wspólnej pracy
zespołu). Poprawia to również wiedzę pracowników, ponieważ oni sami się nią wymieniają w czasie
pracy.
Testowanie.
Testowanie podzielone jest na 2 części. Jedną z nich jest testowanie jednostkowe, które ma na celu
sprawdzenie poprawności działanie danego fragmentu kodu. Drugim rodzajem jest testowanie
funkcjonalne, które ma na celu zbadanie funkcjonalności.
Testowanie przed programowaniem. Ponieważ testowanie jest czasochłonnym zajęciem,
wykonuje się je na samym końcu projektu (ew. etapu), a ponieważ zawsze wtedy brakuje czasy, więc
testy są niedokładne. Dlatego w 'XP' programista ma obowiązek napisanie testu jeszcze przed
napisaniem funkcji. Wraz z rozwojem oprogramowania powstaje siatka testów, przez którą
oprogramowanie zawsze musi przejść (dzięki temu unikamy błędów powstających w czasie
refaktoryzacji czy wprowadzania zmian). Ważne jest aby testy nie były zależne od siebie i żeby były
wykonywane w sposób automatyczny.
Zastosowanie.
Ponieważ zasady programowania ekstremalnego są modyfikowalne, metodologię ta można
zastosować w każdym projekcie. Jednak głównie tą metodologię stosuje się przy:
-tworzeniu prototypowych systemów/technologi (nawet tych dużych), gdzie wymagania dotyczące
systemy szybko się zmieniają, a dodatkowo istnieje wysokie ryzyko pojawienia się nieprzewidywalnych
błędów;
- projekty badawcze, celem których nie jest powstanie samego oprogramowania, lecz zdobycia
wiedzy,doświadczeń na jego temat;
- małe i średnie projekty, które można w łatwy sposób zarządzać nieformalnymi metodami.
Kiedy nie stosować XP?
Z powody dużej ilości nieformalnego przekazywania informacji, metodologie ta nie może być
stosowana t projektach nad którymi pracuje więcej niż 20 programistów (oczywiście liczba ta nie jest
2/3
wartością graniczną, jednak doświadczenia wskazują, iż około tej liczby pojawiać się zaczynają
problemy z niezakłóconą komunikacją).
Nie jest zalecanym używania tej metodologii w przypadku projektów, w których technologia i model
pracy jest dobrze znany i nie trzeba opracowywać projektu od zera.
Również wiele zależy od środowiska pracy. Jeśli integracja i kompilacja projekty zajmuje kilka godzin
niemożliwe jest częste wykonywanie testów.
Programowania ekstremalnego nie zaleca się również do tworzenia projektów “krytycznych”, czyli takich
od których wymaga się idealnej stabilności, i które muszą wykonać swoje zadanie za wszelką cenę (np.
systemy ochrony zdrowia).
Źródło: Beck Kent - “ Extreme Programming Explained”.
3/3