Predem bych rad podotknul, ze o extremnim programovani (XP) toho bylo napsano na internetu pomerne dost (jako ostatne o vsem),
a tak nechci chodit s drivim do lesa. Co bych zde rad postupne zverejnil jsou me osobni zkusenosti, napady a vychytavky, ktere jsem nasbiral pri svem ucinkovani v dosavadnich inscenacich (ano, zamestnani je skutecne jenom velka hra – o tom
napisu samostatny clanek). Nasleduji jednotlive kapitoly, tak jak mi prichazeji na jazyk. 🙂
Extremni extrem
Extremni programovani je vazne zajimavy nazev, podle me trochu zavadejici. Nechapu, ktery z postupu dava dane metodologii punc “extremnosti”.
Mozna je to diky nejznamejsimu parovemu programovani. Pamatuju si jednoho osviceneho kolegu (Svoky), kdyz s tim
prisel za mnou v Unicornu (olala, to uz jsou 4 roky) :
“Vole, ted budeme muset sedet jeden druhymu na kline a usetri se za kompy a zidle”.
I kdyz to byla tenkrat samozrejme hyperbola, i takhle muze vypadat extremni programovani – tam, kde se papouskuje vsechno doslova. Proto dopredu pravidlo cislo 1 – vyzobavame co potrebujeme a aplikujeme ve svych podminkach podle potreby.
Pozn: Zivot je zvlastni, pred napsanim prave teto vety jsem zrovna musel odbehnout k jednomu kolegovi a vyresit problem
s konkurentnima zmenama ve stejnem souboru (i kdyz jsem cely den az do ted nemel pomalu do ceho pichnout) – mel jsem 2 moznosti;
vysvetlit a odbehnout zpet (a tim usetrit 20 minut) nebo setrvat a spolecne s nim celou akci absolvovat a navzajem se pohlidat, ze
nedelame blbosti. Detail,ktery mozna ocenim pristi tyden, kdy se mi nerozezvoni telefonu rozzurenym nakupcikem-geekem na druhem konci, kteremu v combu chybi jeho oblibena ucetni kniha ci kost centrum (rozumej cost centre). I kdyz to bylo sice odlehcene parovani, vubec
jsem si extremne nepripadal. Takze pravidlo cislo 2 – XP nas zbavuje stresu a dodava klidneho spanku.
Casti XP
Jak jsem rekl, o teorii pojednava spousta zdroju treba – XP pornografie.
Nebudu tu opisovat detaily, protoze na to nemam silu a ani v tom nevidim prinos. Jen zde nastrelim buletky s hlavnimi
oblastmi
a) customer stories
b) iterative development
c) pair programming
d) unit testing
e) refactoring
Kladivo na chaozzz
XP, stejne jako kazdou zmenu muzeme aplikovat kdykoliv v prubehu zivota projektu, rozdil je jen v cene. Stejne
jako se vsim, plati cim drive tim lepe. Pro ilustracni ucely jsme se ocitli v situaci, kdy se nam v aplikaci
vyskytl butterfly effect. S timto vedomim si vybirame nasledujici procesy:
1.Refactoring
Kazda sebemensi zmena ovlivni cely system tzn. system nema krasne modularni architekturu nybrz mame zatim hroudu, kterou je potreba uplacat k obrazu svemu. Je to v celku normalni stav, kazda aplikace ma tendence konvergovat k BigBallOfMud. Osobne jsem potkal malo architektu (= 0.9 – ano, jsi to ty Alesi N. 😉 ), kteri byli schopni vyseknout bez logicke/fcni chyby byt jen malou knihovnu, ktera by byla navic jednoducha.
Proto pravidlo cislo 3 – aplikace je polymorf, jejiz kostra reaguje na aktualni pozadavky, neustale se pretvari s cilem limitne se blizit k dokonalosti. A s vedomim, ze se architektura bude menit, musime zajistit, aby se z techto zmen nestala nocni mura, ale naopak okamzik na ktery se tesime. Nedelam si legraci. Nikdy jsem nechapal kolegy, kterych se jimala hruza pri vete “bude se to prepisovat”. Podle me je to druha sance, udelat veci lip s lepsi predstavou skutecnych rizik a nastrah dane domeny. Neco jako odsouzenec na smrt (dobre, radeji na dozivoti), kteremu se rollbackne zivot do checkpointu pred spachanim osudneho cinu.
“Komponenta, dusena jhem aplikaci novych a novych patchu, tak dostane sanci znovu dychat, znovu byt krasna.”
filemon evangelist
2. Unit testing
Duvodem je klidne spani (pravidlo cislo 2) a dale je to vubec podminka nutna pro aplikaci bodu 1. Bez sady testu ke kazde komponente/feature
muzeme na refactoring s uspechem zapomenout. (nebo nemusime, pokud jsme strelci a ne kardasiani < = kardiaci> jako ja). I testy prochazeji vyvojem. Ze zacatku nam pro jejich sestaveni skvele poslouzi zadani sebrana na zacatku projektu – tzv. customer stories, ktera jsou psana jazykem zakaznika tzn. zadne technicke vyrazy.
S tim, jak sestavuju testy se mi pod rukama rodi i vlastni aplikace – interfaces jak graficke tak aplikacni – tzn. uz tehdy programuju, sestavuju prototyp, hraju si. Jak se aplikace stava pouzitelnejsi, pridavam testy podle objevenych bugu.
Ve finale se pak stavam majitelem neocenitelneho testeru – a pri dobre vuli a peci rozhodne lepsiho nez maji servisy Skodovky,
V mem pripade jejich tester neodhalil bug v prevodovce a tak jsem se ocitl v Chorvatsku bez fcni zpatecky. Kdyz si k tomu pridate
tradicni balkanskou horkokrevnost, umite si jiste zive predstavit situaci, kdy na me v uzke ulicce divoce a hlasite gestikuluje
rybar spechajici proti mne v malem nakladacku s ulovkem na trh, rozhodnuty necouvnout ani o pid. 😉
Tak pro dnesek to byla trocha teorie, v pristim dile si povime o konkretnich nastrojich, ktere nam pomuzou XP
snadneji zkrotit a lepe vyuzit.
Pozn: tuhle kapitolu dopisuju na letisti v Zurichu pri cekani na dolet do Phy. Zrovna vyhlasili nabidku 250 EUR tomu, kdo prenecha svuj dnesni let nekomu z potrebnych a odleti az zitra rano. Prihlasila se skupinka 4 japonskych kravataku. Extremni? Urcite, hlavne jejich dnesni vecer. 😉
Pokracovani priste….
Velice pekne napsane Filemone, podle me by si mel do evangelia pridat ” vyzobavame co potrebujeme a aplikujeme ve svych podminkach podle potreby.”. Na jednom internim skoleni, ktere jsme meli ve firme, padlo slovo i na XP a nejvetsi halo zaznamenalo programovani v parech. Ani nevim proc, ale zda se mi, ze se to v urcite trnasformovane podobe deje neustale tj. pul dne programuju s nekym jinym uplne jinou cast projektu, nez kterou mam na starosti :-). Vyhoda je v tom, ze se vzajemne obohacujeme, coz vetsinou z legrace komentuju slovy “cum mi na ruce at neumres blbej!”.
O XP jsem neco cetl a snazil jsem se do nej nejak proniknout, resp. pouzivat na ruzne – mensi (rozumnej skolni) projekty, ale vzdy jsem narazil na zasadni problem s testovanim. Je “snadne” testovat veci typu odebrani a pridani do kolekce, ale co dal a jak testovat nejake vetsi logicke celky – resp. slozitejsi metody. Tusim ze odpoved bude rozpadnout metodu do vice mensich a testovat ty male – duvody – znovupouzitelnost, udrzba apod. Ale ve chvili kdy mam nejaky system hotovy a nemam k nemu testy a chci zacit s refaktoringem tak to musim udelat “natvrdo” a bez testu, nebo lze nejak testovat neco vice nez je v kolekci nebo rovna se necemu?
To Vlasta: v ramci XP se pouziva napr. JUnit, ktery skutecne vyuziva aserci ohledne dat(rovna se, je null, je true) apod. Chovani metod postupne invokovanych v ramci jednoho pripadu uziti (UC) je ruzne. Muze to byt manipulace s daty, vypis na obrazovku, vzdalena invokace ci zmena UI apod. Na jednotlive druhy testu si pak muzete zvolit odpovidajici framework tj. JUnit pro testovani vysledku na urovni dat, Cactus pro ulehceni testovani na strane serveru, HTTPUnit pro proklikavani webu ci Mercury LoadRunner pro vsechno(ale ten je za velky penize). Faktem ale je, ze vetsinu zminenych chovani metod (a to i zdanlive slozitejsich) muzes otestovat pomoci JUnit prave pomoci “snadneho” otestovani dat.
Napr. chci pomoci JUnit otestovat, ze moje krasna implementace invokatoru AOP filtru funguje, tak jak ma.
Filtry sdileji stejny kontext, ktery je jim predavan. V ramci JUnit testu pak naimplementuju jednak testovaci filtr,
ktery pri invokaci vlozi do daneho kontextu treba pod klicem “Test1.testInvoke()” hodnotu Boolean.TRUE. No a test muze vypadat:
[java]
public class Test1 extends TestCase {
protected void setUp() {
server.start();
}
public void testInvoke() {
FilterRepository.add(new MyTestFilter());
Invocation inv = server.invoke(“xxx”);
assetNotNull(inv.getContext().getProperty(“Test1.testInvoke()”));
}
public void tearDown {
server.stop();
}
}
[/java]
Pozn: Kdybych ten kontext nemel k dispozici, muzu si ho vytvorit sam pro ucely testu – napr. nad dbazi, souborem atd.
Napis konkretni pripad, kdy jsi si nebyl jisty ohledne techniky, jak napasovat JUnit.
Pingback: texas holdem