Programowanie
ekstremalne
Extreme Programming
(XP)

Wstęp

Czym jest lekka metodologia



Metodologia programowania to zbiór
reguł i praktyk tworzenia programów



Ciężka metodologia (heavyweight) -
wiele skomplikowanych reguł



Lekka metodologia – zbiór kilku prostch
reguł

Historia



Lata 60-te i wczesne 70-te: cowboy coding,
„real” programmers



1968 Edsger Dijkstra: „GOTO Statement
Considered Harmful”



Lata 80-te: proste reguły i praktyki umożliwiły
znaczny postęp w rozwoju oprogramowania



Lata 90-te: coraz wiecej reguł, narzędzia
CASE, powrót kowbojów



Lekkie metodologie: mało reguł, ale dobrze
dobranych

Dlaczego „ekstremalne”?



Jeżeli recenzje kodu są ważne, to będziemy je robić przez

cały czas (programowanie w parach)



Jeżeli testowanie jest ważne, to będziemy testowali cały

czas (testy jednostkowe)



Jeżeli projektowanie jest ważne, to będziemy je robić na co

dzień (refaktoryzacja)



Jeżeli prostota jest ważna, to będziemy zawsze

pozostawiać system w najprostszej wersji, która zapewnie

funkcjonalność (cos najprostszego, co działa)



Jeżeli architektura jest ważna, to każdy będzie ją

definiował i ulepszał cały czas (metafora systemu)



Jeżeli testy integracyjne są ważne, będziemy integrować i

testować kilkanaście razy dziennie (ciągła integracja)



Jeżeli iteracje powinny być krótkie, to będziemy je skracać

ile się da, do minut lub godzin, a nie miesięcy czy lat

(planning game)

Kiedy używać XP



Kiedy wymagania często się zmieniają



Klient nie jest pewny, czego potrzebuje



Wiadomo, że funkcjonalność będzie sie zmieniać co

parę miesięcy



Projekty o dużym ryzyku



Krótki termin realizacji



Nowe wyzwanie dla zespołu



Nowe technologie



Małe zespoły: 2-12 osób



Zaangażowanie klienta i kierowników w zespole



Wszyscy muszą pracować razem



Możliwość testowania na każdym etapie

Filozofia

Filozofia XP



Kent Beck, Ward Cinninghan



1996 projekt dla Chryslera (Chrysler

Comprehensive Compensation – C3)



Nowa metodologia na podstawie analizy

problemów z tworzeniem oprogramowania

stanardowymi metodami



Zasady



Komunikacja



Prostota



Sprzężenie zwrotne



Odwaga

Komunikacja



Problemy z oprogramowaniem
spwodowane komunikacją



Projektant – programista



Klient – analityk



Kierownik – programista



Rozwiązanie – narzucenie praktyk
wymagających komunikacji



Testy, praca parami, planowanie

Prostota



Co jest najprostszą rzeczą, która będzie
działac?



Zakładamy, że lepiej zrobić cos
najprostszego, co zadziała dziś, i co
najwyżej zapłacić więcej jutro, gdy
będziemy potrzebowali czegoś więcej,
niż dziś zrobić coś skomplikowanego,
czego możemy nigdy w pełni nie użyć

Sprzężenie zwrotne



Testy jednostkowe dają szybką
informację zwrotną o stanie systemu



Testy funkcjonalne dają informację
zwrotną od klienta



Wczesne wejście do fazy produkcyjnej –
żeby zdobyć jak najwięcej informacji
zwrotnej

Odwaga



Konieczne zmiany w architekturze

powodują, że testy przestają działać



Odrzucanie rozwiązań i napisanego kodu,

ktory nie działa dobrze – przepisanie od

nowa



Eksperymentowanie z kodem:

implementacja kilku rozwiązań w celu

sprawdzenia, które będzie najlepsze



To wymaga odwagi, ale ona sama nie

wystarczy (może prowadzić do hackowania)

Reguły



Planowanie



Historie użytkownika, planowanie release’u, planowanie

iteracji, naprawianie XP



Projektowanie



Prostota, metafora systemu, karty CRC, rozwiązania

impulsowe, brak zbędnej funkcjonalności, refaktoryzacja



Implementacja



Obecność klienta, standardy kodowania, najpier testy,

programowanie parami, jedna para integruje, częste

integracje, współdzielenie kodu, pozostawienie

optymalizacji na koniec, żadnych nadgodzin



Testowanie



Testy jednostkowe do całości kodu, testy po znalezieniu

bugów, , częste testy akceptacyjne

Planowanie

