Vývojář Marek si pro vás, milí čtenáři, připravil zamyšlení na pokračování. Aneb trochu filozofického zamyšlení ještě nikdy nikomu neublížilo.
Při každém rozhodnutí ohledně architektury software se jako jeden z faktorů řeší i dilema optimalizace versus obecnost.
Je-li kód dostatečně obecný, umožňuje efektivní znovupoužitelnost. Je-li tato obecnost navržena s maximálním ohledem na „křivku učení”, stává se kód opravdovým prostředkem rapidního vývoje. Co se dá snadno naučit a použít v nových situacích, je automaticky tím správným stavebním kamenem na tvorbu moderních informačních systémů. Takže co tady vlastně řešit? Tvořme prostě obecný kód, řešme problém jednou a používejme řešení toho problému lidsky příjemným specifikováním jednotlivých zvláštností!
Problém pak nastává v rychlosti obecného kódu. Projdeme si celý tento prostor postupně:
Nejrychlejší jsou špagety, ale...
V zásadě každý architektonický prvek sloužící k přehlednému a znovupoužitelnému kódu s sebou nese provozní režii navíc.
Optimalizace kódu totiž znamená naopak vypouštění nadbytečně obecných pasáží a kódování maxima funkcionality na míru, „natvrdo”. Netýká se to jen problematiky obecných API a expresivních nástrojů na formulaci dílčích problémů, jako je např. ORM nebo i template engine jako takový.
Funkce jsou rychlejší než hierarchicky bohatý objektový model. A pokud chcete opravdu něco hodně rychlého, zapomeňte na skriptovací jazyky a použijte C.
Pokud se na situaci díváme z této strany, je nejvýhodnější provozovat plochý kód přímo na míru, "staré dobré „špagety”. Pokud něco takového průmysl opravdu potřebuje, proč se starat o pohodlí „IT dělníků”, čili programátorů? Nemají být profesionály, kteří jako každý jiný zaměstnanec musí snášet i nepohodlí? Rovnou si tedy shrneme, proč je takový přístup vlastně neekonomický.
Berte ohled na vývojáře
Baťa správně pochopil, že prostý tlak na pracovitost nepřinese žádnou další, novou konkurenční výhodu. Koupil stroje, naplánoval efektivní výrobu a - o své zaměstnance se dobře postaral. Chápal, že efektivita je součinem motivace pracovníků a prostředků pro zvýšení efektivity práce. Bral ohled na ševce: vytvářel maximálně příjemné pracovní podmínky a respektoval běžné, normální limity lidských schopností.
Stejně tak je třeba brát ohled na vývojáře. Vývojář je spolehlivý, pokud se netopí v chaosu oněch „špaget”. Jeho efektivita stoupá, když není přetěžován znovuvytvářením různých kol. To se ostatně začne s rostoucí složitostí soukolí značně prodražovat.
A hlavně je vývojář produktivní, pokud cítí respekt před používanými technologiemi a dokáže se tak ztotožnit se svojí rolí v naplnění konkrétní funkcionality.
Z tohoto úhlu pohledu je to opět jasné: Jestliže je vývoj i o složité byrokracii a častým smyslem software je právě zjednodušovat byrokracii, nemá být snad samotný proces tvorby software „první na řadě” s péčí o efektivitu? Není tvorba efektivních vývojářských nástrojů pak jednoznačně základním předpokladem vývoje konkrétního software, který bude zákazník vůbec ochoten financovat?
Dilema: rychlost nebo spolehlivost
Takže je tu opravdové dilema: rychlost plynoucí z jednoduchého a špatně spravovatelného kódu nebo spolehlivost plynoucí z přehledného vývoje?
Klasické řešení spočívá v hledání jak rychlých, tak obecných a příjemně použitelných řešení. Jejich výčet a zhodnocení by vydalo za celý seriál. My se ale rovnou podíváme na unikátní přístup, který k tomuto dilematu zaujali tvůrci Drupalu.
Vytvořili prostě další kulatou krychli a my si nejdříve řekneme, v čem spočívá kulatost krychlí na několika příkladech.
Přehled kulatých krychlí
Kompilovaný kód je rychlý, interpretovaný se snáze vyvíjí. Nešlo by ale mít obojí? Ano, odpovědí je bytekód. Uloží se v binární podobě mezivýsledek překladu zdrojového kódu. Interpret jej pak prostě jen znovu použije.
Omezená instrukční sada (RISC) umožňuje levnější výrobu procesorů a jejich větší pružnost. Roste ale délka strojového kódu. Naopak CISC umožňuje efektivnější strojový kód, ale výroba je dražší a náchylnost k poruchám vyšší. Nešlo by mít výhody obojího? Ano, RISC architektura s implementovanou softwarovou vrstvou na kódování složitějších instrukcí, která je ale rychlá a větší počet instrukcí s úspěchem emuluje. Je to opravdu i pružné řešení.
Zpět k našemu problému: Rychlost je třeba na provoz a obecnost s expresivitou na vývoj. Nešlo by teda mít obojí? Přesně tuto otázku si takto po vzoru dobrých IT inovátorů položili i tvůrci Drupalu a nalezli opověď „Ano”. Učinili tak poměrně originálním způsobem, který si popíšeme v následujícím díle tohoto seriálu - Levný vývoj nebo levný provoz? A což takhle to neřešit?
