Programowanie ekstremalne

Gdy czasem czytam blogi, które ukazują się na dobrychprogramach, dochodzę do wniosku, że w dalszym ciągu na uczelniach zbyt wiele czasu poświęca się nauce teorii, miast porządnie przygotować do pracy programistów. A potem jest niestety tak, że student bez praktyki, po prostu nie może się odnaleźć na rynku pracy. To natomiast napędza wszystkich frustratów do wypłakiwania się na forach o złych pracodawcach oczekujących nie wiadomo czego od pracownika.

Sądzę, że to głównie dlatego, iż uczelnie uczą programowania idealnego. Co to dla mnie znaczy? Programowanie idealne polega na tym, by stworzyć program idealny. By przewidzieć wszystkie możliwości, zaplanować reakcje na nie, stworzyć obszerną, doskonałą dokumentacje, idealnie sformatować kod i zachować jak największą lekkość kodu. Tymczasem w przyrodzie nie występuje nic "idealnego" i "doskonałego". Są natomiast rozwiązania, które mimo swoich oczywistych niedoskonałości działają. W procesie tworzenia aplikacji jest jeszcze jeden ważny czynnik. Klient. Klient to pojęcie z teorii metodyk programowania i oznacza każdą osobę, która ma wpływ na kształt programu (czyli np. funkcjonalność, funkcyjność itd), ale nie jest programistą. Takich osób, drodzy studenci na swojej drodze spotkacie dziesiątki w jednej tylko firmie. I to niezależnie od tego, czy programujecie front- czy back-end aplikacji. A zmiany dokonywane będą w sposób chaotyczny, nieskonkretyzowany, często wykluczający się wzajemnie.

I napisz tu, jeden z drugim, do tego dokumentację.

Programowanie ekstremalne

Ludzie piszą swoje programy od wielu lat, od wielu lat również piszą je komercyjnie. Dlatego wielu z nich wpadło już na ten pomysł, że tworzenie dokumentacji do rozwijanej aplikacji jest często stratą czasu. O ile jeszcze warto metodę opisać trzema parametrami (co przyjmuje, co zwraca, co w ogóle robi), o tyle rozpisywanie się na temat zasad działania to strata zasobów. Dlatego Enterprise Architect i UML powoli zostaje wyparty przez Planning Poker i Scrum.

Czym w ogóle jest programowanie ekstremalne? To rodzaj metodyki pracy przy którym tworzone są aplikacje "wysokiego ryzyka". To wysokie ryzyko pochodzi stąd, że tworzony kod nie jest do końca jasny i zaplanowany, jednak przyjmuje on i zwraca oczekiwane wyniki. Bardzo często fragment kodu pochodzi z innej aplikacji lub jest emulowany na inny język programowania. Te fragmenty kodu oraz kod, który powstaje w czasie programowania nie jest dokumentowany. Jedynie weryfikowany przez testy jednostkowe.

Programowanie ekstremalne jest jednak tylko jedną z metodologii zaliczanej do tak zwanego Agile Programming i jest (jak nazwa wskazuje) ekstremalna metodą. Omówię trochę bardziej Scrum.

Scrum

Scrum to jedna z metod zwinnego programowania, nastawiona na realne tworzenie produktu. Realne, a więc stałe jego rozwijanie. Metodyka ta zakłada pracę w oparciu o tzw. sprinty. A dokładniej wygląda to tak:

Spotkanie z klientem - grupa projektowa (nie tylko sami programiści, ale także analitycy, często graficy, scrum master) spotyka się z klientami, którzy określają zakres oczekiwanych rozszerzeń aplikacji. Na tym etapie bardzo często klient popuszcza wodzę wyobraźni, ale to nic nie szkodzi. Im więcej się dowiemy, tym lepiej będziemy znać oczekiwania klienta. Te rozszerzenia powinny być konkretne, ale sformułowane ogólnie. Czyli na przykład "dodanie możliwości zakupu na raty", ale nie "dodanie nowych możliwości zakupów".

Planowanie sprinta - Często nazywa się ten etap estymacją sprinta, czyli nadawaniem odpowiedniego priorytetu dla każdego z oczekiwanych rozszerzeń aplikacji. Tutaj przydaję się wzmiankowany planning poker. Jest to po prostu talia kart, ponumerowana, która rozdaje się wśród grupy projektowej. Każde z rozszerzeń jest oceniane przez pracownika przez wartość karty. Osoby, które ocenią je najwyżej oraz najniżej muszą swój wybór uzasadnić i przekonać innych do swoich racji. Karty pokazuje się tyle razy, aż nie nastąpi pełna zgoda. Następnie określa się ilość zasobów (czyli osobogodzin, ale zasób brzmi ładniej) dla konkretnego zadania. Po wyczerpaniu zasobów estymacja kończy się, a rozszerzenia, które nie weszły do sprinta przechodzą do następnego.

Sprint - sam sprint to okres pracy zespołu projektowego nad zadaniami. Jego okres jest różny (znam firmy, gdzie okres ten trwa 3 miesiące, znam takie, gdzie trwa trzy tygodnie). Zadaniem zespołu jest wykonanie wszystkich zadań, które sobie założył. Dobrą praktyką jest stosowanie tej samej długości sprintów (dzięki temu lepiej rozplanowuje się czas) oraz organizacja tzw. daily meetingów, czyli codziennych spotkań (najlepiej porannych), w których omawia się problemy dnia poprzedniego. W tym momencie klient już nie może nic zmienić w swoich rozszerzeniach, a scrum master dba o to, by zespół projektowy mógł pracować niezależnie.

Prezentacja sprinta - Po zakończeniu sprinta prezentowane są wyniki prac zespołu projektowego. Zawsze powinno być tak, że pokazywane są "namacalne" zmiany. Każdy zamieszany w projekt może brać udział w prezentacji i zabrać głos. Często zdarza się, że w takich momentach zespołu projektowy zwraca uwagę klientowi na brak logiki w zgłaszanych rozszerzeniach.

A teraz loop, czyli wszystko się powtarza. Dzięki takiej metodyce prac w końcu w kliencie i zespole projektowym wyrabia się nić porozumienia, projekt staje się solidny i rozbudowany.

Oczywiście są wady również takiego rozwiązania (i w ogóle programowania zwinnego). Przede wszystkim mała ilość dokumentacji kodu powoduje, że bardzo ciężko zmienia się zespół projektowy. Ogromna ilość wiedzy na temat kodu i jego działania znajduje się po prostu w głowach programistów, dlatego bywają sytuacje, gdy rozbudowa kodu o nowe rozszerzenie jest bardzo czasochłonna.

Podsumowanie

W zasadzie to wszystko, co chciałem napisać w tym temacie. Niestety moja natura zmusza mnie do dodania złośliwej uwagi - drogi czytelniku! Jeśli uważasz, że po zaliczeniu na pierwszym roku programowania w C zostaniesz przyjęty do pracy z otwartymi ramionami, jeśli uważasz, że Twoje porfolio aplikacji można rozszerzyć grafami klas, jeśli uważasz, że dla Twojego klienta ma większe znaczenie, czy kod jest optymalny czy oddany w terminie - uważaj! Możesz zostać niemile zaskoczony.