{"id":1296,"date":"2011-03-15T15:10:52","date_gmt":"2011-03-15T14:10:52","guid":{"rendered":"http:\/\/blog.websupport.sk\/?p=1296"},"modified":"2025-03-11T21:06:09","modified_gmt":"2025-03-11T20:06:09","slug":"ws-agilne-extremne-programovanie-xp","status":"publish","type":"post","link":"https:\/\/www.websupport.sk\/blog\/2011\/03\/ws-agilne-extremne-programovanie-xp\/","title":{"rendered":"WS Agilne: Extr\u00e9mne Programovanie (XP)"},"content":{"rendered":"Doba \u010d\u00edtania:<\/b><\/span> 6<\/span> min.<\/span><\/span>

V predch\u00e1dzaj\u00facej \u010dasti sme si nie\u010do povedali o agiln\u00fdch metodik\u00e1ch ako celku: \u010do maj\u00fa spolo\u010dn\u00e9 a na ak\u00fdch princ\u00edpoch stoja. V tejto \u010dasti sa bli\u017e\u0161ie pozrieme na princ\u00edpy Extr\u00e9mneho programovania.<\/p>\n


\nT\u00fato metodiku zaviedol\u00a0Kent Beck<\/a>, po prv\u00fdkr\u00e1t bola pou\u017eit\u00e1 v roku 1996. Jej z\u00e1kladom je jednoduch\u00fd, realistick\u00fd sp\u00f4sob myslenia, pou\u017e\u00edvanie pomerne \u0161tandardn\u00fdch princ\u00edpov a postupov, ako p\u00edsanie k\u00f3du, testovanie, at\u010f. \u010co je na tom extr\u00e9mne? My\u0161lienky dotiahnut\u00e9 do extr\u00e9mov. V\u010faka tomu je mo\u017en\u00e9 dosiahnu\u0165 vy\u0161\u0161iu kvalitu a pru\u017enej\u0161ie reagova\u0165 na zmeny klientov\u00fdch po\u017eiadaviek po\u010das v\u00fdvoja. Mana\u017e\u00e9ri, z\u00e1kazn\u00edci aj developeri tvoria jeden t\u00edm. Ten sa samoorganizuje \u00a0tak, aby bolo vyrie\u0161enie probl\u00e9mov \u010do najefekt\u00edvnej\u0161ie.\u00a0Pozrime sa na z\u00e1kladn\u00e9 pravidl\u00e1.<\/p>\n

Pl\u00e1novanie<\/h4>\n

Z\u00e1kladn\u00e9 po\u017eiadavky s\u00fa sp\u00edsan\u00e9 do celkov (User stories)<\/strong>, ktor\u00e9 je mo\u017en\u00e9 odhadn\u00fa\u0165 a zaradi\u0165 do iter\u00e1ci\u00ed<\/strong>. Je to v podstate ekvivalent rozsiahlych dokumentov s rozobrat\u00fdmi po\u017eiadavkami. Ka\u017ed\u00e1 story je definovan\u00e1 tak, aby bolo jasn\u00e9, \u00a0\u010do v sebe zah\u0155\u0148a. Nedostato\u010dn\u00e9 pochopenie by mohlo sp\u00f4sobi\u0165 chybu v odhade. Je d\u00f4le\u017eit\u00e9, aby sa ka\u017ed\u00e1 story zameriavala na to, \u010do klient potrebuje, bez zbyto\u010dn\u00fdch detailov pou\u017eit\u00fdch technol\u00f3gi\u00ed.\u00a0S user stories priamo s\u00favis\u00ed vznik\u00a0akcepta\u010dn\u00fdch testov<\/strong>. Sl\u00fa\u017eia na overenie \u010di bola dan\u00e1 po\u017eiadavka implementovan\u00e1 pod\u013ea predst\u00e1v. Jedn\u00fdm zo zn\u00e1mej\u0161\u00edch testovac\u00edch frameworkov je\u00a0Selenium<\/a>.<\/p>\n

\"Comic<\/a><\/p>\n

 <\/p>\n

Aj\u00a0v\u00fdvoj je rozdelen\u00fd do iter\u00e1ci\u00ed, av\u0161ak nie je presne definovan\u00e1 ich ve\u013ekos\u0165. Prisp\u00f4sobuje sa po\u017eiadavk\u00e1m klienta a \u010dasto s\u00fa extr\u00e9mne kr\u00e1tke. D\u00f4le\u017eit\u00e9 je \u010dast\u00e9 vyd\u00e1vanie releasov s novou funkcionalitou.<\/p>\n

Mana\u017eovanie<\/h4>\n

Medzi najd\u00f4le\u017eitej\u0161ie pravidl\u00e1 mana\u017eovania patr\u00ed napl\u00e1novanie iter\u00e1cie tak, aby bol t\u00edm schopn\u00fd implementova\u0165 v\u0161etky napl\u00e1novan\u00e9 story. Pr\u00edli\u0161 ve\u013ea nad\u010dasov dlhodobo zni\u017euje jeho v\u00fdkon.\u00a0Okrem toho treba nepretr\u017eite sledova\u0165 postup pr\u00e1c, eliminova\u0165 rizik\u00e1 a v pr\u00edpadne nutnosti prekonzultova\u0165 s klientom prelo\u017eenie menej prioritn\u00fdch stories do \u010fal\u0161ej iter\u00e1cie.<\/p>\n

In\u00fdm d\u00f4le\u017eit\u00fdm princ\u00edpom je zastupite\u013enos\u0165<\/strong>. \u010clenovia t\u00edmu by sa mali pri implement\u00e1cii po\u017eiadaviek do jednotliv\u00fdch \u010dast\u00ed projektu strieda\u0165. Nem\u00f4\u017ee nasta\u0165 situ\u00e1cia, \u017ee iba jedin\u00fd \u010dlen t\u00edmu bude ma\u0165 preh\u013ead o tom, ako funguje nejak\u00e1 \u010das\u0165 syst\u00e9mu. Pri pl\u00e1novan\u00ed je tak\u00fdto pr\u00edstup\u00a0ve\u013ekou v\u00fdhodou.<\/p>\n

Extr\u00e9mnemu programovaniu treba prisp\u00f4sobi\u0165 aj pracovn\u00e9 prostredie. Zariadenie by malo zoh\u013ead\u0148ova\u0165 neust\u00e1lu komunik\u00e1ciu. Ide\u00e1lny je openspace s tabu\u013eami na r\u00f4zne n\u00e1\u010drty a zoznamom \u00faloh, ktor\u00e9 treba spravi\u0165.<\/p>\n

\u010cast\u00fdm probl\u00e9mom vo firm\u00e1ch b\u00fdvaj\u00fa dlh\u00e9 meetingy, ktor\u00e9 treba pl\u00e1nova\u0165 dopredu. Extr\u00e9mne programovanie vyu\u017e\u00edva, tak ako \u010fal\u0161ie agiln\u00e9 metodiky,\u00a0stand up meetings<\/strong>. B\u00fdvaj\u00fa zvy\u010dajne r\u00e1no. T\u00edm na nich stru\u010dne poinformuje a vykomunikuje probl\u00e9my a ich rie\u0161enia. R\u00fdchle meetingy pom\u00e1haj\u00fa udr\u017ea\u0165 t\u00edm s\u00fastreden\u00fd. Je d\u00f4le\u017eit\u00e9, aby sa pri stand up meetingoch st\u00e1lo. Podporuje to efekt\u00edvne a r\u00fdchle vyjadrovanie.<\/p>\n

Ka\u017ed\u00fd \u010dlen t\u00edmu mus\u00ed presne vedie\u0165, \u010do m\u00f4\u017ee o\u010dak\u00e1va\u0165 od ostatn\u00fdch. Pom\u00e1haj\u00fa tomu z\u00e1kladn\u00e9 hodnoty a pravidl\u00e1 Extr\u00e9mneho programovania. Pokia\u013e niektor\u00e9 z t\u00fdchto pravidiel nefunguj\u00fa, treba ich upravova\u0165 a zlep\u0161ova\u0165 na pravideln\u00fdch retrospekt\u00edvnych meetingoch<\/strong>.<\/p>\n

Architekt\u00fara<\/h4>\n

Z\u00e1kladom je jednoduchos\u0165<\/strong>. Implement\u00e1cia jednoduch\u0161ieho dizajnu je v\u017edy krat\u0161ia ako implement\u00e1cia komplexnej\u0161ieho.<\/p>\n

Extr\u00e9mne programovanie vyu\u017e\u00edva takzvan\u00fa syst\u00e9mov\u00fa metaforu<\/strong>. Je to metafora pre jednoduch\u00fa architekt\u00faru s nieko\u013ek\u00fdmi kvalitami. Jedna z najd\u00f4le\u017eitej\u0161\u00edch je jej \u013eahk\u00e1 vysvetlite\u013enos\u0165, bez spisovania rozsiahlych dokumentov. \u010eal\u0161ia kvalita je konzistentnos\u0165 ozna\u010dovania tried a met\u00f3d. Dobr\u00e9 n\u00e1zvoslovie v\u00fdznamne pom\u00e1ha lep\u0161iemu porozumeniu celkovej architekt\u00fary.<\/p>\n

Je d\u00f4le\u017eit\u00e9 \u00a0implementova\u0165 len funkcionalitu, ktor\u00e1 je nevyhnutn\u00e1 a klient ju po\u017eaduje. Netreba zab\u00fada\u0165 ani na neust\u00e1le refaktorovanie<\/strong> k\u00f3du. V mnoh\u00fdch pr\u00edpadoch je efekt\u00edvne pou\u017ei\u0165 aj \u00a0Spike rie\u0161enia<\/a>. S\u00fa to jednoduch\u00e9 experimenty, ktor\u00e9 sl\u00fa\u017eia na r\u00fdchlej\u0161ie vyrie\u0161enie probl\u00e9mov. V podstate ide o k\u00fasky k\u00f3dov alebo programov, ktor\u00e9 je mo\u017en\u00e9 vo v\u00e4\u010d\u0161ine pr\u00edpadov po odhalen\u00ed chyby zahodi\u0165. \u010casto sa pou\u017e\u00edvaj\u00fa na brainstormovanie OOP aplik\u00e1ci\u00ed aj CRC karty<\/a>.<\/em><\/p>\n

Programovanie<\/h4>\n

Ke\u010f\u017ee program\u00e1tori nemaj\u00fa k dispoz\u00edcii kompletn\u00fa \u0161pecifik\u00e1ciu aplik\u00e1cie, je nevyhnutn\u00e9, aby bol z\u00e1kazn\u00edk neust\u00e1le dostupn\u00fd na prediskutovanie pr\u00edpadn\u00fdch nezrovnalost\u00ed. Spolupracuje s t\u00edmom na vytv\u00e1ran\u00ed stories a odhadov a ur\u010duje ich prioritu.<\/p>\n

Ka\u017ed\u00fd jeden k\u00fasok k\u00f3du, ktor\u00fd ide do produkcie sa programuje v p\u00e1roch. Pair programming<\/strong> je met\u00f3da, pri ktorej sedia dvaja program\u00e1tori za jedn\u00fdm PC. Sk\u00fasenos\u0165 hovor\u00ed, \u017ee pokia\u013e p\u00e1r prekon\u00e1 ist\u00e9 soci\u00e1lne z\u00e1brany a program\u00e1tori si uvedomia svoju rovnocennos\u0165, dok\u00e1\u017eu\u00a0za rovnak\u00fd \u010das implementova\u0165 \u00a0to\u013eko isto funkcionality, ako keby pracovali osve. Pridan\u00e1 hodnota spo\u010d\u00edva v \u00a0kvalitnej\u0161om k\u00f3de a omnoho men\u0161ej chybovosti.<\/p>\n

Extr\u00e9mne programovanie vyu\u017e\u00edva aj princ\u00edpy Test driven developmentu<\/strong>. Pred vytvoren\u00edm hocijakej funkcionality mus\u00ed by\u0165 najsk\u00f4r nap\u00edsan\u00fd jednotkov\u00fd test (unit test<\/strong>). V\u00a0pr\u00edpade pou\u017eitia PHP je mo\u017en\u00e9 pou\u017ei\u0165 PHPUnit<\/a> framework. Podobn\u00e9 testovacie frameworky s\u00fa dostupn\u00e9 aj pre in\u00e9 jazyky<\/a>. P\u00edsanie testov pred funkcionalitou n\u00fati program\u00e1torov implementovan\u00fa funkcionalitu podrobne rozanalyzova\u0165. Pozeraj\u00fa sa na nov\u00fa funkcionalitu ako na \u010diernu skrinku, o ktorej vedia, ak\u00fd bude ma\u0165 vstup a ak\u00fd v\u00fdstup. Musia nap\u00edsa\u0165 test, ktor\u00fd pre v\u0161etky mo\u017en\u00e9 vstupy otestuje spr\u00e1vny v\u00fdstup. Ke\u010f\u017ee testujeme funkcionalitu, ktor\u00e1 e\u0161te neexistuje, testy musia failova\u0165. Postupn\u00fdm implementovan\u00edm funkcionality by mali testy prech\u00e1dza\u0165. Nesmie sa vyda\u0165 nov\u00fd release bez toho, aby niektor\u00fd z testov nepre\u0161iel.<\/p>\n

Releasovanie hotovej funkcionality uskuto\u010d\u0148uje v\u017edy iba jeden p\u00e1r. Ide\u00e1lne je ma\u0165 na releasovanie vyhraden\u00fd jeden po\u010d\u00edta\u010d, aby aj ostatn\u00ed videli, kedy je obsaden\u00fd a releasuje sa.<\/p>\n

Zdrojov\u00fd k\u00f3d je vlastn\u00edctvom cel\u00e9ho t\u00edmu. Znamen\u00e1 to, \u017ee ka\u017ed\u00fd m\u00f4\u017ee robi\u0165 zmeny v celom projekte, ako opravova\u0165 chyby, tak aj prid\u00e1va\u0165 nov\u00fa funkcionalitu.<\/p>\n

Testovanie<\/h4>\n

Testova\u0165 treba v\u0161etko, neust\u00e1le a v\u017edy. P\u00edsanie unit testov r\u00fdchlej\u0161ie pom\u00e1ha odha\u013eova\u0165 chyby aj nesk\u00f4r po\u010das v\u00fdvoja. Tak isto sa p\u00ed\u0161u unit testy aj na chyby. Okrem unit testov sa pravda\u017ee sp\u00fa\u0161\u0165aj\u00fa aj akcepta\u010dn\u00e9 testy na ka\u017ed\u00fa story a zapisuj\u00fa sa ich v\u00fdsledky. Story nie je dokon\u010den\u00e1 pokia\u013e neprejde v\u0161etk\u00fdmi akcepta\u010dn\u00fdmi testami.<\/p>\n

 <\/p>\n

\"\"<\/p>\n

 <\/p>\n

Z\u00e1kladn\u00e9 hodnoty extr\u00e9mneho programovania:<\/p>\n