Zkusil bych rozdelit odpoved na 2 casti: 1) neschopnost zakaznika zadat praci: Je vice zpusobu, jak donutit zakaznika potvrdit co chce. Vyzkousene v nasem pripade jsou use case diagramy jako specifikace pozadavku na aplikaci (strategicka analyza toho co zakaznik vlastne chce). Pote nasleduje analyza procesu atd - funkcni specifikace atd.. Takze takova modifikace UP. V pripade, ze zakaznik doopravdy poradne nevi co chce se mi libi agilni metodiky. Proste jsou mnohem vic prizpusobene tomu, ze zakaznik tape. Takze se proste integruje do vyvoje... Stejne tak se osvedcuje americky :) zpusob mysleni (nefunguje? zahodit, napsat znovu, perfekcionismus je zbytecny). Teda nevim jestli neco jako americke mysleni existuje, akorat se clovek ze vsech knih o softwarovem vyvoji dozvida neco takoveho :).
2) psani testu. Viz a 1) Test pisu uz na pozadovanou funkcnost. Diky testu si muzu ujasnit co vlastne chci napsat. Co se tyce usetreni casu, tak testovani funkcnosti nekdy vypada nasledovne: maven jboss_war_only -> pockam az se war nahraje na jboss /-> proklikam se v pozadovane fcnosti -> jestli je vse ok, dobre. JEstli ne tak logger.debug .. nebo debug primo na Jbossu. Jestlize zaberu cas tim, ze napisu test a ten mi projde, tak mam teoreticky zaruceno, ze nektere chyby jsou odchyceny a testovani na serveru muzu minimalizovat. (nemluvim o J2EE vecech co jsou vyzadovany po JBossu ale predpokladam, ze diky architekture JBosse by se to dalo taky otestovat). DH >>> [EMAIL PROTECTED] 28/03/06 07:11odp. >>> Nejake testy dopredu je urcite pekne napsat, ale nakolik to skutecne delate v normalnim produkcnim prostredi ? Nepocitam nejake male projekty pro sebe. V normalnich projektech zakaznik vetsinou poradne nevi co vlastne chce, ale musi to bejt nasazeny do pul roku. Takze na tom zacne delat celej tym a jeste nez je vlastne hotova analyza tak se jiz programuje, za behu se to meni, mesic pred odevzdanim kdy ukazujete zakaznikovy nejakej prvni malo funkcni prototyp se ukaze se to vlastne takhle moc nechtel a to co bylo v zadani vagne specifikovano jako malej prirucni sklad je nakonec skladove hospodarstvi na samostatnej system (samozrejme chyba obchodniku kteri neco tak nedokonale popsaneho zaridili). A to je realita. Takze nejake testy dopredu se moc nedaji napsat protoze na zacatku vypada ze fukce fce(a,b) ma vratit soucet tech cisel, ale nakonci vraci soucin, takze by jste v prubehu museli ty testy desetkrat prepisovat. A to ze neco nekde nefunguje uplne dobre protoze to neproslo dobrejma testama vadi vetsinou zakaznikovy daleko mene nez to ze jste nestihli termin o mesic. (samozrejme nepocitam ze delate program pro banku, i kdyz tam bych mohl taky vypravet co se clovek vsechno nedovi). Mam pocit ze heslem dnesniho programovani je strej vtip kterej se vypravel o prvnim chybovem pentiu: Kolik je 2+3 ? Pentium: 6 To ale neni pravda, vysledek je 5 Pentium: to nevadi, ale je to rychle.
