Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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. 

Komentarze

0 nowych
MaXDemage   18 #1 17.09.2011 11:45

Dopowiem kilka swoich uwag, mam nadzieje, że wybaczysz.

Każdy programista "powinien" dążyć do kodu idealnego. Nie można powiedzieć - "nie da się" i jedziemy jak popadnie. Nie można robić tak, że wrzucamy ekstremalne programowanie i gówno nas obchodzi czy ktoś potem przejmie ten kod czy nie ;p

Życie jednak weryfikuje wiele rzeczy. Sam byłem przeciwny sprintom i chaosu, który podczas nich trwa (o ile ma się kiepskiego PMa). Jednak tylko tak wyrabiasz normy, tylko tak dostarczasz coś na czas. Pokochałem więc ten rodzaj metodyki :> nie miałem wyjścia.

Nasz klient nasz Pan.

Acz nie zgodzę się że bolivar plecie bzdury. Dużo zależy od firmy, od podejścia i od tego dla kogo jest aplikacja. Bo jeśli tworzymy swoją aplikację, która potem wydajemy, proces wygląda dużo inaczej niż w momencie gdy robimy dla kogoś. Różne projekty, różne metodologie. Pytanie też jak duży jest team programistów? Jakie są terminy? Jakiego maja PMa? Czy zatrudniają studentów 2 roku za najniższa krajową? Jakie kanapki są w bufecie?

:)

tfl   8 #2 17.09.2011 12:06

@MaxDamage

Tekst o programowaniu ekstremalnym pisac chcialem juz od dosc dawna, ten napisalem dzis, po przeczytaniu tekstu Bolivara. Bo po prostu mnie zalewa krew, gdy czytam, ze programista staje sie testerem, gdy weryfikuje, czy string sie zmiesci w bazie. I ze nie wie, ze ktos zmienil wymagania. To typowa spychlogia leniwego googleprogramisty. Googleprogramista, to uknuty przeze mnie rzeczownik, oznaczajacy programiste, ktory kopiuje bez sensu, skladu i ladu klasy z googla, a potem sie dziwi, ze mu kodowanie sie rozjezdza (na przyklad).

Bede uparcie stal przy tym, ze psim obowiazkiem programisty poza pisaniem kodu jest jego weryfikacja. To programista odpowiada za jakos tego co pisze, nie tester. Nie ma "nie wiedzialem", "zapomnialem", "nie poprawilo sie". Unit testy sa od tego.

bolivar   9 #3 18.09.2011 13:42

@tfl: "Parę dni temu na łamach DP pojawił się wpis bolivara o testowaniu aplikacji. Panie szanowny! Nie wiem, gdzie tworzysz swój kod, ale piszesz straszne bzdury. Nie jest zadaniem testera sprawdzanie, czy wielkość pola w bazie się zgadza, bo to jest obowiązek programisty (od razu - nie jest to też obowiązek administratora). Unit testy pisze programista jeszcze przed napisaniem właściwego kodu. Tester sprawdza czy kod działa w całości, a nie weryfikuje pojedynczych metod."
To był tylko przykład... Jeżeli nie przemówił do ciebie to przykro mi, jednak obrazuje przypadek z którym osobiście spotkałem się.

Szkoda, że nie przedstawiłeś manifestu Agile
http://en.wikipedia.org/wiki/Agile_Manifesto#Agile_Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
który oddaje kwintesencje całej metodologii.
Jest też oczywiście druga strona medalu.:
http://dilbert.com/strips/comic/2007-11-26/
;-)

"Bede uparcie stal przy tym, ze psim obowiazkiem programisty poza pisaniem kodu jest jego weryfikacja. To programista odpowiada za jakos tego co pisze, nie tester. Nie ma "nie wiedzialem", "zapomnialem", "nie poprawilo sie". Unit testy sa od tego."
Już cię lubię :-)
Niestety na swojej własnej skórze doświadczyłem, że testy i testerzy są potrzebne. Widziałem w mojej poprzedniej firmie jak spadła ilość zgłoszeń od klientów po wprowadzeniu testerów do firmy.

ps.
nie pracuję jako programista - jestem testerem. Programowaniem bawię się ;-)

bolivar   9 #4 18.09.2011 14:22

