Jak nenapsat framework

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.

5 Responses to “Jak nenapsat framework”

  1. R Says:

    Po vystridani dvou financnich instituci za posledniho pul roku je tohle takove prijemne pohlazeni po frustrovane dusi. Zatimco v prvni uz dospeli davno k tomu, ze k frameworku udelali i klikatko (zarez v CV "senior klikac", dekuji, nechci), tak ve druhe zahodili svuj pruvodni framework a napsali si druhy znova....a momentalne pracuji na klikatku v alfa verzi. V druhe instituci jsou i takove novoty jako Spring3. Snad by se dokonce dalo rict, ze nekdo v autorskem tymu toho frameworku sdilel tvoji ideu "lepsi guideline nez framework", ale i to se kapku zvrhlo. A tak mame zakazano do logic bean injectovat, v modelu pouzivat jen specialni typy(String zazbaleny do nejake jine tridy), v JSP pouzivat jen specialni frameworkove tagliby(i na zalomeni radku) a pro povidani s backendy pouzivame 32kB zpravy s pevnym urcenim, co na kterem bajtu ma byt. Takze i guidelines muzou byt hodne "enterprisey".

  2. Franta Says:

    Taky mám tu čest pracovat teď s jedním interním frameworkem. Vyvinout první obrazovku (nebo spíš přidat dvě textová pole) trvalo asi tři dny. Ale pak už to jde snadno. Na těch interních frameworcích je nepříjemné, že je člověk nezná (na rozdíl od různých otevřených veřejných frameworků) a jednak většinou chybí dokumentace, takže je potřeba otravovat kolegy kolem. Ale jinak to zase taková tragédie není – když se do toho člověk dostane, dá se s tím normálně pracovat – pak už nezáleží tolik na tom, jestli je framework interní nebo externí, ale spíš na tom, zda je dobrý nebo špatný. Jinak tohle je asi věčné téma, syndrom NIH 🙂

    Ad „Nechápu proč není stejný přístup i k frameworkům.“

    Protože to zpočátku nejsou frameworky – je to nejdřív součást aplikace, pár udělátek a společných tříd, které mají usnadnit práci – framework se z toho oficiálně stane až časem.

  3. v6ak Says:

    Franta: Ten poslední odstavec tesat do kamene. Vím, že jsem si takto napsal jeden J2ME framework, co se největších takových děl týče. Možná to souvisí s chudým API. U Javy SE jsem se nedostal o moc dál za malou funkcionální nadstavbu (kromě míst, kde jsem se rozhodl, že dostupnými knihovnami to nevyřeším) a Scala to asi celkem úspěšně vyžene.

  4. V Says:

    Tak tak, stejnej pribeh i u me - velkej software house - cilova skupina financni instituce. Zahozeni desitek let vyvoje programovacich jazyku, verzovani, ide, refactoringu a pouzivani proprietarniho frameworku jak jinak s klikatkem s Win3.1 like gui. From autists to autists.

    Btw uz vime, proc banky maji takhle napaleny poplatky za cokoli. Protoze na takovyhle demenci propalej tak minimalne 100 milionu rocne jako nic.

  5. cb Says:

    souhlas. amen. naprosto stejna situace, mozna kolego:D