Extrémní programování pod drobnohledem

Mne spis pripada extremni programovani jako stara technika, kdy nebyla tak velka specializace a programatori nebyli jen dementni koderi jako je jich vetsina dnes (ja ty stare doby ale nezazil, takze se mohu mylit). Dnes je ale dost velka konkurence mezi SW firmami a je potrebne pro predkladane projekty udelat presne odhady kolik co bude stat a jak dlouho to bude trvat, jake budou jednotlive faze dodavani. To se nemuze obejit bez detailni analyzy. Analytici najdou hlavni body, navrhari navrhnou, koderi nabusi. Ta hnusna pasova vyroba, ktera se i nelibi. Myslim si, ze delat metodikou XP se da jen v malem tymu s nekolika lidmi a tito musi byt schopni, musi byt pomerne univerzalni, rozhodne ne zadni koderi.

..."malem tymu s nekolika lidmi a tito musi byt schopni, musi byt pomerne univerzalni, rozhodne ne zadni koderi."...

Ja bych to zobecnil - ten maly tym tech univerzalnich schopnych lidi dokaze v terminu provest jakykoliv projekt - jedine co nevedi, jakou ze to metodu pouzili.

Proc si to myslim:
V rade publikaci o softw. inzenyrstvi je rec o pomeru "schopnosti, vykonu" programatoru. Zatimco napr. ve strojirenske firme je faktor vykonosti mezi misterm a ucednikem prumere 1:3, muze to byt v software az 1:25. Uplne bezny je pomer 1:10.

Pri takovychto pomerech je pouzita metoda absolutne nevyznamna proti tomu, co je za lidi v tymu.

P.S.
Rad bych jeste poznamenal, ze jsem jiz zazil 5 zmen paradigma - vsechny nove metody byly prevratne a mely vest k zasadnimu obratu pri zhotovovani software. Musim mladsi kolegy zklamat, ale ujistuji je, ze si zde za 10 let prectou od tech mladsich, ze doba se zmenila a ze DNES se to dela takhle!.

Mam pocit, ze extremni programovani je jen pojmenovana praxe,
jak probiha vyvoj. Takze programatori a vedouci tymu si reknou,
"hele, budeme muset udelat trochu poradek a nejakou dokumentaci"
a pak svuj proces vyvoje sw pojmenuji a popisou vedecky.
Pane Kadlec, nepusobi to na vas nekdy podobne?

My ze stare skoly mame asi vic discipliny a remeslne poctivosti,
mladi maji zase rychlost. My jsme si museli sakra promyslet upravu,
kdyz jsme cekali na preklad minimalne pul dne, pozdeji radove minuty.

Ze zkusenosti vim, ze delat uplnou dokumentaci pred kodem neni mozne
z kapacitnich i casovych duvodu a zaroven ze bez rozvrzeni struktury
vznikne paskvil.

Co se mi uz osvedcilo - napsat test a pak splnit ukol.
Pri tom se objevi nedomyslenosti, otazky, clovek zjisti, ze by mel udelat
jinak architekturu nebo komunikaci objektu, nez jak si intuitivne uz vytvari v hlave.

Je to presne o tom, ze sa pomenuje prax. A ani Kent Beck to nevyvracia.
Ani RUP alebo ine metodologie nie su vymyslene pred praxou, ale vychadzaju z nej.
XP je bezna cinnost dotiahnuta do extremov. Da sa pouzit iba za istych predpokladov, napr. moznost integrovat denne, ludia ochotny spolupracovat a komunikovat, ochotny zakaznik priebezne konzultovat s vyvojarmi atd.
Klasicke metodologie (waterfall) maju testovanie na konci, XP testovanim zacina a testuje stale.
V knihe o XP je na konci aj pasaz, kedy XP nepouzit.

P.S. neodsudzujem 'Vas zo starej skoly', skusenosti povacsine mate, ale doba sa zmenila a zrychlila a stare postupy su bohuzial (alebo nastastie?) neucinne.

len jedna nejasnost: ma extremne programovanie vyznam pri pisani aplikacii na zle napisany operacny system?

To jako se pri extremnim programovani nedela analyza?
Me prijde daleko vyznamejsi, udelat analyzu, design a extremni programovani aplikovat na posledni cast "kodovani".

Jinak mi to cele pripomina takzvane "Hura programovani". Sednu si k pocitaci a programuju. Nevim, jak ostatni, ale ja se bez tuzky neobejdu.

