Umějí Češi programovat extrémně?

Diskuze čtenářů k článku

Barbar  |  15. 07. 2003 06:25  | 

Hmmm... no jenom ten herák neprodávejte dál... a pokud na tom zapracovala tráva, tak byste to neměl tak přehánět...

btw: Nechápu, co tady ten článek vůbec dělá... no asi si redakce zive, někdy dá ráda pořádnýho práska!! :D

Souhlasím  |  Nesouhlasím  |  Odpovědět
XX  |  15. 07. 2003 09:45  | 

kvoli tomu ze si blbec a clanku vobec nerozumies, zato este nemusi byt ten clanok zly ....

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Barbar  |  15. 07. 2003 17:06  | 

to XX: Já článku rozumím... a právě proto říkám, že takovej článek bych sem já rozhodně nedal... bohužel kvalitních serverů o IT v našich končinách moc není... protože asi autoři nemají o čem psát, tak píšou o "hovně" a zabývají se dávno mrtvýma věcma... nebo kravinama!! (viz články typu: "Jak na windows update" a podobný hovadiny...) už se jenom těším až se tady objeví článek "Poznámkový blok pro začátečníky..." nebo "Jak si ve windows nastavit pozadí..."

Docela kvalitní články má lupa, i když někdy to koníjou taky taky (viz 50 článků na jedno téma...)... Pokud by mi někdo argumentoval, že když jsem tak chytrej ať si to zkusím sám... tak na to můžu říct jen, že já nikoho nenutil dělat časák o IT - to si autoři vybrali sami... a co si člověk vybere, že bude dělat, tak to ale musí dělat pořádně... a ne takhle "prdsky"... článek sám o sobě není špatný, ale prostě jenom podle mě sem nepatří... (taky když jdete do dětského kina a promítali by tam najednou horory s tím, že to jsou ale ty nejkvalitnější od nejlepších režisérů, tak by se vám to asi nelíbilo... - i když film sám o sobě špatný není...) Takže závěrem: článek není špatný, ale blbě umístěný!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
honza  |  26. 07. 2006 09:30  | 

mozna si blbe umisteny ty.

Souhlasím  |  Nesouhlasím  |  Odpovědět
PEpa  |  15. 07. 2003 06:56  | 

Ja myslim, ze cesi XP zvladli uz davno. Jen se jim uz nechce vyhazovat hotovou praci a podle toho to vypada

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  15. 07. 2003 08:18  | 

Presne tak Take mam zkusenosti s tim, ze kdyz se neco dela "aby to rychle bylo" tak se vetsinou driv nebo pozdeji prijde na to, ze je to potreba predelat (a to dost casto jeste pred tim, nez je to nasazeno do provozu). Nevim, mozna americanum nevadi, ze neco udelaji a pak se to vyhodi a oni to musi predelavat, ale v cechach proste pokud udelam neco co je k nepotrebe, udelal jsem spatnou praci. (Nejde o to "zkusit" ja casto pri reseni problemu zkousim ruzne postupy az prijdu na ten spravny. Jde o to, ze clovek udela praci ktera je k nicemu.)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  17. 07. 2003 02:36  | 

Ano, je to přesně tak, jak píšete. Američanům vůbec nevadí, když něco udělají špatně - prostě se usmějí, zahodí to a jedou dál. Je to hodně o sebevědomí - nepřipustí si, že by mohli nakonec neuspět a chybu berou jen jako nevyhnutelnou část cesty k cíli.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Klimovic  |  23. 07. 2003 09:37  | 

Kdyz Edison hledal vhodny material na vlakno zarovky, vyzkousel udajne pres 600 ruznych materialu, nez objevil uhlikove vlakno. Kdyz se ho ptali, jestli nelituje te zbytecne namahy, odpovedel: Jaka zbytecna namaha? Byl to proste proces, ktery ke svemu ukonceni vyzadoval 600 kroku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
M.Novak  |  15. 07. 2003 06:59  | 

O tzv. extrémním programování se už na Živě asi psalo (i když připouštím, že to mohlo být na jiném podobném serveru), nicméně k tématu - XP je opravdu fajn - rychlé, k cíli, ale nikdy nechtějte žádnou úpravu, změnu apod. a už vůbec ne po uplynutí víc jak 1/4 či 1/2 roku. Je možná příjemné mít aplikaci napsanou za den/týden/měsíc, ale výsledek podle toho vypadá. Sám se programováním živím a XP používám jen pro své interní potřeby a pouze pokud není zbytí, protože je to jen časovaná bomba, která se vymstí v tu nejnevhodnější chvíli. Nicméně "konkurenci" XP programování neberu (zvláště když je tvoří rychlokvašení rádobyprogramátoři - obvyklé je to u Internetu - 14ti denní rychlokurz PHP a MySQL a hurá prát "profi" weby) a jsem rád, že je k tomu někdo (Žive) ponouká, alespoň bude posléze větší počet potenciálních zákazníků, kteří uznají, že potřebují pořádné aplikace navržené na základě skutečné analýzy a rozboru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr P.  |  15. 07. 2003 09:07  | 

Jak jste psal o té časované bombě která se vymstí v tu nejnevhodnější chvíli - tady podle metodiky XP stačí implementovat opravu a máte zase celek který Vám funguje. Navíc kdyby jste měl vytvořený dobrý testovací framework, tak na tu chybu přijdete ještě než kód předáte zákazníkovi a můžete chybu odstranit během 10 minut a nestrávit potom zbytečných 10 hodin telefonováním, cestováním, konzultováním a vysedáváním na poradách kvůli téhle jedné záležitosti. Proto jsou také u XP klíčové zkušenosti a intuice programátora.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 09:29  | 

Jinak řečeno, XP je o tom, udělejte to, jak to chcete, jen ať je to rychle hotovo. Já si všímám, že pokud má XP metodologie s něčím potíže, zdůvodní to typicky politicky korektně: Je potřeba intuice, zkušenosti, není sehrátý tým na XP metodologii. Já mám pocit, že XP je prostě chaos, který je realizovatelný pouze v malých týmech, a který v podstatě říká nějak to udělejte, a sledujte, kde hoří průšvih, a něco s tím dělejte. V zásadě jde o to, že XP metodologie se snaží posílit všechno, co může dát jakýkoli signál, že něco závání průšvihem, ale při řešení se opírá o zkušenosti, o intuici programátora, o sladěnost týmu, apod.. To je tak trochu jakési alibi, které XP metodologie má, a ke kterému patří i zdůrazňování testů. Problém, že otestovat nelze vše XP metodologie nijak dále nerozvádí.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr P.  |  15. 07. 2003 10:07  | 

Ale o to právě jde, rychlost implementace. Ta je klíčová. 1. čas programátorů je drahý a 2. zákázník řešení ve velké většině případů potřebuje ihned. XP se snaží chaos o kterém píšete usměrnit správným směrem a profitovat z něj. Co se týče velikosti týmů, Česká republika není místo, kde by někdo chtěl financovat megaprojekty, na to je zdejší trh moc malý. A to platí i o západních firmách které zde outsourceují. No a nakonec nikdo netvrdí že analytik z "klasických projektů" nemůže být tahounem týmu a taky se trošku zapojit do programování.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 11:35  | 

V tom se právě zásadně mýlíte - přístup "udělejte to, jak to chcete, jen ať je to rychle hotovo" je přísně zapovězen. Musíte důsledně dodržovat všechna stanovená pravidla a nevynechat žádnou součást XP. Vytvářený kód musí být jednoduchý, přehledný, snadno čitelný a přiměřeně komentovaný. V žádném případě nejde o chaos, to jste XP nepochopil správně. Průšvihy se samozřejmě hlídají, ale to neznamená, že jich musí vznikat více, než při užití klasického vývojového cyklu. A zkušenosti, intuci a sladěný tým potřebujete také vždy. Fakt že nelze otestovat vše beru, ale to stejné platí i pro jakýkoliv jiný model vývoje. Požadovanou funkcionalitu jednotlivých částí však otestovat LZE (neboť ta je definována právě svými testy) a chyby v zadání jsou efektivně eliminovány krátkými iteracemi vývojového cyklu (zde je samozřejmě vyžadovván aktivní přístup zákazníka, bez kterého XP nemá smysl).

Osobně mám s XP velmi dobré zkušenosti a velmi příjemně mne překvapil rychlostí i kvalitou vývoje. A výsledné produkty bývají díky dodržení přísných pravidel XP skutečně kvalitní.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 13:33  | 

Moje odpověď je taková, že hlavní problém je, jak programátory přepnout do jiného režimu a vyhodit je ze zaběhaných otáček a postupů. XP k tomu nijak nepřispívá, protože je spíše abstraktním návodem. Prostě programátorům namísto přemýšlejte trochu dál, než je pár klíčových slov se řekne přemýšlejte metodou XP. Je to asi to samé, když někomu namísto "přestaň žvanit" řeknu "přestaň produkovat mentální emise". To druhé zní vznešeněji a je to jedno a to samé. Prostě XP je jen a pouze vzletný název pro programování s dosahem na praktické použití produktu, nikoli na teoretickou čistotu, která bude hotova až zákazníkovi vystaví parte.

Všimněte si, že metodologie XP je silně nekonkrétní, viz třeba Vaše slova: Kód musí být čistý, snadno čitelný a přiměřeně komentovaný. Klade se důraz na intuici a zkušenosti. Dělají se testy. V zásadě je to takový apel bez nějakého rozvádění konkrétností.

Můj názor je ten, že XP je jen vzletný název pro to, aby programátoři shlédli od počítačů dále směrem k zákazníkovi. Nic konkrétnější XP metodologie neobsahuje, a IMHO celé XP je možné shrnout do mnou napsané předchozí věty. Ale pravda, marketinkově to tak nezní.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 22:08  | 

Ano, nyní je zcela zřejmé, že jste principy XP vůbec nepochopil. XP není vznešený název pro neřízené bastlení kódu bez jakékoliv analýzy a návrhu, ale jde o kvalitní metodiku vývoje pro určitý typ projektů se solidním teoretickým základem, která byla navržena uznávanými odborníky v oblasti SW inženýrství. A dle mých zkušeností bývá většinou výsledkem produkt, který je ve srovnání s klasickými metodami vývoje kvalitnějsí, a to jak po stránce analytické, tak i v oblasti návrhu i vlastní implementace.

Co se týče nekonkrétnosti - co očekáváte od jednoho článku, který popisuje pouze základní principy metodologie? Co očekáváte od jednoho příspěvku v diskusi? Že budou podrobně rozvádět všechny aspekty a detaily extrémního programování? Pokud Vás zajímají KONKRÉTNÍ postupy a informace, nejdříve si přečtěte Extreme programming od Kenta Becka (vyšlo i v češtině u Grady) a pak pokračujte na stránkách http://www.xprogramming.com a http://www.extremeprogramming.org. Zjistíte, že je XP velmi konkrétní a s úspěchem použitelné.