Opowiadania użytkowników
(User stories)



Podobne zastosowanie co przypadki użycia (use
case)



Spis rzeczy, które system ma robić, mniej dokładne
niż specyikacje wymagań



Trzyzdaniowe akapity, bez technicznej terminologii



Używane do oszacowania czasu trwania iteracji i do
tworzenia testów akceptacji



Szacowanie czasu potrzebnego na implementację
opowiadania – 1, 2 lub 3 tygodnie „idealnego
czasu”



80 ± 20 opowiadań to właściwa liczba dla release’u

Planowanie wydania
(release)



Planning game – gra z użyciem kart z

opowiadaniami



Uczestnicy: developerzy, klient, kierownictwo



Wynik: wybór opowiadań do

zaimplementowania w następnym wydaniu



Wyznaczenie „szybkości projektu” pozwala

oszacować, ile kart można zaimplementować



Zmienne: zakres, zasoby, czas, jakość

(powina być doskonała)

Szybkość projektu



Suma oszacowań czasu opowiadań /
iterację



Jest wyznaczana po każdej iteracji i określa
ile będzie można zrobić w następnej



Autoregulacja



Jak oszacować prędkość na początku?



Lepiej zrobić kilka iteracji implementacyjnych na
początku niż tracić czas na dokładną
specyfikację



Częste małe wydania
(release)



Jak najczęściej dostarczane dla klienta



Ważne jednostki funkcjonalności jak
najwcześniej



Cel – informacja zwrotna od klienta



Im później dostarczone – tym mniej
czasu na poprawę

Iteracje



Plan implementacji dzielimy na ok.
tuzina iteracji, każda 1 do 3 tygodni



Planujemy zadania tylko na najbliższą
iterację



Nie wolno implementować „za zapas”
nic, co nie jest zaplanowane w iteracji



Ważne jest dotrzymywanie terminów,
lepiej zmienić plan niż przekroczyć
termin

Planowanie iteracji



Spotkanie planowania iteracji – wybór najważniejszych

opowiadań z planu release’u



Ilość opowiadań na podstawie szybkości realizacji

poprzedniej iteracji



Zadania programistyczne tworzone na podstawie

opowiadań oraz nieudanych testów



Karty z zadaniami (taskami) dla programistów



Czas zadania: 1 – 3 dni czasu programisty



Jeżeli zadań jest za dużo, to odrzucamy jedno

opowiadanie, jeżeli za mało, to dodajemy



Co parę iteracji może zajść potrzeba przeszacowania

planu release’u – najważniejsze, aby istotne opowiadania

były realizowane najwcześniej

Przenoszenie ludzi między
zadaniami



Cel: uniknięcie utraty wiedzy lub
wąskiego gardła w programowaniu



Gdy jedna osoba odejdzie, inne mogą
łatwo przejąć jej zadania



Płynne równoważenie obciążenia w
pracy nad różnymi zadaniami



Ułatwione przez programowanie w
parach



Odpowiednik „szkoleń poprzecznych”

Spotkania na stojąco



Na typowym spotkaniu większość tylko
słucha i traci cenny czas 



Poranne spotkanie na stojąco służy
szybkiej wymianie problemów,
rozwiązań i ukierunkowaniu prac
zespołu.



Pozostałe spotkania na bieżąco przy
komputerze

Naprawianie XP gdy sie
psuje



Reguły trzeba będzie dostosować do
konkretnego projektu



Można zmienić reguły, ale wtedy trzeba
przestrzegać tych nowych



Zawsze powinno być wiadomo, jakie
reguły obowiązują i należy ich
przetrzegać, żeby unikać
nieporozumień

Projektowanie (design)

Prostota



Prosty projekt (design) zawsze można
szybciej zrealizować niż skomplikowany



Skomplikowane należy zastąpić prostym



Im wcześniej tym lepiej (zanim straci
się dużo czasu z powodu koplikacji)



Nie dodawać funkcjonalności zanim nie
jest zaplanowana



To nie jest proste!

Metafora systemu



Umożliwia uzgodnienie wspólnego

schematu nazewnictwa obiektów



Ułatwia rozmawianie o projekcie na

zasadzie skojarzeń



Metoafora „naiwna” - wzięta z dziedziny

projektu



Przykład nazw z metafory: „menadżer

okien”, „koszyk”, „linia produkcyjna”



Metafora zastępuj częściowo

architekturę

Karty CRC (Class,
Responsibilities, and
Collaboration)



Narzucają podejście
obiektowe



Ułatwiają
projektowanie
zespołowe