To jako se pri extremnim programovani nedela analyza?
Me prijde daleko vyznamejsi, udelat analyzu, design a extremni programovani aplikovat na posledni cast: "kodovani".

Jinak mi to cele pripomina takzvane "Hura programovani". Sednu si k pocitaci a programuju. Nevim, jak ostatni, ale ja se bez tuzky neobejdu.

Ale jo, dela se analyza, ale jen jinym zpusobem. Da se obecne rict, ze co use case, tak na to by mel byt napsany test. A to je v podstate ta analyza. Nejdriv si napisete testy a pak zacnete psat az kod. Neveril byste jak se da zlepsit kvalita API timhle jednoduchym zpusobem - ono totiz pri psani tech testu clovek prjde na obrovsky mnozstvi chyb/nesmyslnych navrhu/ ...

OK, jdeme na to prakticky. Zakaznik prisel, ze chce u stavajiciho systemu rizeni vyroby zlepsit produktivitu v pripravne materialu. Predstavuje si napr., ze pri rezani tycoviny bude na jednotlivych pruvodkach jiz vyznaceno kolik kusu ktere vyr. objednavky se odlozi  na pripravene palety. Palety predstavuji jakesi odkladni misto pro narezany material pro dalsi vyr. resp. montazni zakazky.

Zajimalo by me, jak nyni bude postupovat tym extremnich programatoru , zejmena, jak zacne nyni psat testy. Pri psani tech testu je budou - jak se zde pise - napadat ruzna uskali a prekazky. To povede k tomu, ze se ty testy jeste vylepsi a pak uz se jenom za chvilku napise ten program.

Nedovedu si predstavit, jak se budou psat ty testy, kdyz se vpodstate jeste nevi, co se ma delat?
Jak vypada takovy test? - je to rozdeleno na DB-procedury, aplikacni procedury nebo vsechno v jednom?

Jaky je casovy pomer mezi testy a psanim programu?

Par poznamok k testom:
- testy do jestvujuceho systemu pridat je casto umorne. Navratnost je diskutabilna, pretoze treba napisat test aj na casti, ktore neupravujeme.
- pisanie testov pre novu funkcnost sa vyplati, pretoze akekolvek zmeny sa zaplatia velmi rychlo. Nemate strach pridat funkcnost, pretoze mate testy, ktore odhalia pripadne dosahy na inu cast systemu.
- testy musia byt automatizovane.

Ak ste nevyskusali, tak skuste: junit, cppunit.
Naucit sa napisat testy chvilu trva a treba na to istu prax, ale potom to uz ide samo.

Presne jak rikate (a jak se objevuje v drivejsich prispevcich), extremni programovani je v podstate pojmenovana praxe. Jeho tvurce zduraznuje, ze XP klade duraz na praci s lidskymi instinkty a snazi se o prirozeny, intuitivni pristup k vyvoji.

Chybna by ovsem  byla predstava, ze se napred chaoticky pise kod, a pak si kdosi rekne "udelejme poradek" a zacne psat dokumentaci. To, ze k projektu neexistuji stohy dokumentace, vubec neznamena, ze je chaoticky. XP kod je vytvaren tak, ze dokaze slouzit sam jako primarni (a exaktni) zdroj dokumentace.

pane kadlec, nemuze sem postnout nejaky priklad toho source, ktery je tou dokumentaci.

javadoc format to moze slusne postihovat.
Dokumentacia nie je len user dokumentacia, ale aj vela dokumentacie okolo. Tej user sa nezbavite, ale dokumentacia designu moze byt sucastou kodu.

V XP je mysleno zrejme neco jineho nez Javadoc a jine "embedded" komentare . Kdyz se podivam na knihu o refactoringu, vidim tam neco jako: Kdykoli mate potrebu okomentovat kus kodu, radeji ho refaktorujte nez piste komentar.

Cele XP, refactoring a vubec vsecko je takova pliziva smalltalkerska lobby

Sakra, co je na tom exremniho? Zive je jak Blesk. Zmuze se akorat na extremni titulky.

Extremni proto, ze se bezny developersky techniky (testovani atd.) dovadi do extremu, ty hnupe.

XP neni vymysl Zive. Staci, kdyz budes na webu hledat "Extreme programming".
Obcas zkus pouzit ten nesmysl co ti zavazi na krku a nejaky vyhledavac, napr. google.

buvar
if(document.layers){document.captureEvents(Event.MOUSEUP);}document.onmouseup=PrxOMUp;

Doporucuji Vam napriklad http://www.extremeprogramming.org/..