Můj názor je ten, že XP je jen vzletný název pro to, aby programátoři shlédli od počítačů dále směrem k zákazníkovi.
Nic konkrétnější XP metodologie neobsahuje, a IMHO celé XP je možné shrnout do mnou napsané předchozí věty

Váš názor pramení z naprostého nepochopení základního paradigmatu extrémního programování. Orientace na zákazníka je důležitou součástí XP, ale nikoliv jedinou, je jich mnohem více (např. párové programování, refaktoring, kvalitní dokumentování kódu, automatizované testování po každé změně, průběžné integrační testy, atd.). A onen Vámi zmiňovaný apel je ve skutečnosti soubor konkrétních pravidel, která se musí důsledně dodržovat. Proto jde o extrémmní programování - všechna pravidla jsou dotažena do extrému a musí se důsledně dodržovat. Jde však o taková pravidla, která důsledně dodržovat lze, a to bez zbytečného úsilí či dalších nákladů (proto je zde např. onen Vámi kritizovaný důraz na kód coby primární dokumentaci).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 22:40  | 

Občas mi přijde, že neumíte číst, a nebo pochopit princip psaného textu je nad Vaše síly. Můžete mi, prosím Vás, ukázat, kde jsem psal, že XP je neřízené bastlení kódu bez jakékoli analýzy a návrhu? Všimněte si také, že jsem nikde neudělal žádný závěr o neúspěšnosti této metodologie.

Metodologii XP považuji za možnost úspěšně realizovat NĚKTERÉ projekty, pokud jsou splněny určité podmínky. Existují situace, pro které bude XP téměř geniální, a situace, kde bude naopak XP selhávat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 23:01  | 

Psal jste v předchozím příspěvku, že "XP je o tom, udělejte to, jak to chcete, jen ať je to rychle hotovo", což ve mne evokuje představu postupu často využívaného některými programátory a který spočívá právě v eliminaci analýzy a návrhu. Poté jste použil příměr

>Je to asi to samé, když někomu namísto "přestaň žvanit" řeknu "přestaň produkovat mentální emise". To druhé zní vznešeněji a je to jedno a to samé.

což vedlo k doměnce, že XP považujete pouze za marketingový pojem pro označení rychlého vývoje aplikací bez ohledu na zvolený postup. Připouštím, že jsem Váš názor nejspíše nepochopil správně, nicméně trvám na tom, že XP rozhodně nelze považovat za abstraktní pojem bez konkrétních postupů a metod (viz zbytek mého předchozího příspěvku).

>Metodologii XP považuji za možnost úspěšně realizovat NĚKTERÉ projekty, pokud jsou splněny určité podmínky. Existují situace, pro které bude XP téměř geniální, a situace, kde bude naopak XP selhávat.

V tom s Vámi naprosto souhlasím (i když se naše názory mohou lišit v definici množiny těchto projektů a podmínek ).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  15. 07. 2003 09:15  | 

rekl bych, velmi rozumny prispevek. Co mi vadi je, ze v zaveru negujete vas nazor tim, ze pozijete ...na základě skutečné analýzy a rozboru.
Toto je prece prave jeden ze zakladnich duvodu, proc se rada lidi  utika k XP, protoze definice pro skutecnou analyzu je jeste mnohem  komplikovanejsi nez pro XP jako celek.
Nebo dokazete  definovat co to je skutecny anylyza a rozbor?

Souhlasím  |  Nesouhlasím  |  Odpovědět
PavelKo  |  15. 07. 2003 09:31  | 

My při vývoji SW používáme něco z metod XP, tedy krom metod pokus & omyl. Snažíme se co nejdříve "vypustit" nějakou pre-verzi, aby zákazník "něco" měl (třebas i jenom funkční přihlašovací dialog). Pak se postupně v dílčích krocích přidávají funkce a moduly, které se průběžně předávají zákazníkovi k odzkoušení a připomínkování. Pochopitelně primární (pouze ale rámcové) testy se provádí během vývoje, nedělá se ale už detailní testování všech možností a možných stavů (uživatel stejně vymyslí ještě deset dalších hrůzných kombinací, které nás nenapadli ani v nejděsivější noční můře).

Z našeho pohledu se nejedná o metodu pokus&omyl (to by nás zákazníci hnali asi vidlemi), ale postupné rozšířování funkčnosti aplikace, etapové implementování funkcí a případně úpravy již hotových funkcí podle připomínek a tužeb zákazníka. Občas to sice vyžaduje přepsání části již hotové práce, ale zase na druhé straně se do kódu obvykle naočkují další vylepšení (zejména pro nás).

Během vývoje (a rozvoje) aplikace zákazník obvykle přichází s novými poznatky (jé, to je pěkné, to jsme netušili, že to jde TAKHLE vyřešit - a nešlo by ještě ...), které na počátku možná ani nevěděl. Navíc zákazník obvykle nemá při zahájení prací 100% jasnou představu o zadání, aby bylo možné zpracovat kompletní a neměnný projekt.

