Včera jsme v hospodě s kolegy probírali krásy interních frameworků, vzpomněl jsem si na svůj starý příspěvek, který jsem před téměř pěti lety napsal. Tenkrát to bylo pod pseudonymem, abych nenaštval zákazníka, teď už si to troufnu i podepsat. Nevím jestli se za těch pět let něco změnilo, ale myslím že to stále stojí za “přetištění”. Takže tady to je:

Před pár týdny jsem začal pracovat na projektu pro jednu velkou českou finanční společnost. Projekt je vyvíjen za pomocí frameworku, který byl vyvinut speciálně pro tuto instituci. A v tom je právě ten největší problém. Framework místo toho, aby práci programátorům usnadňoval, tak ji komplikuje a zpomaluje. A to několikanásobně. Vyvinutí jedné nepříliš složité obrazovky trvá programátorovi několik dní! A to jde jenom o obrazovku, aplikační logika se do toho nepočítá. Na straně aplikační logiky je to o trochu lepší, práce probíhá rychleji, ale abych pravdu řekl, objektovému programování se moc nepodobá. Spolu s klasiky bych mohl říci, že jsem si pokaždé, když jsem narazil na slovo interface, udělal čárku. Víte kolik výskytů jsem napočítal? Ani jeden přátelé. V tomto článku si nechci stěžovat. Chci se jen zamyslet čím to je. Vím že to není problém jen této instituce a tohoto frameworku, slyšel jsem o několika jiných, mnohem horších případech.

Nejprve se zamysleme jaká je motivace pro napsání frameworku. Odhlédněme od faktu, že to musí být neuvěřitelně zajímavá práce, kterou by si chtěl asi vyzkoušet každý programátor. Hlavní motivací bezpochyby bude, že ve velkých společnostech pracuje mnoho různých týmů, obvykle od externích dodavatelů. Každý tým používá jiné technologie, postupy a jmenné konvence což je pro velkou instituci obvykle problém. Je tu proto snaha vývoj nějakým způsobem sjednotit. Pokusím se nastínit proč si myslím, že vyvinutí vlastního frameworku nemůže tuto snahu nikdy naplnit.

Za prvé, pro napsání frameworku potřebujete špičkové programátory s přehledem v oboru a se znalostmi a zkušenostmi s psaním frameworků. Musí vědět jak má takový framework fungovat a hlavně se musí poučit z chyb svých předchůdců. Je zřejmé, že se lidé takovýchto kvalit hledají těžko.

I kdybychom měli jenom špičkové a zkušené programátory, málokdy se framework podaří napsat správně na první pokus. U takto rozsáhlých projektů zákonitě musí dojít k chybám v návrhu, nedotaženosti na jedné straně a přílišné složitosti na straně druhé (obdobně jako u specifikace EJB, kterou rozhodně nenavrhovali amatéři). Pokud by bylo snadné udělat v návrhu změnu, nebyl by to problém. Na problémy se ale obvykle narazí až při použití někým jiným než autory. To už ovšem bývá framework označen za hotový a management pochopitelně odmítá investovat do nějakých zásadních změn. Jinými slovy, framework se musí podařit hned napoprvé, což je skoro nemožné. Chyby v designu tedy zůstávají a uživatelé frameworku musí nalézat cesty, jak je obcházet.

Dalším velkým problémem podomácku napsaných frameworků bývá špatná dokumentace. Přiznejme si to, snad nikdo nepíše dokumentaci rád. Ale u frameworku je to kritický nedostatek! Pokud máte používat API, které je nekvalitně zdokumentované, je to velký problém.

V neposlední řadě musíme zmínit chybovost. V každém softwaru je chyba. U frameworků je kvůli jejich komplexnosti náchylnost k chybám ještě větší. Navíc, chybu v normální aplikaci mohou odhalit testeři. Framework mohou testovat jenom programátoři, což není právě ideální situace. U testování se můžeme chvíli zdržet. Správně by se u každého programu mělo testovat to, jak odpovídá specifikaci. Musím se přiznat, že si nedokážu představit funkční specifikaci frameworku. Tedy rozhodně ne takovou, která by šla použít jako podklad pro testy. Management se tedy musí spolehnout na programátory a věřit jim, že je framework dobře otestován.

Pro frameworky asi platí základní pravidlo jako pro jiné obecné softwarové komponenty, které zní: „Doma to sami nezkoušejte“. Doufám, že by se v dnešní době všichni dívali jak na blázna na člověka, který by přišel s tím, že si napíše vlastní OR mapovací nástroj. Vždyť existuje několik řešení, z nichž i ty komerční musí vyjít levněji, než vývoj vlastního. Nechápu proč není stejný přístup i k frameworkům. To si opravdu všichni myslí, že jsou jejich potřeby natolik jiné, že pro ně neexistuje již prověřené řešení?

Zamysleme se nad tím, jak tyto podomácku psané frameworky nahradit. Nejpřímočařejší řešení je sepsat dokumentaci o tom, co musí všechny aplikace v instituci splňovat. Tzn. omezit chaos způsobený různými přístupy týmů „administrativně“. Můžeme nadefinovat sadu nástrojů a knihoven, které se mají pro vývoj používat, nadefinovat konvence které se mají dodržovat. Je samozřejmě také nezbytné dělat code review (inspekce kódu) pracovníky instituce, aby se ohlídalo, jestli ten který projekt příliš neujíždí od jednotného standardu. Tyto kroky se ostatně používají i při použití frameworku. Dalším důležitým krokem je poskytnutí základní sady knihoven či služeb například pro SSO. Tyto knihovny by ale rozhodně měly být jenom lehkou nadstavbou nad již existujícími řešeními. Myslím si že tento postup je mnohem účinnější a efektivnější než vynakládat miliony za framework, na který budou v lepším případě všichni jenom nadávat.

Představme si, že by například velká banka investovala čas několika lidí na výzkum existujících řešení problémů, které ji pálí.

Po pár měsících by mohl tento tým přijít s tím, že jejich potřebám nejlépe vyhovuje např. použití JSF pro UI, Hibernate pro perzistenci a Spring pro propojení a konfiguraci. Nadefinovala by se pravidla, jak tyto nástroje používat (tady pozor na ohýbání technologií pro účely na které nejsou určeny). Nadefinovaly by se jmenné konvence, kam ukládat jaké zdroje atp. A to je vše. Tento postup přináší několik nesporných výhod. Zaprvé je mnohem levnější. Pokud dobře zvolíte open sourcové projekty, máte často zdarma velmi kvalitní dokumentaci, přístup ke zdrojovému kódu, upgrade a opravy chyb. V neposlední řadě, programátoři z externích firem tyto technologie budou pravděpodobně znát, takže nebudou muset trávit spoustu času studováním dokumentace a lamentováním proč mají sakra používat ten …. framework.

Na závěr bych chtěl případné čtenáře požádat o jejich zkušenosti s podomácku psanými frameworky. Doufám, že tento článek odradí alespoň jednoho člověka od napsání si vlastního frameworku a tím zachrání pár dalších programátorů od osudu psát v Javě procedurálně stejně jako ve Fortranu.