Wydajne Programowane (extreme programming) to nowe podejście do tworzenia oprogramowania oparte o najlepsze z technik ze szczególnym uwzględnieniem prostoty i pracy zespołowej.
XP to ciągłe testowanie i przeglądanie kodu oraz zaangażowanie klienta w proces tworzenia aplikacji. Metody XP zostały dobrze przyjęte przez programistów, jednak ich praktykowanie wymaga cierpliwości i jest nie lada wyzwaniem. 1 Krótko o Extreme Programming
Gdy programowanie komputerów było nową dziedziną, czas procesora był bardzo cenny.
Było niewiele komputerów i konkurencja w zyskaniu dostępu do sprzętu była bardzo duża.
Jeśli istniał błąd uniemożliwiający poprawne działanie programu, trzeba było czekać dni albo tygodnie, by móc sprawdzić go ponownie.
Dowolna zmiana programu miała wpływ na cały program.
Aby zaoszczędzić czas i pieniądze należało się upewnić, iż program jest w pełni sprawny przed umieszczeniem go w komputerze (sprawdzanie na sucho ). Sprawdzanie kodu zajmowało wiele godzin.
A więc wynikała z tego lekcja: ZMIANA JEST TRUDNA I KOSZTOWNA! 2
Kilka dekad pózniej, Extreme Programming, nazywane w skrócie XP (wydajne programowanie), stawia wszystko na głowie, gdyż sugeruje operację całkowicie odwrotną: Wykonanie wysokiej jakości oprogramowania odbywa się pomimo, a nawet dzięki ciągłym zmianom.
XP to sposób tworzenia oprogramowania, który kładzie nacisk na prostotę, reakcję zwrotną, odwagę i komunikację. Stanowi w zasadzie reakcję na przekonanie, iż zmiana jest zła i można jej uniknąć.
W kilku ostatnich latach tysiące programistów i firm przekonało się, że XP pomaga im tworzyć lepsze, bardziej niezawodne oprogramowanie przy mniejszym stresie. Koncepcje XP wpłynęły nawet na słownictwo i narzędzia wykorzystywane poza zespołami używającymi XP.
Zauważyć można wzmożone zainteresowanie inżynierów oprogramowania testowaniem i odpowiednimi do tego narzędziami. 3
XP jest doskonałym rozwiązaniem, ponieważ 12 jego głównych technik polega na sobie i jest ściśle związanych. Siła jednej z technik neutralizuje słabość innej.
Zrozumienie wartości wydajnego programowania i związków między technikami umożliwia odniesienie sukcesu.
XP nadaje się idealnie dla niewielkiej grupy twórców w firmie piszącej oprogramowanie dla innej firmy oprogramowanie dostarcza się często, wynik prac nie jest znany od samego początku modyfikacje są nieuniknione.
XP nadaje się także w projektach, w których wiadomo, co dokładnie należy wykonać.
Oczywiście kilka technik XP przydaje się w każdym projekcie programistycznym. 4 Dlaczego Extreme Programming?
Wiele metod tworzenia oprogramowania zakłada, że zmiana jest kosztowna. Błąd znaleziony w fazie konserwacji kosztuje więcej, niż ten sam błąd znaleziony w fazie planowania.
Techniki Extreme Programming (wydajne programowanie) postulują inne stwierdzenie: Możliwa jest minimalizacja wzrostu kosztu zmian w czasie. 5
XP stara się odpowiedzieć na następujące pytania:
Jakiego rodzaju oprogramowanie można wykonać, gdy ma się pełną swobodę w zmianie wymagań i środowiska?
Mając wystarczającą ilość czasu i zasobów, co można w ten sposób uzyskać?
Czy taki cel jest w ogóle realistyczny?
Jeśli tak, w jaki sposób można go uzyskać? 6 Równanie XP
Projektami programistycznymi można zarządzać w kategoriach 4 zmiennych: czasu, możliwości, zasobów i jakości.
Wiele projektów koncentruje się na czasie i zasobach, zakładając, że jakość pozostanie stała. Jeżeli możliwości kiedykolwiek się zmieniają, są typowo zwiększane (np. klient prosi o nowe funkcje).
Co gorsza, czas i zasoby są często zmniejszane lub pozostają stałe. Gdy zbliża się data wydania, często przy projekcie pracuje mniej osób niż na początku.
Ostatni z parametrów, czyli jakość musi spadać! 7
XP sugeruje inną strategię:
Zespół wraz z klientem godzi się na pewien poziom jakości.
Czas i zasoby ustala się jako wartości stałe.
Pozostaje tylko określenie możliwości:
Co zostanie dostarczone?
Kiedy zostanie dostarczone?
Klient ustala priorytety dla poszczególnych funkcji systemu.
Praca odbywa się etapami a oprogramowanie prawie zawsze będzie gotowe do wydania, choć nie zawsze z pełnym zestawem funkcji. 8
XP zaleca regularne dostrajanie możliwości, nawet codziennie. Każda decyzja biznesowa może wpłynąć na projekt.
XP to wykorzystuje, czyniąc zmiany i ich efekty widocznymi dla osób podejmujących decyzje biznesowe.
Zakładając odpowiednią komunikację w zespole, szybkie odpowiedzi w kwestii stanu projektu i zdolność do dostosowania możliwości, praktycy XP mogą swobodnie zakładać dostateczną ilość zasobów. Jest to jedno z głównych założeń XP: Uwidocznienie zależności dotyczących zmian prowadzi do mniejszej liczby niespodzianek i bardziej płynnego tworzenia oprogramowania. 9 Wartości XP
XP składa się z czterech podstawowych wartości: komunikacji, odpowiedzi na pytania (pętla zwrotna), prostoty, odwagi.
Wszystkie techniki XP wykorzystują te podstawowe wartości. 10 Wartości XP: Komunikacja
Dobra komunikacja leży u podstaw każdego projektu i umożliwia łatwe dostosowywanie się do zmian.
Dzięki temu klient wie, kiedy poszczególne funkcje systemu będą dostarczone a programiści i analitycy wiedzą co robić.
Ukrywanie lub ignorowanie informacji i nieszczerość jest często przyczyną fiaska projektów.
Metodyka XP dokonuje podziału: osoby podejmujące decyzje biznesowe zajmują się nimi a osoby zajmujące się szczegółami technicznymi podejmują wyłącznie decyzje techniczne. 11
Klient zajmuje się wyłącznie priorytetami i dyktuje co i kiedy powinno być zrobione.
Wzajemne zaufanie: Analitycy ufają osobom biznesowym w kwestiach identyfikacji funkcji i ich priorytetów to właśnie zarządzający znają się na dziedzinie problemu.
Klient ufa twórcom oprogramowania w dziedzinie oszacowania czasu trwania poszczególnych faz zadań ponieważ to właśnie twórcy znają się na technologii.
Każda z grup (osoby biznesowe i analitycy- programiści) są częścią tego samego zespołu i podejmują odpowiedzialność za swoje decyzje. Celem zespołu jest zaspokojenie wymagań rzeczywistego klienta. 12
XP, a jak to niekoniecznie bywa w przypadku tradycyjnego procesu tworzenia oprogramowania, wymaga ciągłej komunikacji twórców systemów z klientem.
Klient musi przeanalizować dostarczony przez twórców projekt z punktu widzenia użytkownika i działalności biznesowej.
Tak więc klient współdziała przy opracowaniu priorytetów i odpowiada na pytania twórców.
Klient powinien codziennie widzieć postępy prac i do nich dostosować harmonogram.
Klient uczestniczy w testowaniu oprogramowania już na wczesnych etapach wytwarzania oprogramowania.
Usunięcie bariery komunikacyjnej prowadzi do elastyczności.
Rozróżnienie decyzji biznesowych od technicznych pomaga podejmować dobre decyzje.
Komunikacja jest niezbędna dla osiągnięcia celów. 13 Wartości XP: Odpowiedzi na pytania
Ten element XP podkreśla umiejętność zadawania pytań i uczenie się z uzyskiwanych odpowiedzi.
Jedynym sposobem poznania zdania klienta jest zapytanie go.
Jedynym sposobem sprawdzenia poprawności kodu jest przetestowanie go.
XP kładzie nacisk na wczesne zadawanie pytań i wczesne testowanie. XP umożliwia częste i szybkie odpowiedzi.
Każda z technik XP zawiera wbudowaną pętlę pytanie- odpowiedz.
W celu zmniejszenia wzrostu kosztu zmian w czasie XP zaleca słuchanie i naukę z wszystkich możliwych zródeł, koncentrację na ciągłym planowaniu, projektowaniu, testowaniu i komunikacji.
Pewne zmiany w systemie zawsze będą kosztowne ale są tańsze, gdy są wprowadzone wcześnie (krótkie cykle pytanie- odpowiedz. 14
Szybkie odpowiedzi i natychmiastowe reakcje na nie zmniejszają nakład czasu i zasobów dla pomysłów, które wnoszą niewiele nowego.
Błędy są znajdowane na przestrzeni krótkiego czasu (dni, tygodni) a nie miesięcy czy lat.
Planowanie tylko do pewnego stopnia pozwala uniknąć niektórych błędów dopiero rzeczywiste sprawdzenie pozwala poznać niektóre pułapki i zagrożenia.
Pytania i odpowiedzi ułatwiają dostosowywanie harmonogramów i planów. Dzięki temu gdy ktoś znajdzie problem, projekt jest natychmiast kierowany na właściwy tor z uwzględnieniem tego problemu.
Częste uzyskiwanie odpowiedzi umożliwia częste wprowadzanie poprawek i wyciąganie wniosków na ich podstawie.
Zaleca się aby klient mógł uczestniczyć w projektowaniu kodu: przeglądać funkcje w trakcie ich tworzenia cenne uwagi klienta mogą wcześnie wpłynąć korzystnie na projekt. 15
Częste testowanie ogranicza miejsce poszukiwania błędów do minimum.
Innymi podstawowymi zasadami XP są częste demonstracje i wprowadzanie szybko najważniejszych funkcji.
Czas od projektu do implementacji mierzony jest w godzinach. 16 Wartości XP: Prostota
Prostota oznacza wykonanie tylko tej części oprogramowania, która rzeczywiście musi być wykonana.
XP wychodzi z założenia, że projektowanie na zaś jest trudne i ryzykowane, przewidywalna jest tylko najbliższa przyszłość, dlatego trzeba z realizacją pewnych funkcji się wstrzymać. 17 Wartości XP: Odwaga
Odwaga oznacza konieczność podejmowania trudnych decyzji gdy jest to niezbędne.
Jeżeli funkcja nie działa: naprawia się ją.
Jeżeli kod jest niewystarczający: ulepsza się go.
Informację o ewentualnym fakcie niemożliwości przekazania wszystkich funkcji klientowi trzeba mu natychmiast przekazać. To klient powinien zadecydować jakimi funkcjami się najpierw zająć w przypadku gdy taka sytuacja zajdzie.
Odwagę bardzo trudno wprowadzić: nikt nie chce zle wypaść i tracić twarzy na skutek łamania obietnic.
Jednak jedynym sposobem odzyskania zaufania po błędzie jest naprawienie go i przyznanie się do niego.
Wychodzenie na wprost wyzwaniu jakim jest tworzenie oprogramowania zamiast unikanie go czyni oprogramowanie lepszym. 18 Zakładanie dostatecznej ilości czasu i zasobów
Tworzenie oprogramowania to nieustanny wyścig związany z czasem i zasobami.
XP ma inne podejście i zakłada wystarczającą ilość czasu na wykonanie oprogramowania.
XP twierdzi, że tylko zapewnienie wystarczającej ilości czasu i zasobów prowadzi do dostarczenia oprogramowania o satysfakcjonującej klienta jakości.
W XP zamiast spieszyć się z powodu zbliżającego się terminu, praca odbywa się w normalnym tempie. Ilość wykonywanej pracy jest zawsze stała i dostosowuje się możliwości, by spełnić harmonogram przy przyjętych ograniczeniach czasowych. 19 Wystarczająca ilość czasu
Wystarczająca ilość czasu na wykonanie zadań zapewnia niewielki koszt zmian i małą liczbę popełnianych błędów.
Zakłada się, że klient może łatwo i tanio zmienić priorytety. Klika technik XP czuwa nad tym by, kod był elastyczny (łatwy do modyfikacji i rozszerzania).
XP stara się wykonać najlepsze oprogramowanie przy dostępnych zasobach i czasie, zakłada się jednak, że dobrze oszacowano ilość pracy jaką rzeczywiście da się wykonać.
Projekty XP mają bardzo krótkie cykle, co redukuje odstęp czasu między projektowaniem (analizą) a wykonaniem oprogramowania (działaniem).
Wprowadza się wiele mechanizmów oceny i weryfikacji na każdym z etapów co umożliwia szybkie wprowadzanie poprawek. Projekt prawie od razu produkuje pewne wyniki więc daje się sprawdzić czy podąża się właściwym torem. 20 Wystarczająca ilość zasobów
XP zapewnia wystarczającą ilość zasobów w trakcie tworzenia systemu informatycznego.
Liczba programistów określa liczbę pracy wykonywanej w jednostce czasu modyfikuje się możliwości, aby dopasować projekt do zasobów.
Programiści muszą wykazać oszacowania przewidywanego czasu trwania każdego zadania.
Następnie, ma miejsce poprawa tych ocen wraz z realnym czasem spędzonym na wykonywaniu zadania. Z czasem te oceny są tak precyzyjne, że mogą być użyte na etapie planowania.
Daje to możliwość klientowi utworzenia budżetu zasobów niezbędnego na poszczególne elementy systemu. Po pewnym czasie w projekcie nabiera się doświadczenia a więc zasoby wraz z upływającym czasem są coraz lepiej wykorzystywane.
Odwrotnie niż w podejściu klasycznym, wraz z rozwojem kodu coraz łatwiej dodawać nowe funkcje. 21 Stały koszt zmian
W klasycznych technikach rozwijania oprogramowania koszty zmian z upływem czasu dramatycznie rosną. Np w modelu kaskadowym gdzie czas, który upływa od momentu planowania/projektowania do testowania oprogramowania wykrycie błędów może wiązać się z powtórzeniem całego cyklu życiowego rozwijania oprogramowania. W klasycznych modelach cyklu życia aplikacji koszty zmian narastają.
XP zapewnia stały w czasie koszt zmian: dodanie nowej funkcji będzie tak samo kosztowne za rok, jak w chwili obecnej.
Dzięki temu opóznia się wprowadzenie pewnych funkcji do czasu aż będą rzeczywiście potrzebne.
XP inwestuje czas i zasoby tam, gdzie oczekuje się natychmiastowych wyników.
Redukuje się koszt zmian, poszukując ciągłego kontaktu z klientem. Klient otrzymuje działającą wersję kodu, tak szybko jak to jest możliwe, często już klika tygodni po rozpoczęciu projektu. 22 Wydajność twórców oprogramowania
XP stawia bardzo wysoką poprzeczkę pod względem umiejętności programistów i projektantów.
Programiści często pracują w parach i dwóch programistów pracuje nad tym samym kodem.
Cała baza programistyczna projekt i implementacja jest otwarta na udoskonalenia.
XP zapewnia kilka pętli pytań i odpowiedzi na etapie kodowania wymuszając na programistach staranność i skrupulatność. Częste testowanie umożliwia usunięcie błędów natychmiast po ich wykryciu.
Dzięki zgodzie na modyfikację poziomu możliwości przy pozostawieniu czasu stałym unika się frustracji i przepracowania.
XP zakłada, że cały zespół menadżerowie, programiści, analitycy i klienci mają swobodę eksperymentowania.
Główny cel XP: wykonywanie wydajnego oprogramowania poprzez wykonywanie naprawdę ważnych zadań. 23 Techniki XP
Istnieje 12 technik XP, które wzajemnie oddziałują i wspierają się nawzajem.
Techniki te pomagają podejmować trafne decyzje i wykonać oprogramowanie wysokiej jakości w przewidzianym czasie.
Często stosuje się tylko kilka technik, lecz stosowanie się do wszystkich daje lepsze rezultaty.
Każda technika spełnia kilka zadań.
Wykorzystanie kilku technik bez znajomości ich współdziałania często prowadzi do poważnych błędów.
Najlepszym sposobem zapewnienia dobrego oprogramowania jest stosowanie i praktykowanie XP
XP nie jest uniwersalną receptą: istnieją inne techniki, czasami wygodniejsze do specyficznych typów zadań.
3 grupy technik XP: kodowania, współpraca programistów, związki między zagadnieniami technicznymi a biznesowymi. 24 Techniki kodowania
Pisanie kodu to jeden z najważniejszych elementów tworzenia oprogramowania.
Większość czasu i energii poświęcanej projektowi dotyczy właśnie kodu stąd duże zainteresowanie tym elementem tworzenia oprogramowania ze strony XP.
Programiści praktykujący XP piszą najpierw kod aby sprawdzić i ocenić swoje plany. Wiele osób postrzega, że programiści XP piszą kod bez żadnego planowania. Jest odwrotnie, pisanie kodu umożliwia planowanie.
Cztery techniki kodowania współpracują ze sobą, aby powstał kod prosty w utrzymaniu, elastyczny i zawsze gotowy do dostarczenia klientowi. 25 Technika kodowania #1: proste projektowanie i kodowanie Cel: wykonanie oprogramowania łatwego w modyfikacji
Należy wykonywać proste projekty i pisać prosty kod, który spełnia aktualne potrzeby klienta.
Unika się odgadywania przyszłych potrzeb, zarówno na etapie pisania kodu jak i projektowania.
Nadrzędny cel to elastyczność, prostsze projekty łatwiej zrozumieć i nimi zarządzać.
Prosty kod łatwiej testować, konserwować i modyfikować.
XP skraca czas planowania do minimum, preferuje spędzenie niewielkiej ilości czasu przed napisaniem kodu.
Projekt uwidacznia się wraz z rozbudową systemu.
Dla kontrastu tradycyjne podejście zakłada, że zmiany są trudne i kosztowne więc trzeba wszystko zaplanować przed rozpoczęciem pracy. 26
XP zakłada, że zmiany są nieuniknione więc plan powinien się dostosowywać. Pracując w krótkich cyklach, cały czas testując czy jesteśmy na właściwej drodze, identyfikujemy błędy i szybko dostosowujemy się do zmian.
Skupiamy się na prostocie i terazniejszości, XP przestrzega przed dodawaniem funkcji `na zaś', gdyż każda funkcja wnosi pewien koszt, zabiera czas, zasoby i odciąga od głównego nurtu projektu.
Niepotrzebne funkcje zaśmiecają i komplikują system chęć ich dodania wynika ze strachu, że wprowadzenie ich w przyszłości będzie kosztowne i trudne.
XP uzyskuje elastyczność poprzez prostotę.
Zadaje się pytanie: Czy można uprościć kod i nadal przejść przez odpowiednie testy .
Przewidywanie przyszłości jest trudne, należy projektować tylko to co jest aktualnie potrzebne. 27
Prosty projekt zapewnia:
wspólną odpowiedzialność za kod (z racji jego prostoty złożone systemy wymagają specjalizacji)
refaktoryzację (ponieważ w prostszym kodzie łatwiej dostrzec niebędne do przeprowadzenia zmiany)
testowanie (ponieważ prostszy kod łatwiej sprawdzić).
Prosty projekt wymaga:
dobrej komunikacji między twórcami a klientem
pewności siebie
zdolności do znajdowania prostoty i chęci jej utrzymania (czyli unikania komplikowania rzeczy, które da się zrobić prosto). 28 Technika kodowania #2: refaktoryzacja Cel: znalezienie optymalnego projektu kodu
Refaktoryzacja oznacza poprawę projektu aktualnego kodu bez zmiany jego zachowania.
Refaktoryzacja poprawia istniejący kod, by stawał się prostszy, krótszy i elastyczniejszy.
Refaktoryzację należy przeprowadzać regularnie zaraz po fazie testów nowego kodu.
Wiele środowisk programistycznych (IDE) wyższej klasy obsługuje podstawowe metody refaktoryzacji, które wykonuje się automatycznie: wystarczy określić cel refaktoryzacji a środowisko wykona niezbędne poprawki lub powróci do stanu oryginalnego.
Refaktoryzacja jest o tyle ważna, że XP zachęca do powstawania projektu na podstawie eksperymentów z kodem a to prowadzi do powstania kodu nieeleganckiego i niskiej jakości. 29
Refaktoryzacjia to eliminacja powtórzeń (duplikacji kodu), podział długich metod i funkcji na krótsze, uściślenie nazw metod i zmiennych, ciągłe upraszczanie i poprawianie.
Celem refaktoryzacji jest uproszczenie projektu i zmiana jedynie struktury kodu, bez wpływania na zachowanie. Testy przed i po wykonaniu refaktoryzacji powinny dać takie same wyniki.
Czasem zdarza się sytuacja, że po dłuższym czasie spędzonym nad refaktoryzacją, zauważa się możliwość znacznego uproszczenia architektury systemu. Należy zapytać się klienta o zgodę na zmiany i być gotowym na obronę swojej tezy pod względem biznesowym. 30
Refaktoryzacja zapewnia:
prosty projekt (ponieważ zmiany są wprowadzane regularnie)
dyscyplinę
Refaktoryzacja wymaga:
dyscypliny (ponieważ refaktoryzację należy przprowadzać, gdy tylko to możliwe)
obiektywnych testów (aby upewnić się, że zachowanie kodu jest takie samo przed jak i po refaktoryzacji)
wspólnej własności kodu (oznacza to możliowość poprawienia dowolnego fragmentu systemu)
standardów kodowania (aby wykonywać zmiany w taki sposób jak to oczekuje zespół) 31 Technika kodowania #3: opracowanie standardów kodowania Cel: łatwe przekazywanie pomysłów przy użyciu kodu
Standardy pisania (kodowania) programów tworzy się w celu pomocy programistom w komunikowaniu się poprzez kod. Kod to główne narzędzie komunikacji w całym projekcie.
Standardy kodowania wykorzystują najlepsze praktyki programistyczne i są to pewne konwencje w stosunku do kodu.
Standardy kodowania nie muszą być sztywne (obowiązujące cały czas). Ewoluują wraz z projektem.
Standardy kodowania to wskazówki a nie rozkazy. Trzeba wiedzieć kiedy stosować się do standardów a kiedy je zawiesić.
Standardy kodowania oszczędzają czas.
Niektóre projekty stosują zautomatyzowane testy czy kod spełnia standardy kodowania.
Znany standard: Notacja węgierska w Microsoft opracowana przez Charlesa Simonyi 32
Standardy kodowania zapewniają:
refaktoryzację (łatwiej zobaczyć zmiany i zautomatyzować modyfikacje, gdy kod jest jednorodny stylowo)
programowanie w parach (programiści skupiają się na kodzie a nie na stylu)
wspólną własność kodu (kod zawiera elementy wspólne dla całego zespołu a nie tylko programistów danego kodu)
Standardy kodowania wymagają:
pracy zespołowej (w celu ustalenia wspólnych preferencji i przyzwyczajeń)
okresowych sprawdzeń (aby sprawdzić czy standardy nadal pasują do kodu po jego ewolucji)
programowania w parach (aby zachować - wymusić standardy w nowo tworzonym kodzie) 33