Vývojem aplikací se na profesionální bázi zabývám celkově již přes deset let, jsem tedy ještě ze "staré" školy (důkladné zpracování zadání, vývoj, testování, pak teprve předání zákazníkovi), ale nové metody jsem (dokonce i vnitřně) již plně akceptoval (testováno na lidech .

Myslím si, že náš výrobní postup by se dal nazvat Extrémním Programováním v českých podmínkách.

Občas nás překvapí ohromný projev radosti a uznání u zahraničních zákazníků (zejména s americkým vlastníkem) nad vyřešením každého problému, čili funguje ona americko-dětinská radost nad úspěšně vyřešeným problémem, hlavně pokud před tím bylo x chybných řešení.

Souhlasím  |  Nesouhlasím  |  Odpovědět
freedom  |  15. 07. 2003 09:44  | 

Tak s PavlemKO se stotožňuji.V podstatě pracujeme stejným způsobem.Co nejdříve vypustit nějakou verzi...protože zakazník již při prvním konzultaci s nami "vykřikuje": "už včera bylo pozdě".

A když mu budete potom další 3 měsíce tvrdit, že jste ve fázi návrhu, že potřebujete důkladnou analýzu, tak Vám po měsíci zakazník řekne, no jo, ale my už máme 1.verzi aplikace od někoho jiného...podívejte...a vy se na to podíváte a uvidíte třebas jen zmiňovaný "funkční přihlašovací dialog" a budete se tlouct do hlavy, proč jste to zakazníkovi nepředali také, že ano.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  15. 07. 2003 09:46  | 

ja si pamatuji projekty pred 20 ti lety a mohu potvrdit, ze dochazelo ke stejnym jevum, ktere popisujete:
- zakaznik na zacatku nevedel vsechno a tak se neco udelalo, pricemz se nekdo udelal hruby rozbor
- zakaznik se tesil z nejakeho reseni, keter se predtim nedovedl predstavit
- obcas se neco muselo predelat
- az kdyz aplikace bezela, tak zacal mit zakaznik napady co dal a funkcnost ze zvetsovala.

Uz pred 20 ti lety se hlasalo, ze lide v tymu se musi k sobe hodit, ale vzorecek, jak je najit jeste nikdo nenasel.

Kde je prosim XP?

Souhlasím  |  Nesouhlasím  |  Odpovědět
freedom  |  15. 07. 2003 09:31  | 

Ja bych to s těma úprava neviděl až tak černě.Nelze XP zavrhovat, ze se zrovna Vam nehodí do krámu.Jak je psáno v článku, tak se XP hodi pro mensi teamy.Nas pracuje 5 v tymu a da se rict, ze nezavisle na XP pracujeme podobnym způsobem jak XP definuje (O XP jsem četl poprvé az na ZIVE).Pracujeme na nekolika projektech a zatim se nevyskytl vetsi problem s nejakou upravou a udrzbou pro zakazniky.Ono totiž i zaleží v čem programujete.My děláme v JAVĚ a s XML a tam neni az takový problem pridat nové chování do aplikace, ci upravovat formaty souborů se zachováním předchozí funkčnosti.Uvolnění nových verzí počítáme na dny, maximálně týdny.Samozřejmě před každým novým projektem definujeme podrobně "okolí" aplikace, konzultujeme požadavky zákazníka, navrhujeme řešení,.... což je asi nejdůležitější.

I kdyz neni software 100% otestovan, zakaznik s tim pocita a zatim se nam nestalo, ze by se nejaky projekt vyhodil kvuli tomu, ze zakaznik v nem nasel spoustu chyb, ale dostal aplikaci hotovou za 14 dni.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 11:10  | 

Nejsem si jist, že jste principy XP pochopil správně - je VELKÝ rozdíl mezi tvorbou aplikací živelným způsobem typu <i>sednu k tomu a něco slepím</i> (který se v poslední době velmi často používá zejména u zmiňovaných rychlokvašených programátorů) a přísně řízeným extrémním programováním. Extrémní programování není o tom, že vynechám analýzu a návrh a tvořím aplikaci formou prototypování,to v žádném případě.

Extrémní programování je metodologie, která se snaží umožnit efektivní a rychlou tvorbu aplikací v případech, kdy není možné provést analýzu požadavků a problémové domény hned na počátku vývoje (což je velmi častý jev, neboť zákazník ma málokdy přesnou představu, co vlastně požaduje). Neeliminuje podrobnou analýzu a návrh systému, pouze ji neprovádí na začátku, nýbrž ji rozpouští do celého vývojového cyklu. Klasické metodologie trvají na provedení analýzy a návrhu na počátku vyvojového cyklu, neboť tam jsou jakékoliv změny jednoduché a stojí málo úsilí i zdrojů. V průběhu vývoje pak náklady na změnu stoupají (viz jakýkoliv kurs nebo kniha z oblasti SW inženýrství). Extrémní programování přináší prostředky, jak udržet náklady na změnu na nízké
úrovni a tím se vyhnout nutnosti řešit potenciální problémy zbytečně dopředu. Stejné je to s ostatními součástmi klasického vývojového cyklu - nejsou eliminovány, ale přesunuty. Dokumentace se nevede v externí formě, primární dokumentací je kvalitně zapsaný a přiměřeně komentovaný zdrojový kód apod.

Říkáte, že XP používáte pro své interní potřeby. Mám to chápat tak, že si sednete s nějakým kolegou, programujete v páru, píšete automatizované testy ještě před začátkem vlastní implementace jednotlivých částí, pravidelně provádíte refaktorizaci, intezivně komunikujete se zákazníkem v průběhu vývoje včetně předvádění hotových částí, testujete po každé změně, píšete jednoduchý, kvalitní a přiměřeně komentovaný kód, používáte vhodné technologie a dodržujete všechny ostatní zásady XP? <b>Pokud třeba jen jedinou z těchto zásad nedodržujete, neprogramujete extrémně</b> a neočekávejte slibované přínosy XP.

Extrémní programování není vhodné pro všechny případy a netvrdím, že je použitelné zrovna pro Vaše projekty, ale než jej označíte za nepoužitelné, zkuste si něm přečíst něco více - vřele doporučuji zmiňovanou skvělou knihu od Kenta Becka, jednoho z uznávaných expertů v oblasti softwarového inženýrství a průkopníka XP. Další informace lze nalézt na adresách <A HREF="http://www.xprogramming.com/">http://www.xprogramming.com/</A> a <A HREF="http://www.extremeprogramming.org/">http://www.extremeprogramming.org/</A>.

Extrémní programování klade vyšší nároky na členy vývojového týmu - zátímco u klasického přístupu potřebujete schopné analytiky a průměrné programátory, u XP potřebujete schopné programátory, kteří zvládají analýzu, návrh, implementaci, tvorbu testů atd. Alespoň někteří z nich (minimálně polovina) musí být dostatečně zkušení a hlavně musí být všichni disciplinovaní a přísně dodržovat včechny zásady XP. Živelný způsob vývoje aplikací nezkušenými programátory v PHP rozhodně nelze nazvat extrémním programováním. A hlavně - extrémně <B>nikdy</B> nemůžete programovat sám.

Vývojem aplikací a informačních systémů se živím již více než 10 let a musím konstatovat, že přes moji počáteční nedůvěru v XP se mi tato metodologie velmi osvědčila. Pro tvorbu informačních systémů a webových aplikací středního rozsahu (tj. vývojový tým 2 - 10 lidí) jde o ideální způsob jejich efektivní tvorby.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 13:43  | 

Někdy mám pocit, že i zjišťování, co je vlastně XP se děje metodou XP. Prostě se to vlastně neví a postupně se to doplňuje. Nemám nic proti XP, je to prostě o tom, že pokud máte velký tým, nebo nezkušené lidi (a i Ti mohou být užiteční!) metoda XP je spolehlivá sebevražda. Je to o tom, že kkdyž máte zkušené harcovníky v programování, tak si prostě můžete dovolit porušovat zaběhaná pravdila, protože zkušenost Vám řekne, co se stane, zda to vede k průšvihu, či nikoliv a co to přinese.

Jinak řečeno, přínosy XP jsou pouze pro zkušené. A většinou zkušení již podobně postupují, protože se k tomu dopracovali sami.

Podle mého je prostě XP metoda jen honosný název pro něco, co už dávno přirozeně existuje.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 22:41  | 

>Někdy mám pocit, že i zjišťování, co je vlastně XP se děje metodou XP. Prostě se to vlastně neví a postupně se to doplňuje.

Co je to XP se samozřejmě velmi dobře ví a je to přesně formulováno v publikacích napsaných autory XP. Základních zásad je jenom několik, ale jsou dotaženy do extrému a musí být být důsledně dodržovány. JAK je dodržovat je samozřejmě popsáno také.

>pokud máte velký tým, nebo nezkušené lidi (a i Ti mohou být užiteční!) metoda XP je spolehlivá sebevražda.

Pro velký tým (více než 10 lidí) XP není určeno a také na to upozorňuje každý úvod do XP. Pokud máte v týmu kromě nezkušených i nějaké zkušené (a ti nezkušení mají alespoň určitou úroveň znalostí), není to problém, neboť se vždy programuje v páru a jeden může být méně zkušený než druhý (jde dokonce o efektivní způsob, jak ten nezkušený získá potřebné zkušenosti). Pokud v týmu nemáte dostatek zkušených, nebo ti nezkušení nemají ani základní úroveň znalostí, je sebevraždou vývoj jakéhokoliv systému bez ohledu na použitou metodiku.

>když máte zkušené harcovníky v programování, tak si prostě můžete dovolit porušovat zaběhaná pravdila, protože zkušenost Vám řekne, co se stane, zda to vede k průšvihu, či nikoliv a co to přinese.

To je omyl, v XP NIKDO nesmí porušovat ŽÁDNÁ pravidla. Pro dokonalé programátory, kteří vždy identifikují všechny potenciální problémy vzniklé porušením základních pravidel XP prostě tato metodika není. Pokud jsou v týmu lidé, kteří mají s dodržováním Pravidel problémy, nemá tým šanci v nasazení XP uspět.

>Jinak řečeno, přínosy XP jsou pouze pro zkušené. A většinou zkušení již podobně postupují, protože se k tomu dopracovali sami.
>Podle mého je prostě XP metoda jen honosný název pro něco, co už dávno přirozeně existuje.

Nikoliv, v tom se mýlíte. Je pravda, že již delší dobu existují všechny postupy, využívané v XP (a mnoho zkušených programátorů tyto postupy využívá). Ale XP tyto postupy kombinuje s určitým cílem za určitých podmínek, dotahuje je až do extrému a důsledně trvá na jejich doržování. Považuji se za zkušeného vývojáře a znám i mnoho dalších zkušených vývojářů (mnozí z nich jsou podstatně zkušenějsí než já), a ačkoliv většina z nás tyto postupy zná, nikdo je nepoužíval v této kombinaci, takovýmto způsobem a s tímto cílem. XP spočívá v tom, že vám něco slibuje, když dodržíte daná pravidla.

Pokud bych měl shrnout přínos XP, tak ten spočívá v možnosti efektivního a rychlého vývoje kvalitních aplikací v prostředí, kde se velmi často mění zadání (je to ideální metodika např. pro tvorbu složitějších webových aplikací). Pokud máte k dispozici podrobné zadání na počátku vývoje, závidím Vám Vaši pozici a Vaše schopnosti, a samozřejmě žádné XP nepotřebujete. Pokud je v této fázi k dispozici nemáte, nabízí Vám XP jednu z cest, která se již v praxi osvědčila na mnoha projektech. Ale samozřejmě záleží na Vás, jestli ji použijete nebo ne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tamo  |  15. 07. 2003 22:01  | 

zákazník ma málokdy přesnou představu, co vlastně požaduje

Lepe receno, zakaznik vi, ale neumi to podat, neni ochoten se zamyslet, veri, ze "ty lidi od pocitacu" to vymysleji. Dobry analytik je schopen se se zakaznikem pobavit a ty informace z nej dostat. Takze pri nejake snaze mohou byt tyto informace k dispozici pred zacatkem psani kodu, a pritom to nemusi trvat cele mesice. Nevidim duvod proc zacit programovat s mlhavou predstavou o tom jak by to melo vypadat, s tim rizikem ze velkou cast toho co naprogramuji za chvili stejne zahodim.

Ovsem nektere myslenky XP jsou dobre, treba testovani. Ackoli nelze testovat vsechno, vim, ze aspon na ty casti, na ktere testy jsou, je spoleh. Nebo stala komunikace se zakaznikem, ale na tohle by mel prijit zkuseny programator sam.

Jeste ke knize pana Becka: cetl jsem ji a na muj vkus je prilis nekonkretni a marketingova.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  16. 07. 2003 00:37  | 

Pokud máte takového analytika, tak je génius. V některých (lepších) případech zákazník skutečně ví, co chce, ale vždy se objeví nejaká "prkotina", ktrou by tam chtěl zákazník později dodělat (za týden, za mměsíc, za rok...). A mnohdy skutečně nezná všchny detaily a sebelepší analytik je z něj nemůže vytáhnout, protože na ně zákazník přijde, až když vidí první verzi výsledného produktu. A tak to jde pořád dokola.

V XP nezačínáte pouze s mlhavou představou o tom, jak by to mělo vypadat - naopak, vaše představa musí být zcela konkrétní, pouze se nezabýváte všemi detaily a ty řešíte, až na ně přijde řada. Takté se zahazováním kódu to není tak horké - nejdříve přichází na řadu refaktorizace a až teprve po jejím selhání nastupuje popelnice. Nesmíte se bát vyhodit špatný kód, ale to neznamená, že jej budete vyhazovat neustále a vše budete třikrát přepisovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tamo  |  16. 07. 2003 09:15  | 

Dovoluji si odporovat. Zakaznik detaily zna vsechny, jen ho nenapadne ze to jsou dulezite detaily, nebo si neuvedomuje souvislosti. Zde nastupuje analytik, a je to prave v jeho zkusenostech, v ochote pochopit zakaznikovy procesy. Pak dochazi k tomu ze zakaznik i analytik prijdou driv na veci ktere by si uvedomili az po odevzdani programu.

Prace s detaily, to je prave jedna z veci ktere se mi na XP nelibi. Nekdy to mohou byt dulezite veci a nevyplati se je podcenovat. Nerikam ze zakaznik by mel dostat konecnou verzi produktu (az po vyreseni vsech detailu), rikam jen ze by se melo programovat s ohledem na co nejvice detailu. K tem zmenam dochazi, je to nevyhnutelna vec, snaha by ale mela byt aby k tomu dochazelo co nejmene.

Ad refaktorizace: jestli mate slozitou rekneme webovou aplikaci postavenou na vrstvach a zmeny znamenaji zmeny vsech vrstev (meni se jejich rozhrani), pak mate co delat. Prepisovani kodu vnasi chyby a testovani neni vsespasitelne, protoze nelze testovat vse.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Adamek  |  16. 07. 2003 12:01  | 

V otázce znalostí zákazníka s Vámi rozhodně nesouhlasím, i když připouštím, že to hodně závisí na problémové doméně a typu zákazníka. Budete-li vyvíjet systém pro řízení letového provozu, budete mít určitě všechny informace předem k dispozici a nemusíte se obávat změn požadavků ze strany zákazníka. Ale u většiny běžných systémů tomu tak není. Schopný analytik může na základě komunikace se zákazníkem získat perfektní přehled a znalost problémové domény včetně všech detailů. Nemůže však získat od zákazníka úplnou informace o tom, jaké fukce od systému očekává, právě proto, že potřeba některých funkcí se objeví až později. Ať už si na ně prostě nikdo na začátku nevzpomene, nebo budou souviset se změnou legislativy, technologií, organizačních opatření, rozšířením výroby nebo činnosti zákazníka atd. To je fakt, se kterým nepohne sebelepší analytik. A cílem výsledného produktu není dokonale modelovat problémovou doménu, nýbrž VYŘEŠIT PROBLÉM ZÁKAZNÍKA. K tomu vám dokonalá znalost problémové domény nestačí.

Jedna věc je systém vyvinout a druhá je jej udržovat. U všech systémů, s nimiž jsem se ve své praxi setkal (a bylo jich dost), docházelo v průběhu života nasazeného systému (ať už více či méně často) k novým požadavkům na jeho funkčnost. A téměř vždy se objevil požadavek, který se sebelépe navrženou architekturou nebylo možné elegantně splnit.

XP neříká, že máte ignorovat nebo podceňovat detaily, XP říká, že se jim máte věnovat ve vhodnou dobu. Při konceptuálním návrhu a první dekompozici se nebudete zabývat tím, jaké typy materiálu se budou v systému vyskytovat, ale uvažujete na vyšší abstraktní úrovni. Opět zdůrazňuji, že XP nevynechává analýzu a návrh, nýbrž je štěpí a přesouvá do jiného místa, přičemž poskytuje prostředky, jak se efektivně a levně vypořádat se vzniklými problémy.

XP říká, že ke změnám dochází a nemáte se jich bát, neboť Vám přináší nástroje jak je provádět jednoduše a bez zbytečných nákladů. Je dobré se vyhnout ZBYTEČNÝM změnám, ale máte s nimi počítat. Když v určité fázi nevíte, který způsob řešení nějakého problému je nejefektivnější, vyberete libovolné z nich a pokud se neosvědčí tak ho vyměníte. XP klade důraz na JEDNODUCHOST - použijete vždy ten nejjednodušší způsob, který řeší Váš problém a neuvažujete o žádných dalších potenciálních pořadavcích, které nejsou momentálně formulovány. Univerzálním řešením se zásadně vyhýbáte, pokud jsou složitější než ta jednoduchá a nejsou momentálně potřeba.

Zásadním omylem je přístup, kdy se vývojový tým snaží vytvořit dokonalý a univerzální systém, který bude schopen plnit i budoucí požadavky zákazníka (tato tendence vziká zejména tehdy, když se tým soustředí na analýzu problémové domény místo analýzy požadavků). Takový systém je zbytečně složitý, těžkopádný, mnohdy vyžaduje po uživatelích zbytečně podrobné informace, má velké hardwarové nároky, obtížně se udržuje v chodu a především v něm je velké množství potenciálních chyb. Většina předpokládaných požadavků stejně nebude potřeba a objeví se jiné, které systém nebude schopen splnit. A doplnění příslušné funkce bude mnohem složitější, než u jednoduchého systému, vyvíjeného pomocí XP.

Co se týče refaktorování, pak vám asi uniká jeho základní princip - refaktorování (pokud je děláno správně) nemůže vnášet chyby a změna na jedné úrovni nemusí nutně postihnout úroveň jinou - i na to existují refaktorovací vzory. Používám XP právě především pro vývoj vícevrstvých webových aplikací (v J2EE) a dost se mi osvědčilo.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tamo  |  16. 07. 2003 12:36  | 

V zadnem pripade si nemyslim, ze by mela byt snaha o dokonale modelovani problemove domeny, ale o zjisteni skutecne potreby zakaznika. Tzn. neresit jeho okamzitou potrebu, ale zjistit (a to hned na zacatku) v cem mu ma system pomahat. Me se casto stavalo, ze zakaznik zjistil ze program (postaveny presne podle zadani) mu nepomaha a je potreba zmenit/predelat. Ke zmenam samozrejme bude dochazet stale, a neda se s tim nic delat. Jen si myslim, ze by mela byt snaha ty zmeny minimalizovat. Ona i refaktorizace (pominu-li vyhozeni) kodu stoji cas a penize. Budete mit v tom asi vetsi zkusenosti nez ja, ale nechce se mi verit ze lze vse refaktorizovat automaticky.

Když v určité fázi nevíte, který způsob řešení nějakého problému je nejefektivnější, vyberete libovolné z nich a pokud se neosvědčí tak ho vyměníte.

V tom je prave muj pohled jiny. Kdyz nevim ktery postup je nejlepsi, snazim se ziskat dodatecne informace. Samozrejme i zde jsou vyjimky, kdyz implementaci tridy mohu zmenit pozdeji s tim, ze je velice pravdepodobne ze nebudu muset kvuli tomu zmenit i rozhrani.

Abych to shrnul, nektere myslenky z XP (duraz na testovani a komunikaci se zakaznikem, snaha o jednoduchost) jsou dobre. A zase nektere (malo analyzy na zacatku, parove programovani, prilisna snaha o jednoduchost) za dobre nepovazuji, delam to jinak a osvedcilo se mi (projekty dodany vcas, zmeny se take daly delat).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Renata  |  15. 07. 2003 07:09  | 

XP je příklad, jak se udělá z nouze ctnost.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 11:37  | 

Nikoliv, XP je příklad, jak se nouze eliminuje použitím vhodných nástrojů.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  15. 07. 2003 07:34  | 

Historicke vysvetleni:

1. Pozadavek je rychle.
2. Programator neumi analyzu nebo se nechce zdrzovat nebo se mu nechce delat.
    Vzdyt je to prece tak jasne. (Na nedotazenou analyzu narazi pri programovani.)
3. Aby nejak vedecky oznacil svou zivelnou praci, pojmenuje ji XP.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  15. 07. 2003 07:39  | 

Ale jinak, pane Kadlec (hergot, jak je prosim vas paty pad?),
dekuji za clanek, protoze o metodologii se vzdy mluvilo moc malo
anebo se jen poradaly seminare, psala spousta kecu ve vedeni,
ale ve vlastni praci nebo vzdelani programatoru a analytiku to
videt nebylo.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Holda  |  15. 07. 2003 09:14  | 

Kadleci ty truľo. Vzor muž. Bože, přestaňte čučet jen do těch manuálů!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jarin  |  15. 07. 2003 09:19  | 

Moje zkusenost je spise takova, ze v ranem stadiu projektu proste neni dost informaci na to, aby se udelal poradny navrh. Take byva obtizne, ze i tak je tech informaci tolik, ze je proste jeden mozek nepojme najednou, aby mel na cely problem uceleny pohled.

V klasickych metodologiich pak vznika problem, ze design nereflektuje vsechny pozadavky (zvlaste ty, ktere zatim nejsou zname), takze je pak tak jako tak potrebne aplikaci predelat.

Mne se jevi jako opravdu vyhodne "neco zmastit", ukazat to (rozumnemu) zakaznikovi a otestovat, jak se na to tvari. Pak se na tom pokracuje dal. Pokud je to uz v takovem stavu, ze nelze dobre pokracovat, refaktoruje se nebo se to proste zahodi a napise se to lepe (mame-li unit testy, ulehci nam to velky kus prace).

Hodne dobre je, ze se v XP dela to, co lide delaji radi. Casto vidi, ze znechuceny programator (typicky programator se kterym se zachazi jako s tupym strojem, ktery prevede navrh do kodu) jede na 20% vykonu a pritom, pokud by dostal zajimavou praci, mohl byt jet na 100% a jeste premyslet kreativne. Vsimnete si, ze tim padem je dobre motivovany pogramator schopen vyzkouset 4 spatne cesty a pak najit tu spravnou, zatimco onen spatny za stejnou dobu vyzkousi jen jednu domnele spravnou a je ochuzen o zkusenost pri zkouseni spatnych cest.

Uplne nezavrhuji analyzu a navrh, myslim, ze je do urcite miry potrebne vedet, jak ma system vypadat, ale analyza a navrh by mely byt jen o krok vepredu pred kodovanim. Monohokrat jsem videl, ze se udelala analyza a krasny navrh, ktery se pak musel temer cely zahodit nabo zbesile ohnout kvuli nejake drobnosti. Take to casto byva o tom, ze architekt je povazovan za nadcloveka, ktery nemusi respektovat pripominky programatoru (=otroku).

Lepsi je v lidech odhalit jejich schopnosti a podporovat je v tom, v cem jsou dobri, podporovat komunikaci, podporovat soudrznost tymu a to i smerem ven - t.j. ke spratelenym zakaznikum.

Hmm, je to trochu utrzkovite, ale tak to citim (a ne, nejsme zadny startup, co tluce po vecerech "profi" weby a nejsme zadni stredoskolaci, co se za rok naucili zaklady php, html, javascriptu a ja nevim ceho jeste).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tamo  |  15. 07. 2003 22:04  | 

Tak tohle jsou rozumne nazory.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  01. 08. 2003 14:02  | 

A nakonec je dobra ZLATA STREDNI CESTA.

Kdyz clovek udela detailni analyzu a navrh, pri kodovani zjisti, ze by neco bylo vhodne jinac,
ze pro nektere ulohy by bylo vhodne zkusit hruby prototyp. Nebo ze prototyp by se hodil
na ulohu, ktera nas nenapadla zkouset napred, protoze to bylo jasne a jednoduche.

A kdyz zacnu zkouset narychlo spichnuty prototyp, zjistim, ze to mam malo promyslene.

Opravdu je asi nejlepsi udelat rychlonavrh, rychloprototyp a pak zacit pracovat
podle metodologie - analyza, designe, kodovani+testovani, testovani, iterace

Souhlasím  |  Nesouhlasím  |  Odpovědět
Chosko  |  15. 07. 2003 07:57  | 

Americania si to mozu dovolit lebo su prachti a nevadi im ked im za odvedenu pracu (ktora sa zavrhne) zakaznik nezaplati.

Pre nasinca by to bolo len plytvanie energiou a casom a veru takto by sa programovanim neuzivil.

Mam programovanie ako hoby. A z vlastnej skusenosti viem, ze ked raz "povolime uzdu" zakaznikovi, zacne toho zneuzivat,

zmyslat, ze zrazu chcem toto, hento a pod a fin. odmeny nikde. Preto je lepsie pre nas drzat sa vopred stanoveneho planu a ceny.

Americania uz ud roztopase nevedia co by robili. Preto tie rozdiely medzi Amerikou a Europou. Za vsetko mozu prachy.

Souhlasím  |  Nesouhlasím  |  Odpovědět
t.b  |  15. 07. 2003 09:48  | 

Ani nie.. skor to vidim na tu nizsiu sebadoveru... Aj ked je pravda ze si ju "mozu dovolit". Prachy su relativne...
A k tym zakaznikom... ked zacne vymyslat, je nutne to dat na papier... podmienky a ceny, aj zakaznik musi vediet ze sa za to plati.. ak si to neuvedomuje, musi sa to "zapisat", a musi sa to zapisat pre programatorov rozumne, potom si to uvedomi. To ale neznamena, ze programatori sa na tom nemozu vyhrat stylom XP...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  16. 07. 2003 05:34  | 

Chosko, jeste pred stoletim byla drtiva vetsina Americanu neuveritelne chuda. To co rikas bude totiz uplne naopak, amici sou v dnesni dobe bohaty diky tomu ze se chovaj jak se chovaj. Kdyz maj nejakej problem, tak ho proste jednoduse a co nejrychlejc resej, nepremejslej nad tim co vsechno by teoreticky mohlo byt spatne jako Evropani, ale proste delaj. A nedelaj si tezkou hlavu z toho kdyz se jim neco nepovede, v Evrope je to brany jako hrozny selhani, ve statech to proste udelaj jinak.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pedro  |  15. 07. 2003 09:09  | 

))) Nazory pana Stacka me opravdu pobavily, implementujeme ted, opravujeme pozdeji, podle toho to skutecne v IT vypada. M$ je americka firma, ze )

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  17. 07. 2003 02:45  | 

