Denně pracuji s open source (OS) produkty a docela často narážím na fakt, že i ty nejznámější z nich mají své mouchy, někdy i docela závažné. Proto jsem se rozhodl napsat něco o kvalitě těchto produktů. Když ale chceme mluvit o kvalitě, měli bychom si nadefinovat co to ta kvalita vlastně je. Nejvíc se mi asi líbí definice od pana Glasse
Kvalita je souhrn sedmi atributů: přenositelnost, spolehlivost, efektivita, použitelnost (přívětivost), testovatelnost, srozumitelnost a přizpůsobivost.
Když si tak projdu open source produkty, které používám, většinou narazím na nějaký prohřešek proti uvedeným atributům. Teď jsem zrovna asi čtvrt hodiny válčil s instalací kontroly pravopisu do nově nainstalovaných Open Office. Vzhledem k tomu, že nejsem úplný začátečník a řeším to pokaždé, když si nainstaluji novou verzi, myslím, že to je způsobeno špatnou použitelností a srozumitelností. Člověk by tak nějak čekal, že když si nainstaluje českou verzi, tak bude mít českou kontrolu pravopisu nainstalovanou automaticky.
Podobné je to například u Mavenu. Je to dobrý produkt, ale co mi je to platné, když strávím několik hodin hledáním funkčního pluginu. Opět tedy drobný nedostatek v použitelnosti. Nebo například pěkná kryptografická knihovna Bouncy Castle. Funguje perfektně, ale na problém narazíte, když se snažíte udělat něco jenom trochu nestandardního. Přijdete na to, že není moc rozšiřitelná (přizpůsobivá). Ve výčtu bych mohl pokračovat, ale nechám to na vás. Zkuste si projít produkty které používáte a podívat se na ně z hlediska atributů definujících kvalitu.
Důležité je, že problémy s kvalitou nemají jenom OS produkty. Naprosto stejné výhrady můžeme mít i proti komerčnímu software. Minulý týden jsem například ztratil půl dne bojem s Weblogicem, který mi vyhazoval naprosto nesmyslnou chybu. Do teď jsme přesvědčený, že to nebyla moje chyba. Ale i kdyby, kvalitní software by měl být schopný mi říci, co dělám špatně.
Takže, který software je kvalitnější? Komerční nebo open source? Můžeme se na to podívat z několika hledisek. Lidé ho píší dobrovolně, pro radost. Ne proto, že si tím vydělávají na chleba. Mají tedy mnohem lepší motivaci. To má pozitivní vliv na spolehlivost. Na druhou stranu se najde málo dobrovolníků, kteří by dělali ty „nudné“ práce jako je psaní dokumentace, testování a zvyšování uživatelské přívětivosti. Z toho plyne klasický problém OS software – horší srozumitelnost a použitelnost.
Pokud je OS projekt prací více lidí, má obvykle hodně striktní pravidla o tom kdo a za jakých podmínek smí přispívat. S takovými pravidly se setkáte u komerčních projektů méně často. U úspěšných OS projektů je také zažitá kultura unit testů. Z toho samozřejmě plyne testovatelnost – další atribut kvality. To že na projektech pracuje více vývojářů s různými zájmy má také velmi pozitivní vliv na rozšířitelnost. Úspěšné projekty obvykle obsahují prostředky pro snadné rozšíření a přizpůsobení. Často bývají hodně modulární. Další věc, s kterou se v komerčních softwarech setkáme méně často. U některých se naopak setkáme s prostředky zamezujícími rozšířitelnosti.
Velký vliv na kvalitu OS projektů má také evoluce. Nekvalitní projekty prostě nikdo nepoužívá a po pár verzích jsou odsouzeny k zániku. Problém nastane, když existuje jenom jeden projekt s daným zaměřením. Jako příklad můžeme vzít Acegi. Knihovna, která má z hlediska návrhu hodně slabin, ale je v podstatě jediná ve své oblasti. Tudíž nám nezbývá, než se s těmi slabinami smířit. V komerční oblasti efekt evoluce není tak silný. Když dodává nekvalitní produkt velká a známá firma, najde se hodně zákazníků, kteří ho koupí a používají jenom kvůli tomu jménu. Navíc je pro management těžké uvěřit tomu, že může být nekvalitní něco, do čeho investovali tolik prostředků. Jako příklad si můžeme uvést EJB (i když to není produkt ale specifikace). Ty byly šílené co se týče přívětivosti. Kdyby to byl OS projekt tak by ho nikdo nepoužíval. Protože za nimi ale stojí Sun, tak tu straší dodnes.
Stále jsem ještě ale neodpověděl na otázku jestli je kvalitnější open source nebo komerční software. A odpověď je přitom tak snadná: Ani ten, ani onen. Jsou špatné a dobré open source projekty, stejně jako jsou špatné a dobré komerční produkty. Ono se není čemu divit, píší je ti samí lidé.
Já bych to tak hrozně z EJB neviděl, dokonce ani s EJB 2.1, pořád lepší než Annotation Hell…
Navíc, kdyby to nebyla taková pruda, tak teď asi nemáme Spring.
“Pokud je OS projekt prací více lidí, má obvykle hodně striktní pravidla o tom kdo a za jakých podmínek smí přispívat. S takovými pravidly se setkáte u komerčních projektů méně často.”
To snad nemyslite vazne! Uz ste videli komercny software bez restrikcii, vy ano?
tak ty EJB si trocha prestrelil. Vdaka Sun-u za tu specku, plus nevim jestli vis a co z toho vyplyva, ale existuje proces JSR.
Umis si predstavit, kde by byl ted enterprise sektor bez EJB ?
Mozna te omlouva, ze jsi jeste nikdy nedelal na mission critical enterprise projektu, ale potom nepis o EJB ze je nekvalitni. Ma mouchy, to ano, ale na svoji dobu to je i tak majstrstyk.
O tom jestli mám použít EJB jsem dost přemýšlel. Použil jsem je jenom jako příklad něčeho, co mělo do kvality hodně daleko, ale protože za tím stál silný hráč, tak se to nakonec prosadilo. Pokud souhlasíme s uvedenou definici kvality tak zkusme ohodnotit EJB z pohledu jednotlivých atributů
přenositelnost: Zkoušeli jste přenést security nebo správu vláken (WorkManager) na jiný EJB kontejner?
Spolehlivost: Není co vytknout
efektivita: Od té doby co byla přidána možnost použití Local volání docela OK
použitelnost (přívětivost): Díky bohu za Xdoclet (mimochodem open source)
testovatelnost: 0 bodů
srozumitelnost: 0 bodů
přizpůsobivost: jakž takž. Mohl by mi někdo poradit, jak rozjet víc instancí stejné beany s různou konfigurací?
RE:Andrej Opravdu jsem neviděl komerční projekt, který by nepřijal kód protože na něj nejsou unit testy. Tým, který vás nenechá submitnout do repository aniž by to před tím zkontroloval někdo zkušený. Asi mám smůlu na projekty:-\
Podle specifikace není možné mít 2 různě nakonfigurované instance stejné třídy. V EJB je konfigurace striktně per class ne per instance jako ve Springu.
EJB 3.0 řeší hodně problémů – hlavně testovatelnost a přenositelnost (ačkoli jenom částečně – třeba failover a cluster jsou zcela mimo specifikaci) a použitelnost – není jednodušší způsob jak udělat WS než přes Staless Session Bean – btw. nevíš jestli Spring WS umít tyto anotace číst?