print
A A A

Programowanie ekstremalne – XP

Motywacja:

  • klasyczne metodologie wytwarzania oprogramowania zbyt wolno reagują na zmiany rynku i wymagań klientów
  • zbyt dużo planowania, analizy i tworzenia modeli oraz dokumentacji opóźnia wytworzenie i dostarczenie tego co naprawdę się liczy – kodu
  • klasyczne podejścia powodują, że zmiany (spowodowane np. wykryciem błędu) w późnych fazach tworzenia kodu są bardzo kosztowne
  • w procesach opartych na drobiazgowej analizie i planowaniu zbyt mało ufa się i daje swobody, tym którzy tak naprawdę tworzą kod – programistom

Podstawowe zasady XP:

  • oprogramowanie jest rozwijane w krótkich cyklach i w ciągłej interakcji z klientem, po każdym cyklu może nastąpić zmiana założeń co do dalszej pracy, co więcej może nastąpić rewizja już napisanego kodu (refactoring)
  • każdy przyrost dostarcza konkretną funkcjonalność określaną na podstawie scenariuszy ("opowieści użytkownika", user stories)
  • już pierwsze wydanie zawiera system o pewnej całościowej strukturze realizujący istotne dla klienta funkcje
  • kolejne wydania (releases) kodu następują co kilka miesięcy (maximum), iteracje mają po kilka tygodni, obowiązuje planowanie zadań kilka dni do przodu, przy założeniu, że kolejność działań jest określana przez priorytety ważności
  • przed przystąpieniem do kodowania opracowywane są szczegółowe testy mające za zadanie sprawdzenie wszelkich aspektów poprawności wprowadzanych zmian
  • każda zmiana jest od razu integrowana z całością kodu oraz testowana – nowe oraz opracowane wcześniej testy (zautomatyzowane) są powtarzane codziennie (lub nawet kilka razy dziennie), żeby sprawdzić czy nie zostały wprowadzone błędy
  • w ciągu całego procesu gromadzona jest informacja zwrotna służąca usprawnieniu procesu i ostatecznego kodu
  • ważna jest specyficzna organizacja miejsca pracy
  • kodowanie realizowane jest zgodnie z przyjętymi przez cały zespół regułami (coding standards)
  • programowanie odbywa się parami (zgodnie ze szczegółowo ustalonymi zasadami), częste są także dyskusje pomiędzy członkami całego zespołu tworzącego kod
  • dokumentacja oprogramowania składa się z:
    • komentarzy w kodzie
    • opisu testów
    • niewiele więcej

XP, a podejście klasyczne

Jedną z podstawowych różnic pomiędzy programowaniem ekstremalnym i podejściem klasycznym jest stosunek do specyfikacji i dokumentacji. W XP specyfikacja jest rozwijana na bieżąco, w trakcie iteracyjnego tworzenia kodu i we współpracy z klientem (a nie jest tworzona przed implementacją i opisywana w rozległej dokumentacji). Podobnie zapewnienie jakości odbywa się poprzez testowanie dokonywane na bieżąco, a nie poprzez sprawdzenie zgodności ze specyfikacją. Klasyczne podejścia mogą stosować XP do tworzenia prototypów (do wyrzucenia), np. w fazie odkrywania i walidacji wymagań lub projektowania GUI.

Projektowanie kodu w ramach XP:

  • pojęcie „metafory” zamiast architektury kodu – próba syntetycznego, przenośnego wyrażenia istoty logicznej struktury kodu (np. metafora koszyka na zakupy w programach e-commerce)
  • szczegółowe planowanie kolejnych działań w ramach iteracji – „gra w planowanie”, planning game
  • nacisk na prostotę struktury kodu w każdym momencie (realizacja całej funkcjonalności kodu przy użyciu jak najmniejszej liczby klas i metod, bez duplikacji – zasada once and only once)
  • ciągła refaktoryzacja dla poprawy struktury kodu (designing through refactoring)
  • karty CRC używane do projektowania klas