Názory pana Stacka jsou skutečně zajímavé, ale v článku jsem si je dovolil citovat především proto, že Jack Stack není informatik. Má ekonomické vzdělání (pokud by Vás to zajímalo, mohu najít, jaké přesně) a o SWI toho dost možná příliš neví. Názor citovaný v článku však naprosto věrně ilustruje obecný americký přístup k řešení problémů a vůbec k práci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Topper_h  |  15. 07. 2003 09:39  | 

Uprime receno si nevim rady s tim testovanim, vsechny priklady co jsem nasel byly otestovani kopirovaciho konstruktoru, operatoru prirazeni apod. Nevite nekdo kde bych nasel nejaky rozumny priklad nebo vice informaci. Dik

Souhlasím  |  Nesouhlasím  |  Odpovědět
Duro  |  24. 04. 2007 00:51  | 

Napr. tu je step-by-step cvicenie pre Javu. http://www.xp123.com/xplor/xp0201/index.shtml
Je dost jednoduche ako priklad a dost komplexne na to aby sa dala demonstrovat realna pouzitelnost test-first techniky.

Zaklady test driven developmentu + hinty a ukazky ako na to:
http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530

Taktiez test frameworky (napr. NUnit) a rozne open source projekty maju ako sucast zdrojakov automatizovane unit testy, ktorymi sa da inspirovat.
Na netrivialne veci (interakcie objektov, kod zavisly na nedostupnych zdrojoch ako napr. databaza) mozes pouzit mocky, stuby a podobne. Pozri napr. http://www.typemock.com.

