Na twitteru jsem zachytil zajímavé vlákno od Graham Lea (@evolvable). S laskavým svolením autora překládám do češtiny.
Jak bylo na virtuální konferenci FOSDEM.
Jak je to s přístupností mobilního menu z klávesnice? Používáte odkazy “více” a “zde”? Znáte rozdíl mezi aria-label, aria-labelledby a aria-describedby? Je PDF strojově čitelný formát z pohledu zákona o přístupnosti?
Posledních pár let mě baví se zabývat bezpečností aplikací. Čistě technicky. A když člověk tyhle věci implementuje, dostane se k zajímavým problémům, které by ho ani nenapadly. A tak se stalo, že jsem se dostal k proxy. Jako slepý k houslím.
Souhlas
Je to tak.
blabol
Dobra kravina, obhajovat kvadratickou slozitost slovy „je to agilni“ :D usetreny cas proti mape kolik? 5 minut? Hloupoucke uvazovani.
Re: blabol
Ale on ji tak neobhajuje. Takový text by vůbec nestál za otištění. On v několika odstavcích rozebral své důvody. Já věřím, že takhle napsané to má smysl. Ne pro každého, ale s tím nic neudělám.
Optimální kód nemusí být složitý
Článek předpokládá, že čím rychlejší kód, tím nutně musí být složitější. To ale vůbec nemusí být pravda, obzvlášť pokud se použijí knihovní funkce, které jsou obvykle optimalizované. Obhajovat neefektivní kód tím, že je jednodušší napsat, je obvykle jen výmluva. Výkonnější kód také může vést ke snadněji pochopitelnému výsledku, protože i když je třeba složitější, donutí nás to vyčlenit tu složitost stranou.
Proto je lepší se takovýmto botám (kvadratická složitost, kde je triviální dosáhnout lineární) vyhnout už předem.
Re: Optimální kód nemusí být složitý
Já myslím, že v článku je jasně napsané jak ten kód vypadal a jak vypadala optimalizace. Nepřišlo mi, že by se tam nějak zdůrazňovala složitost kódu. Každý kdo umí programovat má jasnou představu, že ta optimalizace byla velmi jednoduchá. Hlavní poučení z článku je, že to že něco vypadá jako špatně napsané nemusí být nutně pravda, protože v kontextu původního zadání/předpokladů to bylo ok.
Co se týká optimalizací, tak jsou dva extrémy: 1. „příprava na 3. světovou a přílet ufonů“, 2. „PNJ = problém někoho jiného…kompilátoru/interpretu/toho kdo ten kód dal na stack overflow…“. Ani jeden z těchto přístupů není správný. Starší generace, pod dojmem šetření prostředků za každou cenu, a vědecké typy inklinují k extrému 1. Mladší či méně zkušení pak k 2. Umění je najít ten správný balanc. No a někdy ten nalezený balanc v aktuálním kontextu nemusí vypadat ideálně, zatímco v kontextu minulém ideální byl. No a právě o tom je ten článek…
Re: Optimální kód nemusí být složitý
Ne, článek nepředpokládá, že rychlejší kód musí být nutně složitější. Ale dobře žes upozornil, že by si to někdo mohl do textu promítnout.
Clanok ma pravdu
Preberal som niekolko velkych projektov. Po prvotnom nadavani som casom „dospel“. Snazil som sa pochopit preco to ten predomno tak napisal (to vzdy pomoze ked pochopite ako rozmyslal ten pred vami). No a teraz uz mam pokoru k takymto kodom. Pretoze viem kedy a ako vznikali. No a ked to vsetko vstrabam tak hura prerobit.
PS: Skusali ste si otvorit svoj 8 rokov stary projekt do ktoreho ste nezasahovali?