Gra w planowanie:

  • we wzajemnej interakcji pomiędzy przedstawicielami klienta i programistami powstaje schemat kolejnych działań
  • klient decyduje o:
    • zakresie funkcjonalności (co system ma robić, user stories)
    • priorytetach funkcji (do sterowania wydaniami)
    • składzie konkretnych wydań
    • datach wydań
  • wytwórca (programista) decyduje o:
    • oszacowaniu koniecznych zasobów do realizacji
    • technicznych konsekwencjach podjętych decyzji
    • organizacji procesu wytwarzania oprogramowania
    • szczegółowym harmonogramie realizacji wydania

Cykl programowania w XP:

  • początek: napisz test
  • skompiluj test (powinno się nie udać – nie ma jeszcze kodu)
  • zaimplementuj tyle, aby udało się skompilować
  • wykonaj test (powinien się nie udać – kod nie jest kompletny)
  • zaimplementuj tyle, aby przejść pomyślnie test
  • wykonaj test
  • dokonaj refaktoryzacji, dla uproszczenia, usunięcia powtarzalności
  • przeprowadź wszystkie istniejące testy
  • przejdź do następnego zadania i zacznij od początku

Testy w XP:

  • zawsze izolowane (sprawdzające jeden aspekt, fragment kodu)
  • zautomatyzowane – możliwe do włączenia w zestaw zadań sprawdzających kod, uruchamianych po każdej modyfikacji (do kilku razy dziennie)
  • dzielące się na:
    • funkcjonalne – inspirowane przez klienta i transformowane w testy jednostkowe przez specjalnie oddelegowanego członka zespołu
    • jednostkowe – tworzone przez programistów do testowania poszczególnych metod
    • inne: symulujące losowe dane wejściowe, symulujące najgorsze przypadki, porównujące różne wersje systemu

Uczestnicy procesu XP:

  • klient
  • programiści
  • tester – współpracuje z klientem przy pisaniu scenariuszy i uruchamia testy sprawdzające realizacje scenariuszy
  • śledzący (tracker) – sprawdza postęp prac oraz weryfikuje wszelkie oszacowania
  • trener (coach) – nadzoruje proces tworzenia oprogramowania przez zespół, pomaga, kontroluje, itp.
  • konsultant (okazjonalnie)
  • szef – podejmuje strategiczne decyzje, zdobywa zasoby, reprezentuje zespół na zewnątrz

Troska o programistów w ramach XP:

  • 40-godzinny tydzień pracy – „mamy za dużo pracy” zamiast „mamy za mało czasu”
  • odpowiednie środowisko pracy – otwarta przestrzeń z małymi prywatnymi pomieszczeniami na obrzeżach i stanowiskami w środku dla programowania parami
  • wspólne posiadanie kodu
  • nacisk na nieustanną komunikację (związane m.in. z programowaniem parami)
  • stworzenie ideologii zespołu walczącego o zwycięstwo (i nagradzającego się za wszystkie osiągnięcia)
  • dużo jedzenia i picia w zasięgu ręki
  • zasada “work with human nature, not against it”

Programowanie ekstremalne jest propagowane jako rewolucja w tworzeniu oprogramowania.

Opisywane jako oparte na wartościach:

  • komunikacji
  • prostoty
  • informacji zwrotnej
  • odwagi (!?)

Do problemów, na które natyka się programowanie ekstremalne należą:

  • niedostosowanie do wymagań niektórych klientów (wymagających kontraktów, rozbudowanej specyfikacji, bogatej dokumentacji itp.)
  • niedostosowanie do struktur organizacyjnych tradycyjnych (dużych) firm software'owych (mających np. biura rozproszone w różnych częściach świata)
  • niedostosowanie do mentalności niektórych programistów
  • trudność utrzymania prostej struktury kodu, w miarę jego wzrostu dokonywanego metodami ewolucyjnymi
  • trudność zapewnienia wymagań bezpieczeństwa i niezawodności dla niektórych rodzajów systemów

«RUP     Agile Programming»