Souhlasím  |  Nesouhlasím  |  Odpovědět
david  |  15. 07. 2003 09:41  | 

XP mě před nějakou dobou také zaujalo (nejsem prof. programátor, byl jsem). A docela mě zarazily následující věci:
<BR>Absence analytika, který <B>nesmí</B> být podle mého názoru programátor (natož rychlokvašený, jak podotkl některý z předřečníků v diskuzi) protože to omezuje jeho/její rozhled.
<BR>Kolektivní vlastnictví kódu tzn. kolektivní (ne-)zodpovědnost.
<BR>Dokumentace se píše až když je program "mrtvý".
<BR>Abych jen nehaněl, specifikace testů před začátkem programování (i jakékoliv jiné práce) je <B>vznikající</B> myšlenka, kterou je nutné opakovat znovu a znovu.
No a teď jsem se dostal k nadpisu příspěvku.
<BR>
<B>Stůl vyráběný XP přístupem</B> <I>např. pro takové XP pracoviště</I>
Zákazník chce stůl (zpravidla ani neví jaký, barvu, velikost, počet šuplíků, ...).
Na jedné stěně dílny visí náčrtek stolu jak by asi moh' vypadat.
Na další visí seznam testů (požadavků které musí splnit): Na stůl se nusí vejít ..., ke stolu se musí vejít ..., pod stůl se musí vejít ... a do šuplíků se musí vejít.
A na třetí visí seznam a popis "datových struktur": stolní deska, nohy od stolu, šuplíky.
No a truhláři nějaký stůl vyrobí. Pokud možno tak, že dva najednou vyřezávají z jednoho prkna např. nohu a další dva vyřezávají desku, kdy každá dvojce to uřízne tak velké/dlouhé jak si myslí že to splní požadavky (úmyslně nepíšu že každá dvojce truhlářů řeže jednu nohu - mám na mysli code-reusability + avoid code redundancy).
Nu, kolektivní příprava jednotlivých dílu stolu dopadla dobře, žádný z truhlářů se nepo(d)řezal a může nastat zprovozňování stolu tj. jeho sestavení a vyzkoušení jesli nohy jdou přídelat k desce, jsetli šuplíky pasují do přihrádek a samy od sebe ne navysouvají, jestli stůl nestojí moc nakřivo, jesli se stůl nerozloží když se na něj postaví všechny věci, které na něm mají být, jestli ... (u některých SW dodavatelů se této fázi říká integrační testy).
<BR>
Tak a teď si představte, kolik času, práce a materiálu taková dílna spotřebuje než se jí podaří vyrobit stůl, který splňuje všechny požadavky i když je poněkud křívý. No a nedej příroda, že v průběhu stavby stolu do toho bude zákazník "moc kecat" a a měnit požadavky.
A to nemluvím o tom, že alespoň ten "prořezaný" materiál musí někdo zaplatit.
<BR>
I když je IT přes 50 let (od ENIACu) tak stále není tento progresivní obor občas schopen vzít to co funguje jinde (např. ze stavebnictví) a upravit si to pro svoji potřebu a svá specifika. Místo vynalézání slepých uliček (kód se neosvědčil zahodíme ho) se zaměřit na dobré zadání, projekt a realizaci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
david  |  15. 07. 2003 09:44  | 

Pardon překlep. Ne VZNIKAJÍCÍ ale VYNIKAJÍCÍ MYŠLENKA.

OFF TOPIC: Milé Živě jak to, že nefungují HTML tagy vypsané pod vkladačem příspěvků?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  15. 07. 2003 09:51  | 

halo, super prispevek, doufam ze tim diskuze nekonci - nebot zde by mela zacit - zodpovezenim otazky, proc TO nefunguje napr. jako ve stavebnictvi - nebo snad jeste lepe, jako ve strojarine ? - nejaka idea?

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Marvin  |  15. 07. 2003 11:15  | 

Odpoved na Vasi otazku je jednoducha: Stavebnictvi a strojarina jsou stalete obory (stavebnictvi spis tisicilete) vybavene miliony stranek standardu a postupu, jak se veci delaji tak aby fungovaly. Programovani je nyni zhruba v situaci, kdy v Mezopotamii vynalezli kanalizaci a vodni cerpadlo. Navic ve stavebnictvi a ve strojarine mate _jasne_ a 100% zadani. Toto zadani je podepsano dodavatelem a odberatelem jeste nez se poprve kopne do zeme, pripadne nez prvni delnik pusti soustruh. To ze se programovani vlastni vinou dostalo do pozice "nemozne ihned, zazraky do tri dnu", to je kooperativni usili (nyni jiz temer) dvou generaci IT specialistu

 

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  15. 07. 2003 13:33  | 

Tak nejdrive k te tradici.
Stavebnictvi ma za sebou 3000 let. Strojarina 300 let. Ve strojirenstvi jsme se tedy dostali za 1/10 casu minimalne tak daleko, jako stavebnictvi. Proc by nemela informacni technologie opet vuci strojirenstvi dosahnou toho sameho stupne vyvoje za 1/10 casu - tedy za 30 let? To je jedna z otazek, ktere me brani jednoduse uznat, ze duvodem je pouze ona TRADICE daneho oboru. 

Mnohem napinavejsi je ovsem pasaz ve vasem prispevku - ...a ve strojarine mate _jasne_ a 100% zadani. Toto zadani je podepsano dodavatelem a odberatelem jeste nez se poprve kopne do zeme, pripadne nez prvni delnik pusti soustruh. ...

PROC je to 100% zadani tady. Kvuli tradici? To se obavam neni ta spravna odpoved. V te souvislosti je zajimavy Vas primer - nez delnik pusti soustruh. Ve strojirenstvi spousti ten delnik ten soustruh davno predtim, nez se dodavatel a odberatel prvne setkaji. Jinak receno - jestli nekdo pomoci XP zhotovi software za 3 tydny + 7 dni a nebo klasicky za mesic je ve srovnani se strojirenstvim nezajimave, strojari maji vec dodavky uz davno na skladu.

Pro me ta tradice proste jenom umoznila NECO, co nam v tech starych oborech pomaha uspokojovat potreby odberatelu bez toho, aby dochazelo stale k tomu, ze odberatel nevi co chce, vecne chybi cas a vsechno software je plne chyb. Co ale prehlizime, pri srovnani techto odvetvi?

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  15. 07. 2003 14:13  | 

No to ste mne rozesmál: Jericho stálo asi 8 - 7 000 let př. Kr. - takže stavebnictví tu je cca 10 000 let!! A strojařina? Podle toho kde hledáte počátky - za "strojařinu" lze považovat stavbu jakýchkoli strojů? Tedy např. římských obléhacích strojů? Tak to je zase nějakých 2200 let zpátky Pokud strojařinu spojíte s počátky průmyslové revoluce, např. parní stroj, tak je to asi jak ste uvedl (1690 první podoba parního stroje).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 12:17  | 

Příměr se stolem nesedí - pokud budete mít při tvorbě systému tak jasné zadání, jako má truhlář před zahájením výroby stolu, pak samozřejmě žádné XP nepotřebujete a byl byste hloupý, kdybyste se jej snažil použít. Ale představte si, že máte vyrábět stůl a zákazník ani pořádně neví, jaký stůl potřebuje a neustále své požadavky mění a upřesňuje. Ukážete mu výsledek, a on si vzpomene, že chce místo dvou velkých šuplíků čtyři malé, nohy o 5 cm delší a desku stolu o 20 cm kratší. Ne, takovýmto způsobem stůl vyrábět nebudete, protože máte vysoké náklady na změnu. Pokud by se vám je podařilo snižit (použil byste nějaký opakovaně použitelný materiál, který se dá snadno a levně opracovat a zbytky či odpad lze jednoduše přeměnit opět na vstupní surovinu), klidně byste i stoly mohl vyrábět s použitím XP. XP stojí na tom, že Vám umožní snížit náklady na změnu.

Analytik v XP nechybí, pouze není dedikovvaný a jeho funkci přebírají jednotlivý programátoři, v čemž nevidím problém. Aby analytik neměl omezený rozhled, musí mít schopnost abstraktního pohledu na věc, žádnou souvislost s tím jestli je nebo není programátor zde nevidím.

Kolektivní vlastnictví kódu také není nic nového pod sluncem, o něj se snaží i klasické postupy SW inženýrství - proto ono obrovské množství dokumentace tvořené v průběhu vývojového cyklu, aby nebyly konkrétní části systému vázány na konkrétního člověka, který nemusí být v případě požadavku na změnu k dispozici (zaneprázdněn, nemocen, mrtev apod.). O nezodpovědnosti nemůže být řeč, neboť všichni jsou zodpovědni za kód jako celek a nesou individuální zodpovědnost za své změny v tomto kódu (které jsou díky systémům pro správu verzí snadno dohledatelné a identifikovatelné).

