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.