By była jasność zamieściłem pod wpisem dodatkową informację.
Mam nadzieję, że sporo ona wyjaśni:

[add 14:19 18-09-2011]
Podaje proste przykłady - proszę brać pod uwagę, że DB czytane są zarówno przez osoby zaczynające przygodę z IT jak i mające już kilka lat na karku. Proszę to brać pod uwagę, że nie każdy z nas/was posiada kilkunastoletnie doświadczenie w projektach. Niektórzy myślą dopiero o przyszłości i dla nich głównie są te wpisy.

tfl   8 #5 18.09.2011 15:42

Wiec wdarlo sie nieporozumienie. Odebralem Twoj tekst jako rodzaj usprawiedliwienia dla programistow, ktorzy nie musza wiedziec o wszystkim w czym pisza.

W zwiazku z Twoim wyjasnieniem usuwam (krzywdzacy) fragment.

Ciesze sie, ze mamy podobne zdanie na ten teamt.

bolivar   9 #6 18.09.2011 16:15

@tfl: Przyznam, że po kilku zdaniach już wiem, że naprawdę miło się z Tobą pracuje :-)

Czekam na dalsze wpisy o Agile - sam pracuję w zespołach wykorzystujących tą metodę prowadzenia projektów.

SnajperskY   4 #7 18.09.2011 19:29

Fajny, sensowny wpis. Czekam na kontynuację z przełożeniem owych metod na własne doświadczenia. Wiadomo, że żadnej reguły nie można stosować 1:1 w każdym przypadku. Ogólniki są dobrym, ale materiałem na wiki :)

Ze wszystkim się zgadzam, ale tutaj paradoksalnie poniosło Cię, tak skrytykowane przez Ciebie idealistyczne podejście:

[...]
Bede uparcie stal przy tym, ze psim obowiazkiem programisty poza pisaniem kodu jest jego weryfikacja. To programista odpowiada za jakos tego co pisze, nie tester. Nie ma "nie wiedzialem", "zapomnialem", "nie poprawilo sie". Unit testy sa od tego.
[...]

Nie chciałbym tutaj klepać oczywistych oczywistości, ale obecnie liczy się czas wdrożenia. Klient niejednokrotnie potrafi wymagać byle jakich wydań testowych, aby jak najszybciej ujrzeć funkcjonalność, bądź poprawkę. Nie ma czasu na obkładanie kodu testami jednostkowymi.

Co gorsze, unit testy, podobnie jak dokumentacja, wymagają nieustającej pielęgnacji... Może się z tego zrobić mały pod-projekt :) Oczywiście nie neguję potrzeby ich tworzenia, ponieważ nie raz ratowały mi choćby refaktoryzację, ale klient nasz pan :)

Ze studentami jest jeszcze ciekawiej. Kodowanie kodowaniem, ale niestety tak ważna praca w zespole również jest zwykle tylko iluzją. Owszem, każde CV zawiera wpisy typu "praca w zespole", jednak po głębszej rozmowie okazuje się jak różnie można ten termin interpretować. Daleki jestem od stwierdzenia, że uczelnie wychowują głównie indywidualistów, ale do tej pory przytrafił mi się tylko jeden taki wyjątek od reguły.

Pozdrawiam

SnajperskY   4 #8 18.09.2011 19:44

Aha, poza tym masz bardzo nisko zawieszoną poprzeczkę z napisem "konflikt"... Każda różnica zdań to dla Ciebie już dramat?

SnajperskY   4 #9 18.09.2011 19:45

Zignoruj #8

przemo_li   11 #10 19.09.2011 08:40

@SnajperskY
Jestem zdania, że Klien powinie być poinformowany kiedy jego wymagania mogą zaszkodzić projektowi.

Nie ma nic złego w "dokręceniu śrubki" na krótki okres, ale potem programiści i klient (choć on o tym może nie wiedzieć), z ZŁYM kodem. Trzeba wtedy spędzić troszkę czasu na jego naprawie, tak aby dodawanie nowych funkcji(w rozumieniu funkcjonalności dla klienta) odbywało się efektywnie.

Więc informujmy Klienta kiedy jego prośby degradują projekt, i umiejmy pogodzić jawne życzenia Klienta (nowa funkcjonalność) z niejawnymi życzeniami Klienta (szybkie i niezawodne dostarczanie nowych wersji).