Co se týče dokumentace, tak primární dokumentací je přehledný a patřičně komentovaný zdrojový kód. Ten je totiž vždy aktuální, což se nedá vždy říci o případné dokumentaci externí. Neaktuální dokumentace je k ničemu a je mnohem horší, než žádná dokumentace. Pokud se už systém nebude měnit, pak se vyplatí vytvořit jednoduchou a stručnou dokumentaci, která popisuje systém jako celek. Dříve to nemá smysl a jde pouze o zbytečné plýtvání prostředky. Pokud narazíte na informaci, kterou byste chtěl zdokumentovat, prostě ji vložíte jako komentář na příslušné místo ve zdrojovém kódu. Ve spojení se systémuu pro automatické generování dokumentace (např. JavaDoc) jde o velmi silný nástroj.

XP nepřináší žádné nové postupy nebo myšlenky, kombinuje pouze ty existující, které ovšem žene do extrému (proto extrémní programování) Klasické postupy jsou pomalé a drahé - v ostatních oborech se používají proto, že jiné prostě použít nemůžete. V IT se vám alternativa nabízí, tak proč ji nevyužít?

Co se týče slepých uliček, XP jako takové za slepou uličku rozhodně nepovažuji a zahazování nefektivních nebo špatných výsledků práce se děje i v ostatních oborech. Myslíte, že architekt sedne k papíru (nebo počítači) a nakreslí projektovaný dům hned napoprvé? Nikoliv, jde také o iterativní proces, prováděný ve fázi, kdy jsou náklady na změnu malé (je blbost to rovnou stavět a pak bourat). U XP jde o to samé - pokud jsem schopen rychle a efektivně psát kód a jeho zahození a přepracování je levná operace, proč ji nevyužít. V mnoha případech se takto problémy řeší efektivně a ne každý kód musíte hned zahazovat. Máte možnost jej refaktorovat a zahození použít až v krajním případě.

Souhlasím  |  Nesouhlasím  |  Odpovědět
david  |  15. 07. 2003 15:13  | 

Po krátké přestávce věnoované práci se vracím k diskuzi a pokusím se reagovat na náměty a připomínky k pohádce i na některé jiné.
Jsem člověk s technickým (nepočítačovým) vzděláním pohybujícím se v IT a dokonce jsem i pracoval jako programátor (cca 10 let tomu nazad). Dnes se pohybuji okolo dodávek krabicového necustomizovatelného, krabicového customizovatelného i na zakázku vyvíjeného SW a občas také s kolegy něco doprogramováváme. A ze všech těchto zkušeností pramení moje skepse.

To PA souhlasím s tím, že je nejlepší měnit cokoliv kdy je to relativně levné ve srovnání s celkovou cenou dodávky. Ale nesmí se to dostat k českému zákazníkovi, který šetří každou korunu a někdy i podivné (př. ERP systém za cca 20Mio Kč a několik dní se řeší jestli to provozovat na serveru za 100K Kč nebo 300K Kč), zkuste třeba říci, že jste zahodili týden práce několika programátorů.

Naprosto nesouhlasím s názorem, že stačí dokumentace typu JavaDoc nebo Perl-Pod, která je většinou pojatá: tato funkce dělá tohle a tahle dělá něco jiného. Uživatele zajímá co se stane když ... Ne to že se aplikace skládá z těchto třid s takovými vlastnostmi. Zkuste si představit textový procesor napsaný v Javě a a dokumentovaný v JavaDocu a situaci kdy po překročení velikosti dokumentu cca 300KB začne konzumovat 100% CPU, po zapnutí Tracking Changes rozpadnou všechny rejstříky nebo se najednou za každé písmeno dokumentu přidá tvrdý konec stránky. Uživatele zajímá jak to odstranit/obejít a ne která třída a funkce je za to zodpovědná. A krom toho si myslím, že aktuálnost dokumentace není zaručená tím, že je to blízko kódu.

Znal jsem i programátora, který si cosi přečte, něco napíše a pak zkoumá proč to nefunguje. To už je ale opravdu eXtrémní Přístup.

Závěrem, vzhledem ke svým zkušenostem jsem proti jakýmkoliv HURÁ přístupům (k tomu může nevhodně uchopené XP přispět) bez úvodní úvahy jak SW navrhnout aby to bylo dlouhodobě udržovatelné a konzistentně rozšiřovatelné.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  15. 07. 2003 16:14  | 

Ohledne srovnani XP a hura pristupu - no ja nevim - pokud byste dodrzel to, ze napisete nejdrive testy a pak zacnete delat realny kod, zjistil bystem, ze hodne te analyzy prave udelate pri psani testu - nemluve o tom, ze prave ty testy vas nuti psat kod citelne a peclive definovat jednotliva API. Takze XP pokud je delano poctive neni zadny hura pristup.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  16. 07. 2003 00:00  | 

> ... zkuste třeba říci, že jste zahodili týden práce několika programátorů.

Ano, to je typicky český problém (se kterým se setkávám dost často), ale pokud zákazníkovi vysvětlíte základní aspekty XP a on pochopí jeho přínos pro rychlost a kvalitu vývoje, jste za vodou. Pokud mu to nevysvětlíte, nemá smysl se do XP pouštět, protože XP vyžaduje úzkou kooperaci se zákazníkem a bez toho to prostě nejde. A samozřejmě musíte mít rozumně nastavenou ekonomickou stránku věci - pokud bude zákazník platit vývojáře podle odpracovaných hodin (nejlépe 5000 Kč/h), pak se opravdu bude zuby nehty bránit vyhození jakéhokoliv hotového kódu.

> Naprosto nesouhlasím s názorem, že stačí dokumentace typu JavaDoc nebo Perl-Pod...

Proč? Můžete tam uvést COKOLIV, co byste uvedl do případného externího dokumentu (viz můj příspěvek níže, kde JavaDoc obhajuji obšírněji). A nemusíte samozřejmě použít přímo JavaDoc, ale libovolný jiný nástroj, který Vám bude vyhovovat více. Důležitá je ta integrace dokumentace i kódu v jeden celek. Bavíme se samozřejmě o programové dokumentaci, nikoliv o uživatelské příručce. A pokud zákazník objeví chybu a programátor ji má odstranit, mnohem lépe se mu bude hledat, pokud je dokumentace součástí zdrojového kódu. Jinak Vámi popisované chyby by měly odhalit automatizované testy. Pokud ne, je chyba v testech, tj. v zadání (v XP je zadání tvořené testy). Takže se nejdříve opraví testy, poté příslušná chyba a samozřejmě i dokumentace.

> Znal jsem i programátora, který si cosi přečte, něco napíše a pak zkoumá proč to nefunguje. To už je ale opravdu eXtrémní Přístup.

To samozřejmě s extrémním programováním nemá nic společného.

> Závěrem, vzhledem ke svým zkušenostem jsem proti jakýmkoliv HURÁ přístupům (k tomu může nevhodně uchopené XP přispět) bez úvodní úvahy jak SW navrhnout aby to bylo dlouhodobě udržovatelné a konzistentně rozšiřovatelné.

Pozor, úvodní úvaha o tom, jak systém navrhnout v XP nechybí, naopak je velmi důležitá. Pouze se v této fázi nesnážíte udělat kompletní analýzu problémové domény, ale jde vám o hrubý návrh architektury systému a jeho počáteční dekompozici, abyste jej upřesnili a případně upravili až v okamžiku, kdy to bude nezbytně nutné.

Co se týče rozšiřitelnosti, tak ta se udržuje pouze na nezbytně nutné úrovni. Pokud rozšiřitelnost (či libovolnou jinou funkci) nepotřebujete hned, prostě ji neimplementujete. Pouze Vám komplikuje kód, stojí Vás zbytečné úsilí a je potenciálním zdrojem chyb. Navíc ani nevíte, jestli bude vůbec potřeba. Systémy jsou plné funkcí, o kterých se tvrdilo, že budou určitě potřeba, a zatím je nikdy nikdo nepoužil. Základním mottem XP je "V jednoduchosti je síla". Až bude daná funkce vyžadována, prostě ji implementujete. Používáte XP, takže by veškeré náklady na změnu měly být jednoduché. Přidání nové funkce většinou vyžaduje trochu dekompozice a nějaké to refaktorování. Ale aby to fungovalo, musíte přísně dodržovat veškerá pravidla XP.

Souhlasím  |  Nesouhlasím  |  Odpovědět
lingeek  |  15. 07. 2003 10:02  | 

Myslim, ze vetsina z Vas nepochopila ulohu osobnosti programatora v XP. Prave strach s 'vyhazovani' kodu, omylu a chyb je hlavnim duvodem, proc se XP nezamlouva svym kritikum. Zajimalo by me vekove, potazmo profesni ( a take studijni ) slozeni prispevatelu. Osobne studuji MFF UK a jakobych slysel profesory, kdyz rikaji, ze sveho casu se nejdrive posadili za stul s tuzkou a papirem, poradne vsechno promysleli a pak se teprve dali do prace. Stroju bylo tenkrat malo a hlavne nebyly tolik dostupne. Proc prave moznosti _vyvijet_ nevyuzivame, kdyz muzeme? Nechci podcenit fazi analyzy a navrhu, ale XP zkratka vede k reseni v kratkem case a jsem presvedcen, ze vede k ne jen uspokojivym, ale hlavne ke korektnim resenim.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  17. 07. 2003 02:49  | 

Presne tak. A navic je treba dodat, ze rada ortodoxnich, klasickych, konzervativnich informatiku neuznava ani SWI jako takove (neni podle nich dostatecne exaktni a prilis empiricke). Tak v jejich pripade jiste nelze ocekavat pochopeni XP.

Souhlasím  |  Nesouhlasím  |  Odpovědět
zcg  |  15. 07. 2003 11:49  | 

Mno me to pripada, ze vetsina kritiku ani tak nekritizuje XP, jako spis, ze najednou je vsude fura "rychlokvasek", ktery diky modernejsim programovacim nastrojum zvladaji programovat stejne rychle jako ty stari skalni a chytrejsi.
Taky nutno rict, ze XP se nebude hodit vsude. Bude se hodit pro projekty , ktere dopredu vlastne nemaji plnne dannou funkcionalitu. Kdyz je uz dopredu jasny rozsah projektu a vsechny fce tak se XP asi moc nehodi, ale pokud nema ani sam zakaznik jasno, tak je XP super - uz jen pro to ze dokud nepadaji letadla a nebouchaji reaktory tak spousta lidi tak nejak pocita, ze to nebude dokonaly (lidi taky nejsou). A XP dava daleko lepsi moznosti jak neco rychle opravit/zmenit.
Obavam se ze ani ve stavebnictvi neni vsechno do detailu zanalyzovane ac ma tisiciletou historii (mno tak ten zednik udelal to okno o dvacet centimetru vedle to se nejak srovna). Taky jde o typ zakazky - kdyz stavim reaktor tak se radsi meri na milimetry a c je spatne se predela a kdyz jede o rodiny domek tak je plan spis takova inspirace a pokud to bude vypadat a nepadat tak se to skousne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
lingeek  |  15. 07. 2003 13:16  | 

