- There is no silver bullet
- Om något pushas som det bästa sen sliced bread så är det nåt grundläggande fel nånstans
- Det är (faktiskt) inte alltid fel att uppfinna hjulet igen (eller kanske inte hjulet, men kanske chassit, karossen och inredningen för att fortsätta på den något krystade bil-liknelsen)
Här kom en spec, en standard som skulle lösa alla mina problem - persistens, distribuerade lösningar, messaging och en hel massa annat. Sun, i sin oändliga vishet, publicerade en "show case"-app i form av "pet store" full av
J2EE-patterns att använda för intet ont anande utvecklare världen över.
Inte nog med det - "Enterprise" i namnet gjorde att management i tusentals företag också svalde betet. Att använda J2EE blev ett slags kvalitetsstämpel; en garant för att lösningen var byggd på solid grund, lätt att underhålla och skala upp.
Hej vad vi alla bedrog oss. Om man bara hade använt sin (iofs på den tiden betydligt kortare) erfarenhet och utbildning och verkligen läst specen istället för att kasta sig över ett kodexempel och med ett fånigt flin på läpparna sjösätta sin första Entity Bean i nån mer än lovligt buggig och seg 'container'.
Vad som framgår som pinsamt tydligt nu i ett förklarat ljus är att J2EE-specen var ett typiskt 'Design by Commitee' piece of crap. En kopp komplexitet tillsammans med fyra liter configuration i form av XML och sex matskedar magi - vad containern har för sig under huven visste man inte riktigt (och det var ju inte meningen att man skulle behöva veta det heller). Lycka till förresten med att sätta en debug-stopp långt inne i JBoss mitt i nån ConfigurationFactoryManagerFactory eller nåt som är i full färd med att instansiera sig själv utifrån nån vidrig XML-blobba.
Applikationerna blev precis det motsatta mot vad som utlovades:
- Skalbarhet - my ass. Nåt segare än en J2EE-applikation med Entity Beans går inte att uppbringa. Det är datavärldens motsvarighet till en bil med prestanda från en Trabant och komplexitet hos en Ferrari F1
- Maintainability - tanken var att eftersom allt var byggt efter en enhetlig spec skulle man kunna byta utvecklare i ett projekt lika ofta som man byter kalsonger. Vem som helst skulle kunna kliva in och vara produktiv på en gång. Detta föll genast eftersom alla var tvungna att kringgå den vidriga specen med hembyggda lösningar (som ofta blev mer eller mindre de facto patterns för J2EE-utveckling) som t ex "fast lane" (dvs gå direkt med JDBC mot databasen för att göra saker som inte gick att göra med J2EE (som att läsa upp fler än 10 objekt t ex (hmm, ett persistensramverk som inte fixar att läsa upp ett tjog objekt eller så från databasen borde ju fått folk att tänka efter)))
- En tredjeparts-marknad med färdiga komponenter färdiga att bara drag-and-droppa in i din container och vips så funkar allt! Att bygga ett system skulle bara kräva en systemdesigner (gärna i kostym) som i samråd med beställaren grafiskt drar-och-släpper komponenter i en grafisk högnivå-utvecklingsmiljö. En luttrad utvecklare inser kanske att det är omöjligt att t ex komma fram till en generell definition av ett så basalt begrepp som 'användare'. Vissa system behöver user name och mail address, medan andra behöver längd i cm och hårfärg. Marknaden för tredjepartskomponenter blir snabbt begränsad till komponenter för typisk generell funktionalitet - mail-skickning, och messaging t ex
J2EE är en typisk 80-20 deal. Det går bra att utveckla 80 procent av din applikation (om du kan stå ut med att den är seeeeg), medans resterande 20 procent är omöjlig att utveckla eller måste byggas i strid med vett och sunt förnuft för att kringgå alla hinder som J2EE lägger i vägen.
No comments:
Post a Comment