PS Programowanie Ekstremalne (ang. XP) to też określenie na inną metodologię programowania Zwinnego. Więc Scrum to Programowanie Zwinne, XP to Programowanie Zwinne, ale Scrum to nie Programowanie Ekstremalne (XP).

PSPS Programista powinien traktować pisanie kodu złej jakości jako jedno z narzędzi z jego warsztatu, oraz powinien go stosować ze świadomością konsekwencji.

tfl   8 #11 19.09.2011 09:23

@przemo_li

ale przeciez napisalem tak: 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. :)

pozdrawiam

SnajperskY   4 #12 19.09.2011 09:43

@tfl

[...]
Jestem zdania, że Klien powinie być poinformowany kiedy jego wymagania mogą zaszkodzić projektowi.
[...]

Myślę, że poniższe wszystko wyjaśnia :)

[...]
Klient niejednokrotnie potrafi wymagać byle jakich wydań testowych, aby jak najszybciej ujrzeć funkcjonalność, bądź poprawkę.
[...]

Klient klientowi nierówny. Owszem, należy tak manewrować klientem, aby nie zrobić totalnej kupy z projektu, ale ten ciężar spoczywa na nas.

[...]
ZŁYM kodem
[...]

Niestety "zło" jest pojęciem bardzo względnym i zależnym od punktu widzenia. Klienta, póki nie wymaga, nie obchodzi kształt API oraz jakość implementacji. Liczy się termin, mimo że Ciebie krew zalewa patrząc przez swój pryzmat :) Z wiekiem zalew krwi staje się coraz mniejszy co pozytywnie wpływa na projekt :)

[...]
Programista powinien traktować pisanie kodu złej jakości jako jedno z narzędzi z jego warsztatu, oraz powinien go stosować ze świadomością konsekwencji.
[...]

Jak wyżej. Dodatkowo, każdy lider projektu będzie miał inny pomysł na to co jest "złym" kodem. Samemu również ciężko wyważyć kiedy kod jest wystarczająco dobry, a nie "wycackany". Potrzeba lat doświadczenia, aby zrozumieć, że (jak wspomniałeś) kod idealny nie musi, i zwykle nie przekłada się na kod "wystarczający" -> sukces projektu.

Jako, że zaczynamy zahaczać o abstrakcję ukrytą za mgłą, czekam na kolejny wpis :)

SnajperskY   4 #13 19.09.2011 10:02

#12 -> @przemo_li

Sorry, za pomyłkę.

kadoel   1 #14 19.09.2011 19:03

Jeśli chodzi o uczelnię to często całą inżynierię oprogramowania traktuje się bardzo teoretycznie.

przemo_li   11 #15 20.09.2011 16:22

@kadoel
IO nie jest od Metodologi Programowania. Bo te mają więcej wspólengo z psychologią|marketingiem|zarządzaniem|ergonomią, niż inżynierią. (nie żeby nowoczesna inżynieria oprogramowania nią była ;).

przemo_li   11 #16 20.09.2011 16:29

@SnajperskY
Jedynym wyznacznikiem "dobrego" kodu jest możliwość realizowania obecnych i przyszłych życzeń klienta.

A jest to trudne bo zahacza o wróżenie z fusów (tj. przewidywanie życzeń klienta).

Dodatkowo.
Jakość obecnego produktu jest dla programisty bez znaczenia. Liczy się on tylko jeśli będziemy z nim pracować oraz kiedy będziemy dodawać do niego coś nowego. Zły kod oznacza "dług" który kiedyś będzie trzeba spłacić. Spłata długu kosztuje czas i programistów. A gdy dług jest za duży dodawanie jakichś nowości może stać się niemożliwe do czasu jego spłaty.

To trochę jak budowanie wieży z klocków. Można szybko zrobić ją wysoką, ale jeśli klient zażąda wyższej, to trzeba mu powiedzieć, że aby spełnić jego życzenie to trzeba wzmocnić niższe kondygnacje inaczej się załamie.

Czasami trzeba nawet przekonać do takiej idei menadżerów "doglądających" projekt, nie mówiąc o kliencie.

Czy my mówimy o tym samym?