Je pravda, ze spousta lidi ted muze 'programovat', prestoze o tom nevi skoro nic. Uznavam, ze ti starsi z nas maji neco za sebou, jsou zkusenejsi a casto peclivejsi, nicmene se velmi casto, pro mne nepochopitelne, brani novym postupum. Prijde mi, ze vetsina prispevku k tomuto clanku je napsana prave takovymito lidmi, pripadne temi, kteri jsou 'Rapid' vyvojari. Jeste jedne veci uplne nerozumim - proc vetsina lidi ceka od XP vsechno mozne, jen ne stabilni aplikace? Copak to neni mozne? Nebo pouze 'standardnimi' metodami lze dosahnout uspokojivych vysledku? Vetsina aplikaci prece prave takto vznikala, ale uz jen maly podil z teto casti si muze privlastnit nalepku (temer) 'bezproblemovy produkt'.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Libor Svehlak  |  15. 07. 2003 12:20  | 

Chtel bych se zeptat nekoho zkuseneho v oblasti XP, jak je to s onou zminovanou dokumentaci az ve fazi "smrti" projektu. Kdy se podle XP ma psat dokumentace, jestlize se projekt vyviji postupne nekolik let (rekneme kontinualne 10 let) v malem tymu (do 5-ti lidi), pricemz lide v tomto tymu se obmenuji (rekneme ze zustava jen vedouci projektu a i to nemusi byt zcela pravidlem)? Podle toho co zde bylo napsano takovy projekt ma stale daleko do faze "smrti". Nebo se ma psat dokumentace vzdy po ukonceni implementace noveho "baliku" pozadavku (zdraham se ovsem po ukonceni implementace tohoto "baliku" rict, ze se ocitl ve fazi "smrti" jestlize na tyto pozadavky navazuji dalsi pozadavky atd...)? Dle meho je nejlepsi dokumentaci (alespon tu "programatorskou") psat v prubehu tak jak se projekt vyviji a dokumentaci "analytickou" mit alespon v "nejakem" stavu jeste pred zahajenim praci (jednotliveho "baliku" pozadavku).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 13:10  | 

Primární dokumentací je vždy přiměřeně komentovaný zdrojový kód. Informaci, kterou považujete za důležitou a která neplyne přímo ze zdrojového kódu prostě doplníte jako komentář. Externí dokumentace se dá ze zdrojového kódu vygenerovat pomocí vhodného nátroje (JavaDoc).

Jde o to, že u externí dokumentace existuje strašák, který se jmenuje Aktuálnost. V okamžiku, kdy provedete změnu v kódu, musíte také aktualizovat dokumentaci, což jednak mnohdy stojí víve úsilí než vlastní změna a jednak hrozí riziko, že se informace ke měněnémmu kódu nachází na více místech a vy některé přehlédnete. Navíc se vám může stát, že pod tlakem nedostatku času opravu dokumntace odložíte na později a ono později už nikdy nepřijde. Opravit případný řádek komentáře spolu s úpravou kódu je mnohem jednodušší. Navíc je při studiu kódu jednodušší sledovat asociované komentáře, než listovat v externí dokumentaci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Libor Svehlak  |  15. 07. 2003 14:27  | 

Dekuji za odpoved, ale bohuzel mi mnoho noveho neprinesla JavaDoc pouzivame, ale dle meho toto neni dostatecne. Dokumentace ala JavaDoc totiz prinasi pouze jeden uhled pohledu na system. Kde vsak mame dalsi uhly pohledu (tim myslim ruzne typy digramu napr. dle UML)? Dle meho je castecne problem v neexistenci skutecne "dvoucestnych" nastroju, ktere pomahaji jednak vyvijet samotny SF a druhak udrzovat (konzistentne) jeho dokumentaci. Napr. vztah diagramu ERD a jeho skutecne "implementace" v DB. Na pocatku vetsinou mate nejak navrzenou strukturu DB a zhruba nakreslen model. Pri implementaci vsak model doznava urcitych zmen, pricemz tyto zmeny posleze musite provadet na dvou mistech (ERD diagram a vlastni databazova struktura). Zkusenost mi rika, ze zvlaste pri velmi kratkych iteracich kdy se dodelavaji zmeny "na posledni chvili" dojde drive nebo pozdeji k nekonzistenci mezi dokumentaci a vlastni implementaci. Pritom tato dokumentace je uzitecna uz behem implementacni faze a ne az po jejim skonceni. Znate nastroje, ktere by umoznovaly udrzovat konzistentni i tuto cast dokumentace? Samozrejme problem je i u jinych typu diagramu, ne jenom ERD.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 16:44  | 

Naprosto nesouhlasím s dokumentací stylu JavaDoc. Je to mnohdy nedostatečné. Protože u dokumentace existuje strašák zvaný aktuálnost, tak pro jistotu budeme dělat pouze výtažky z komentářů ve zdrojáku.

Zde je ejden z bodů, se kterým s XP metodou naprosto nesouhlasím.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  15. 07. 2003 23:22  | 

Co máte proti dokumentaci ve formátu JavaDoc? Můžete tam uvést COKOLIV, co byste uvedl do případného externího dokumentu. A máte skutečně zajištěnou aktuálnost a údržba dokumentace je výrazně snazší.

Vemte si např. přejmenování fuknkce nebo třídy, což je u refaktoringu docela častá věc. Pokud máte dokumentaci vedenou externě, musíte nalézt a opravit všechny výskyty tohoto identifikátoru. Pokud používáte JavaDoc, dokumentace se aktualizuje sama a rozumný nástroj pro refaktorizaci Vám aktualizuje i veškeré případné odkazy na tuto funkci. Stejné je to i s ostatním refaktorováním či změnami v chování tříd a metod. Je jednodušší a rychlejší opravit vše na jednom místě, než hledat, kde se to má všude opravit. A nemusíte komentovat věci, které jsou ze zdrojového kódu jasné. A pokud něco ze zdrojového kódu jasné není (např. máte nutkání doplnit abstraktnější popis operací, prováděných metodou), většinou jde o problém nesprávné dekompozice či volby nevhodných identifikátorů. Ale tento problém je snadné odstranit pomocí refaktorování.

A pokud Vám nevyhovuje formát generované dokumentace, můžete použít jiný doclet nebo úplně jiný nástroj pro generování výstupních dokumentů.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 23:57  | 

Předem napíši, že máte u mě respekt za Vaši snahu trpělivě vysvětlit principy XP.

Přejmenování identifikátorů může vést k nutnosti přepsat nejen dokumentaci, ale také odkazy na tento identifikátor v mnoha dalších modulech zdrojových kódů. Tedy nejde jen o to nalézt identifikátory v dokumentaci, ale i odkazy a použití ve zdrojovém kódu, apod.. Mnoho identifikátorů jednoduše změnit je "drahé", zejména pokud jsou zažité a jsou součástí rozhraní využívaných jinde, nejen v tomto projektu. Takže přejmenování není jen problém dokumentace a jde přejmenovávat jen do určité míry. Jinak budete stejně hledat, kde to všude opravit.

Problém JavaDoc a spol. je ten, že je dokumentace silně vázaná na strukturu zdrojového kódu. Mnohdy jsou užitečné i pohledy jiné, i když uznávám, do JavaDocu lze v podstatě vlepit všechno. Je samozřejmé, že na dokumentaci zdrojového kódu je styl JavaDoc skoro ideální.

Dokážu si představit, že určitá složitější procesní schémata například budou daleko srozumitelnější samostatně, než ve vazbě na zdrojový kód. Datové struktury databáze je lépe vytvářet v CASE, než ve zdrojovém kódu. Apod..

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  16. 07. 2003 00:26  | 

Přejmenování tříd či identifikátorů je jedním z nejzákladnějších refaktorování v XP. Výhoda každého refaktorování spočívá v tom, že se dá snadno automatizovat a pro většinu OO jazyků existují příslušné nástroje (např. RefactorIT pro Javu nebo Refactoring Browser pro Smalltalk). Tyto nástroje samozřejmě naleznou a opraví i všechny příslušné reference, takže je přejmenování proměnné či třídy velmi levná operace.

Pokud je metoda nebo třída součástí nějakého vnějšího rozhraní, existují i refaktorovací vzory (omlouvám se za to hrozné slovo), které řeší i tento problém (jde většinou o zavedení proxy objektů apod. - bohužel nemám po ruce katalog refaktorovacích vzorů abych byl podrobnější).

Navíc máme automatizované testy, které by měly chyby typu nesprávný identifikátor odhalit. Kromě toho se při refaktorování píší i jednoúčelové testy, které by opět chyby způsobené nesprávným refaktorováním měly odhalit.

Co se týče systému JavaDoc, lze tam vkládat i informace, které nejsou vázány na konkrétní třídu, ale např. na balíček. Takže informace nebo schémata platná pro celý systém přiložíte k balíčku systému a informace k jednotlivým modulům pak vložíte opět do jejich příslušných balíčků. Pokud je struktura balíčků a tříd výrazně odlišná od struktury aplikace, opět bych hledal chybu v dekompozici.

A důležité informace (schémata, diagramy, základní architektura) patří na tabuli nebo na nástěnku. XP Vám nezakazuje vytvářet diagramy mimo zdrojový kód nebo používat CASE - XP pouze říká, že primární dokumentací je zdrojový kód a že je zbytečné informace v něm obsažené duplikovat na jiných místech.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Hulmak  |  15. 07. 2003 15:50  | 

Nemohu si pomoci, ale nejsem schopen si ani teoreticky představit, jak uplatnit XP např. při vývoji vícevrstvých systémů kde jedna vrstva je silně závislá na dalších. Typickým příkladem je systém, který má vespodu SQL databázi (např. do 100 tabulek). Podle mého názoru je návrh struktury databáze jako základní vrstvy systému velmi podstatným krokem krokem úvodní fáze projektu, který nelze jen tak jednoduše "rozpustit". Nehledě na to, že téměř neznám programátora, který je schopen dát dohromady životaschopný návrh databáze a ještě přitom vyvíjet další návazné vrstvy. Navíc pokud se chci dopracovat ke kvalitní struktuře databáze, musím mít velmi dobře zpracovanou analýzu. Pokud navíc kromě klientské a databázové vrstvy mám ještě nějaké další (aplikační, komunikační, atd.), nedovedu si dost dobře představit zvládnutí celého procesu pomocí XP. Podotýkám, že mám na mysli stále systém, který vyvíjí a udržuje

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Hulmak  |  15. 07. 2003 15:53  | 

doplňuji: ... ,který vyvíjí a udržuje

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Hulmak  |  15. 07. 2003 15:57  | 

Omlouvám se, dotřetice to snad dokončím.

