> vyvojare SW rozciluje ;-) Udelejte to, at to funguje, a moc si s tim > nehrajte. To je bohuzel cesta do pekel, protoze prvni, druhou a treti > zmenu udelas a pak uz tezko vysvetlujes ze ctvrta bude trvat tyden, pata > dva a sesta bude znamenat dvoumesicni prepis.
No plne souhlasim. Clovek s tim bojuje porad, ale vysvetluj manazerovi ze chces aby se to poradne zanalyzovalo a bylo to pekne navrhnute, kdyz on si nekde na internetu najde neco zdanlive podobneho a rekne ti aby jsi to trochu priohnul a pouzil a zbytecne se v tom nebabral. Ze ten cizi kod (neberu ohled na nejaka dusevni prava vlastnika) dela jen zdanlive to same takze tim stravis plno casu, ale jeste navic bokem pocita pi na miliony mist to jiz je jedno. Takze jsem jiz kolikrat poslouchal manazera kterej mi "vysvetloval" jak to mam udelat ja mu to odkejval a pak jsem si to udelal sam podle sebe. Jinak v realu nebejva asi nic jineho nez si opravdu vybrat z techto metodik jen male casti ktere vam v konkretnim pripade budou opravdu k uzitku. Unit testy psat jenom pro kod kterej se bude menit a bude ho clovek casto testovat, test pro funkcnost ktera ma mnoho ruznych chovani pro ruzne vstupni podminky takze by clovek mohl neco zapomenout otestovat (stylem tohle se skoro nemuze stat doprogramuji to tam pozdeji- a jiz na to zapomenu). Treba nekdy se mi velmi osvedcila metodika s extremniho programovani kdy jsou dva programatori u jednoho stroje a vzajemne si radi a opravuji kod. Ale vsechno je to o tom delat to s rozumem a nesnazit se nejakou metodiku brat uplne doslova, to prinese jednak vetsi naklady, pomalost vyvoje a znechuceni vyvojaru. -- Stanislav Ošmera
