Programowanie ekstremalne

Ten artykuł od 2009-03 wymaga zweryfikowania podanych informacji.
Należy podać wiarygodne źródła, najlepiej w formie przypisów bibliograficznych.
Część lub nawet wszystkie informacje w artykule mogą być nieprawdziwe. Jako pozbawione źródeł mogą zostać zakwestionowane i usunięte.
Dokładniejsze informacje o tym, co należy poprawić, być może znajdują się w dyskusji tego artykułu.
Po wyeliminowaniu niedoskonałości należy usunąć szablon {{Dopracować}} z tego artykułu.

Programowanie ekstremalne (ang. eXtreme Programming, XP) – paradygmat i metodyka programowania mające na celu wydajne tworzenie małych i średnich „projektów wysokiego ryzyka”, czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces.

Podstawą ekstremalnego programowania jest synergia wynikająca ze stosowania rozmaitych praktyk, które same w sobie mają wiele zalet, lecz mogą być trudne w zastosowaniu. Łączne użycie tych praktyk ma zapewniać wyeliminowanie niedogodności każdej z nich.

Podstawowe założenia zostały sformułowane przez Kenta Becka. Stroną, która służyła do wymiany poglądów na temat programowania ekstremalnego było pierwsze na świecie Wiki Portland Pattern Repository założone przez Becka i Cunninghama.

Zalecenia

Iteracyjność

Program tworzy się w iteracjach (krótkie, przyrostowe kroki programistyczne) – i co ważniejsze – planuje tylko następną iterację. Efektem każdej iteracji (kilka tygodni) powinna być wersja programu spełniającą założenia dla danej iteracji. Następnie planuje się co zrobić dalej.

Odpowiada to zasadzie Open Source: „release early, release often” (wczesne i częste wydania).

Nie projektować z góry

Nie można z góry przewidzieć, jaka architektura będzie najlepsza dla danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania programu.

Testy jednostkowe

Testy jednostkowe pisze się zanim w ogóle zacznie się pisać kod – najlepiej na początku iteracji. Potem pisze się kod, który potrafi je wszystkie przejść. Takie testy dają zapewnienie (o ile testy są dobrze napisane), że to, co ważne, zostanie zaprojektowane, na to zaś, co nie jest ważne, programiści nie będą tracić czasu.

Ciągłe modyfikacje architektury

Architektura nie jest czymś, czego nie wolno ruszać. Jeśli modyfikacja architektury ułatwi przejście danej iteracji i nie zepsuje wyników testów uzyskanych na poprzednich, należy ją wykonać. Pod tę zasadę podlega także usuwanie wszystkich znanych błędów przed rozszerzeniem funkcjonalności.

Programowanie parami

Programiści piszą w parach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w parze zamieniają się rolami co kilkadziesiąt minut. Ta technika umożliwia wyłapanie wielu błędów oraz wzajemną naukę. Kod, którym zajmuje się tylko jedna osoba, ma tendencje do stawania się całkowicie niezrozumiałym dla kogokolwiek innego niż autor, więc dodatkowy programista zwiększa jakość kodu.

Nie jest jasne, czy sumarycznie łączna wydajność pracy przy takiej metodzie jest wyższa, taka sama, czy niższa niż w tradycyjnym programowaniu indywidualnym.

Stały kontakt z klientem

Specyfikacje są prawie zawsze wieloznaczne, dziurawe i sprzeczne ze sobą. Tak więc należy mieć stały kontakt z tym, dla kogo to oprogramowanie jest tworzone (klient zamawiający program, czy też użytkownicy końcowi). Jeśli kontakt jest dobry, można się nawet obyć bez specyfikacji.

Kwestie kontrowersyjne

  • Brak dokładnej specyfikacji.
  • Konieczna stała dostępność przedstawiciela klienta.
  • Wspólna „własność” kodu – każdy może zmieniać dowolny fragment systemu.

Zobacz też

  • Zwinne programowanie – (ang. agile programming) rodzina metodyk, do której zalicza się również XP
  • XPrince – likwidacja słabych stron XP
  • Portland Pattern Repository – wiki oraz repozytorium dla wzorców projektowych

Linki zewnętrzne