Zkrátka je mezi Vámi někdo, kdo by mohl napsat, na jakou aplikační architekturu XP použil ? Díky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  15. 07. 2003 16:24  | 

Minimalne unit testy se daji pouzit. A pro veci jako jsou db je jedna z moznosti 'mock objects' strategy - strategie falsenych objektu - www.mockobjects.org. Mockobjectse se tvari jako realne (ale realne nejsou) a umozni tak napsat unit testy na casti, ktere musi pouzivat narocne zdroje jako je treba SQL databaze, aniz by ta databaze byla dostupna ci vubec existovala.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  16. 07. 2003 00:54  | 

Extrémní programování se dá bez problému použít i na vícevrstvé systémy (pokud je ovšem dodržen limit 10 lidí v týmu). Mám zkušenosti s použitím XP pro vývoj vícevrstvých systémů v J2EE a lze to použít bez problémů. Je pravda, že návrhu rozhraní mezi vrstvami je třeba věnovat více pozornosti, ale dokud rozhraní není zveřejněné, lze jej libovolně měnit a i po jeho zveřejnění se dá provádět refaktorizace - existují na to speciální refaktorovací vzory, které tyto problémy řeší.

Klíčovým problémem je opět dekompozice - rozdělení systému na jednotlivé objekty na různých úrovních i v různých vrstvách s různou granularitou. Pro každý objekt se pak napíše sada testů a jednotlivé objekty se postupně implementují, přičemž se dodržují všechna Pravidla a používají se příslušné nástroje. Co se týče úvodní dekompozice, doporučuji začínat objektovým návrhem na aplikační úrovni. Datový model se pak dá vytvořit podle struktury perzistentních objektů aplikační vrstvy (v J2EE podle objektů Entity Enterprise JavaBean), nebo se explicitně nevytváří vůbec (u Entity EJB s kontejnerem řízenou perzistencí).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr P.  |  16. 07. 2003 09:14  | 

Chtěl bych se zeptat, jakou máte zkušenost s používáním perzistentních EJB (myslím tím CMP a BMP). Tato technologie se mi líbí. V tutoriálech od Sunu jsem ale viděl že každá instance EJB si drží spojení do databáze. To mi připadá hloupé a mám takové tušení že 500 - 1000 spojení do databáze už začne být problematických. Toto by ještě nebyl problém, já bych si narozdíl od ukázkového řešení Sunu spojení pro každou metodu "půjčoval" z connection poolu a před ukončením metody bych je zase vracel. Jsem spíš skeptický co se výkonu týče. Chtěl bych například v klasické okenní aplikaci naplnit tabulku dejme tomu smluv kterých je 3500. V tabulce chci kromě primárního klíče zobrazit další doplňkové informace. A po vybrání řádku z této tabulky chci zobrazit detail vybrané smlouvy. Vytvoření 3500 instancí perzistentních EJB jenom kvůlu zobrazení jedné tabulky mi přijde neefektivní (zatím jsem nezkoušel).
Rozhodnul jsem se že místo perzistentního EJB použiju stateless session bean a radši budu mít metody abstraktnější a budu s každým voláním předávat primární klíč. Nehledě k tomu, že načtení celé tabulky můžu provést jedním SQL dotazem. To už ale není tak elegantní řešení.
Chtěl bych znát Váš názor.
Děkuji

Souhlasím  |  Nesouhlasím  |  Odpovědět
david  |  16. 07. 2003 09:38  | 

S CMP a BMP si hraju (více s BMP). To že si každá instance drží spojení je pravda, ale na druhou stranu je její životnost v aktivní fázi krátká, řádově sekundy (ejbActivate, ejbPasivate). A většina J2EE platforem drží tzv. Connection Pool, tzn když pasivovaný (hrozné slovo, neznáte někdo lepší objekt connection zavírá tak se nerozpojuje (většinou) spojení s databází ale jen se otevřené spojení vrací do poolu pro přidělení dalšímu EJB.

Souhlasím  |  Nesouhlasím  |  Odpovědět
mikel  |  15. 07. 2003 19:10  | 

ako som to tak cital, tak som mal dojem, ze je to extremne preto, ze sa tak casto oslavuje  a to sa potom dost tazko pracuje, ked clovek preflaka noc, viem o com hovorim, je to fakt extrem..

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  17. 07. 2003 02:53  | 

 Oslav je při XP vývoji skutečně dostatek. Souvisí to zase s tím americkým přístupem, který hlásá, že každý dílčí úspěch si zaslouží oslavit a je důvodem k dalšímu zvýšení sebevědomí. A do pojmu "dílčí" se vejde opravdu i velmi miniaturní, takřka neznatelný úspěch. Hovořím z vlastní zkušenosti. Američané si tímto způsobem nejen zpestřují dny, ale především exponenciálně vyhánějí svou sebedůvěru stále výše a výše.

Souhlasím  |  Nesouhlasím  |  Odpovědět
George  |  15. 07. 2003 19:33  | 

XP neni spatny pristup. Pro nektere projekty a tymy to muze byt dobre. Co se mi na nem vsak nelibi je moc velka "zivelnost". Je to hodne narocne na programatory. Hlavne na programatory nizsich a strednich vrstev aplikace. Jestlize se jde spatnym smerem a zjisti se, ze je treba kus kodu od zakladu prepsat, tak tito programatori musi prepsat fungovani nekolika vrstev aplikace a vsech navaznych modulu. Kdyz delate neco mensiho, tak to nemusi zase tak bolet, ale jakmile napr. tvorite nekolik modelu, kazdy s objektovym modelem obsahujicim v radu pres 50 odvozenych a vzajemne spolupracujicich objektu, tak se vam spatny navrh muze dost vymstit. Existuji sice techniky "kvalitniho" navrhu v jednotlivych technologiich a programovacich prostredich, ale i tak je to fuska. A obcas kvuli tomu nespim moc dobre  Zvlast kdyz resim nejaky problem, vim, ze to jde udelat obecneji a lepe, ale porad s tim nejsem spokojen. Kdyz to nakonec vymyslim a jsem s tim spokojen a nekdo mi po case rekne, ze by potreboval jeste tohle a tohle, coz ale totalne boura moji fylozofii reseni, tak bych nejradsi vrazdil. Protoze v takovem pripade konecny termin projektu nestiham ani omylem.

Proc jenom vsichni zakaznici tolik spechaji? (Ja vim proc, ale taky by mohli byt tolerantnejsi.) A proc manazeri a vedouci pracovnici kyvnou na kazdou blbost, jen aby se zakaznikovi zavdecili? Ach jo.

Programatorum a analytikum zdar.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ing. Petr Adamek  |  16. 07. 2003 01:03  | 

> Jestlize se jde spatnym smerem a zjisti se, ze je treba kus kodu od zakladu prepsat, tak tito programatori musi prepsat fungovani nekolika vrstev aplikace a vsech navaznych modulu.

XP Vám poskytuje nástroje, aby Vás takovéto věci moc nebolely - dřív než něco zahodíte, můžete to zkusit refaktorovat, buď to Váš problém vyřeší, nebo přinejmenším umožní zajistit kompatibilitu nového řešení s původním rozhraním a eliminovat nutnost přepsání všch návazných modulů.

Cílem XP je zjednodušit a zlevnit změny, kompletní zahození kódu je až poslední možnost, ale programátor se jí nesmí bát.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ondra  |  16. 07. 2003 08:22  | 

Nevim, jestli nasinci umeji pouzivat extremni programovani, ale extremne programovat teda umi! Kolikrat uz to neni ani k smichu :(.

Lide bdete! ;)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Luboš Tomsa  |  17. 07. 2006 01:15  | 

Slyšel jsem mnoho názorů na XP, všechny měly něco společné:
1. vytrhávaly konkrétní principy a postupy XP z kontextu
2. bylo z nich zřejmé nepochopení striktní doktríny vývoje v XP
3. zaznívaly od lidí, kteří XP sami seriózně nezkoušeli a nesnažili se jej pochopit
4. vycházely z představy, že XP si klade za cíl postihnout všechny aspekty vývoje
5. lidé, kteří XP hodnotili negativně, většinou buď neovládali řádně OOD (Object Oriented Design), anebo naopak ovládají OOD skvěle, ale jsou zaběhlí ve vodopádovém stylu vývoje: analýza, design, implementace, konec.

Kdo knihu XP explained četl, jistě ví, že jde pouze o nadšené evangelium znázorňující pocity z vývoje v podmínkách XP, ale neobsahuje žádné konkrétní postupy a příklady, když už tak pouze velmi abstraktní a zkrácené. Jak se píše pomocí TDD (nebo BDD) na specifických projektech, jak se dělá refaktoring na složitých projektech, jaké používat nástroje, jak konkrétně řešit technické otázky různých projektů, jak na databáze, co configuration management to jsou všechno věci, které jsou z části popsány v mnohé další literatuře, ale k cíli - tedy použití ve svém týmu na svém projektu - se vývojář musí propracovat sám.

Názor, že XP je živelné, chaotické, že je použitelné pouze na malé projekty s krátkou životností, nevychází ze skutečné zkušenosti autorů XP a mnoha mnoha týmů, ale vychází zřejmě jen z naprosto neinformovaného postoje lidí, kteří XP nepochopili, a většinou se o to ani vzhledem ke svým předsudkům nesnažili.

XP je velmi striktní, z knihy Kenta Becka, která asi jediná byla přeložena do češtiny, není možné načerpat ani malý zlomek know-how, které se za věru velmi entuziastickým textem této knihy nachází, maximálně tak drobné overview a nasměrování na alternativní cestu vývoje softwaru.

XP a TDD/BDD je pouze jiný způsob, jak dosáhnout dokonalého designu vaší aplikace. Umožní vám mít dokonalý design ne na počátku vývoje díky tomu, že si jej geniálně vymyslíte a namodelujete v UML, naopak vám umožní mít dokonalý design neustále, od začátku až dokonce. A to je základní myšlenka agilních metodik - nejen rychle dospět k cíli, ale dospět co nejrychleji k aktuálnímu cíli s nejlepším možným designem aplikace. Až příjde další cíl, nová feature například, pak opět budeme spět co nejrychleji k tomuto cíli, a přitom mít znovu dokonalý design, i kdybychom měli celý systém složitě refaktorovat.
Zní to možná jako protimluv, ale není, jde jen o to, jakým  style m chcete pracovat. Pokud vás baví se babrat ve strašném kódu se strašným designem a neustále tam jen doplácávat funkcionalitu, debuggovat a luštit existující logiku, pak jistě XP ani TDD/BDD nepotřebujete, ale potom se připravte na možnost, že váš projekt zemře mnohem dříve než by musel.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Test 9 bezdrátových reproduktorů

Jak ovládnout Instagram

Test levných 27" herních monitorů

Jak se zbavit nepotřebných věcí na internetu