Dne 1. srpna 2010 10:43 "Zdeněk Troníček" <troni...@fit.cvut.cz> napsal(a): > Oto Buchta napsal(a): >> b) trošku mi to připomíná schizofrenii jednoho známého webdesignéra. >> Dostal za úkol vyvinout velkou JavaScriptovou aplikaci. Vyvíjel ji na >> MACovi a safari a za pár měsíců byla téměř hotová. Chybělo posledních >> pár bezvýznamných nedodělků, když dostal za úkol rozchodit aplikaci i >> na ostatních prohlížečích. Chrome mu zabral den (používá také WebKit), >> Opera fungovala, s ohnivou liškou se mořil dva týdny a MSIE nedal >> vůbec. Qůli MSIE pak musel tuto aplikaci celou přepsat... Prostě "bad >> by design", neboli jak říkáme tu u nás - z hovna tatar neuděláš. Velmi >> obdobně to skončilo s NetScapem (mozilla byl kompletní přepis, skoro >> všechno se zahodilo). Ve světě Javy tu máme dva exemplární příklady >> kompletního přepisu qůli výkonnosti: Xerces a Axis. > > Tady patrne zaspal architekt, ktery si mel na zacatku rici, v jakych > prohlizecich ta aplikace pobezi a podle toho vybrat, v cem se to bude > implementovat. A i kdyz tam MSIE nepatril, tak mel mit v seznamu rizik > portaci na MSIE a byt na ni pripraven. Dobry architekt se stara o rizeni > rizika.
Pokud vim, tak vetsina webaru vyviji prave takto (mozna znate jine vyvojare). MSIE se kontroluje nekdy prubezne, nekdy ex-post, podle zpusobu navrhu aplikace. Pro MSIE se vzdy musi hledat nejake obezlicky, jak zarucit zarucit chovani. Naprosto vymluvne je http://en.wikipedia.org/wiki/Acid3 A nedokazu si predstavit, ze by MSIE nebylo nutnou podminkou. >> Čitelnost je samozřejmě VELICE důležitá. Nelze ji ale prosazovat za >> každou cenu. Mohu-li pro numerický výpočet hodnoty použít Newtona, >> proč místo toho používat čitelnější půlení intervalu? Proč třídit >> prostým hledáním prvků od největšího po nejmenšího, když jsou tu >> bublina, QuickSort či MergeSort? > > Pouzivani efektivnich algoritmu je samozrejme spravne. Ani tato zasada > ovsem neni zadna mantra. Kdyz budes vyhledavat v serazenem poli 100 > celociselnych hodnot, tak je jedno, zda to bude sekvencne ci binarnim > pulenim. A pokud bys mel to binarni puleni sam programovat, tak je lepsi > pouzit sekvencni vyhledavani, protoze je to kratsi a je mene > pravdepodobne, ze v tom udelas chybu. > Jinak ale: EFEKTIVNI ALGORITMY SAMOZREJME ANO. Citelnosti jsem mel na > mysli citelnost na urovni prikazu. Tj. napr. misto > > y = x++ + ++x; Fuj! ;-) > Z toho co pises se bohuzel nedovidame, jak Ti praxe v roli oponenta kodu > pomaha ve vyhledavani "horkych" bodu v programu. Aha. Role oponenta je prave v tom upozornit na problematicky kod. A opravdu se tomu da naucit, che to jen cvik. >>> Navic, dokud neni potreba >>> optimalizovat, nema smysl nejakou optimalizaci delat. >> >> Člověku, který toto prohlásí, patří vytahat za uši. A možná i >> preventivně každé pondělí ráno. > > Odpovim Ti znamym citatem z roku 1974 (slovy: devatenactsetsedmdesatctyri): > > "We should forget about small efficiencies, say about 97% of the time: > premature optimization is the root of all evil." Prestoze je tento citat o necem malinko jinem, presto s nim nesouhlasim. Presto si samozrejme mnoho z vas spolu s Cimrmanem rekne: "Je mozne, ze se vam to nelibi, muzete s tim dokonce i nesouhlasit, ale to je to jedine, co s tim muzete udelat." Pokud to totiz clovek zabali hned po zjisteni vysledku, nemuze se nikdy dobrat neceho lepsiho. Ono totiz dopredu vedet, ze se souhrn vsech optimalizaci nedosahne lepsich vysledku nez tri procent, je nesmysl. -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