Lepsze niż tablica –
umożliwiają łatwe
przesuwanie i
reorganizację oraz
symulacje zachowań
systemu

http://www.agilemodeling.com

Rozwiązania impulsowe (spike
solutions)



Pomocne w rozwiązaniu trudnych
problemów technicznych lub
projektowych



Prosty program do sprawdzenia
potencjalnego rozwiązania, pomijając inne
aspekty



Zwykle do wyrzucenia po sprawdzeniu



Redukują ryzyko problemów technicznych
i pomagają oszacować czas opowiadania

Nie dodawać funkcjonalności za
wcześnie



Nie dodawać rzeczy, które spodziewamy
się, ze przydadzą się później



10% dodatkowych elementów przyda się
naprawdę → 90% strata czasu



Pomimo że system mógłby być dzięki
temu lepszy, należy czynić go
najprostszym.



Należy implementować tylko to, co jest
zaplanowane i nic więcej

Bezlitośnie refaktoryzować



Nie należy „przywiązywać się” do
starego kodu



Unikać niejasnego kodu i zastępować go
prostszym – łatwym do zrozumienia,
modyfikowania i rozszerzenia



Unikać duplikowania fragmentów kodu



Umożliwia reakcję na zmiany wymagań

Implementacja

Klient na miejscu



Klient jest częścią zespołu



Dostępny cały czas do bezpośredniej

rozmowy i podejmowania decyzji



Klient pisze opowiadania użytokwnika z

pomocą programistów



Podczas planowania release’u negocjuje

wybór opowiadań do

zaimplementowania



Dzięki częstym wersjom klient może

szybko ocenić rozwiązania

Standardy kodowania



Ustalony jeden wspólny standard



Dzięki temu kod jest elegancki, łatwy do
czytania i modyfikacji przez cały zespół



Konwencje formatowania, wcięć,
nazewnictwa, komentarzy, etc.



Narzędzia (edytory) wymuszające
standard

Najpierw test, później
program



Ułatwia pisanie kodu – jest cel



Daje od razu informację, czy kod jest
gotowy



Motywacja – przejście testu



Wpływa korzystnie na design



Ułatwia innym korzystanie z kodu (testy
są przykładami!)

Programowanie w parach



Cały kod produkcyjny musi być pisany
w parach



Większa jakość kodu



Wbrew pozorom – większa efektywność
(badania)



Myślenie taktyczne i strategiczne

Integracja



Tylko jedna para integuje kod



Eliminuje błędy równoległej integracji,
gdy nie da się wszystkiego
przetestować



Jasno definiue najnowszą wersję kodu (i
testów!)



Unika się problemów z zespołami
integracyjnymi i równoległym
rozwijaniem kilku wersji

Częsta integracja



Co kilka godzin, albo częściej



Nie dłużej niż jeden dzień



Eliminacja rozbieżności pracochłonnych
do połączenia



Uniknięcie trudnego etapu końcowej
integracji

Współdzielenie kodu



Każdy może zmienić dowolny fragment



Unikanie wąskich gardeł



Każdy ma wpływ na architekturę



„Zbiorowa odpowiedzialność”



Testy zapewniają, że zmiany w
„cudzym” kodzie nie spowodują błędów



Nie ma problemu, gdy ktoś odejdzie z
zespołu

Optymalizacja na koniec



I zasada optymalizacji: „Nie
optymalizuj!”



Nie wolno optymalizować na podstawie
domysłów



Należy zmierzyć wydajność



Zrób, żeby działało, żeby działało
dobrze, i dopiero wtedy, żeby działało
szybko

Brak nadgodzin



Nigdy nie dopuszczać do nadgodzin w
kolejnych tygodniach



Projekty wymagające nadgodzin i tak
się spóźnią



Ważniejsza jest jakość



Można zmieniać zakres projektu lub
czas

Testowanie

Testy jednostkowe



Użycie narzędzi do testowania



Najpierw test, później kod!



Testy znajdują się w repozytorium

razem z kodem



Inwestycja w przyszłość – zysk przyjdzie

później



Ułatwiają refaktoryzację i integrację



Kod musi przejść 100% testów zanim

będzie wydany

Reakcja na bug



Gdy pojawi się bug, należy stworzyć
testy



Nowe testy akceptacyjne dla kodu
podukcyjnego



Testy jednostkowe



Później naprawiamy błąd



Kod przechodzi testy

Testy akceptacyjne



Tworzone na podstawie opowiadań
użytkowników wybranych do iteracji



Może być kilka testów na jedno
opowiadanie



Testy „czarnej skrzynki” (black-box) –
weryfikowane przez klienta