1. Vad är en standardkomponent?
Med en standardkomponent menar jag:
- Standardkomponent: En generell komponent skapad för att hantera ett specifikt problem eller problemområde och som används av programmerare världen över. Jag innefattar här även hela teknologier som t.ex. "Web Services" och "Entity Beans".
Standardkomponentens motsats är den skräddarsydda lösningen. En kodmassa som är skapad för att lösa det aktuella problemet och som inte gör anspråk på att lösa något generellt problem.
2. Standardkomponentens styrkor och svagheter
För att en standardkomponent vara till nytta för dig som programmerare krävs följande:
- Nyttig: Standardkomponenten tillför "nyttig" funktionalitet.
- Korrekt: Standardkomponenten är "korrekt" konstruerad.
Om ovandstående två krav är uppfylls så kan programmering m.h.a. standardkomponenter ge följande fördelar:
- Snabbare lansering: Standardkomponenter kan ge en snabbare lansering av nya projekt, eftersom färre delar av applikationen måste skrivas av dig själv. Detta ställs dock mot inläsningstiden om komponenten är okänd.
- Färre buggar i produkten: En standardiserad komponent innehåller i allmänhet färre buggar än en skräddarsydd komponent. Eftersom en standardkomponent utnyttjas av tusentals programmerare världen över blir standardkomponenten testad i högre utsträckning än den skräddarsydda, vilket medför att de flesta buggar upptäcks tidigt. För att detta ska gälla måste självfallet kompoenten användas rätt, vilket kräver en viss kunskap om komponenten.
Standardkomponenten har följande nackdelar:
- Högre kunskapskrav: Innan man kan börja utnyttja standardkomponenten måste man vara "påläst" på den. Detta kan ta förvånande lång tid för en större teknologi! Ju fler standardkomponenter man vill använda i sitt projekt, ju längre tid måste programmeraren lägga på att utbilda sig på de komponenter som är okända innan han/hon kan komma igång. Om projektledaren eller programmeraren inte har tålamod för denna startsträcka är det lätt att man ger upp och börjar skräddarsy en lösning, bara för att komma igång.
- Sämre prestanda: Att använda en generell komponent ger ofta sämre prestanda än om en lösning skräddarsys för problemet.
3. Exempel: Införandet av Webbtjänster
Problemställning: Ett programmeringsteam står inför uppgiften att bygga en integration mellan två mindre applikationer, båda driftas på var sin server på företagets interna nätverk. IT-chefen har fått följande förslag på hur man ska sköta överföringen av data mellan applikationerna:
- Någon tycker att man ska överföra datat som vanliga textsträngar, returnerade av en Servlet. Strängen byggs enligt ett hemmagjort protokoll, och klienten gör någon typ av stringmatch på strängen för att klura ut vilket svar man fått.
- Någon annan tycker att man kan förbättra lösningen genom att låta Servleten returnera ett XML-dokument. I Servleten byggs XMLen ihop genom att klistra ihop taggar "manuellt". Den anropande klienten tolkar svaret genom att bygga ett DOM-träd av XMLen. Här har teamet använt standarden XML, detta är en teknik som teamet behärskar.
- Någon tredje tycker att de ska utnyttja webbtjänster (Web Services) som trots allt är standardkomponenten för denna typ av lösning. Ingen i teamet har någon erfarenhet av webbtjänster från tidigare projekt, så därför räknar de med att det kan ta en del tid att bekanta sig med tekniken.
IT-chefen tror att en arkitektur med Web Services på sikt kommer att höjja produktiviteten för programmerarna. Men å andra sidan är gruppen för tillfället underbemannade så det är mycket svårt att avvara den tid det tar för programmerarna att läsa in sig på den nya teknologin. Vad ska IT-chefen göra? Att hitta rätt "höjd" på lösningen verkar vara ett ständigt återkommande problem.
4. När ska man använda standardkomponenter?
Själv tror jag att valet av hur många standardkomponenter man vill utnyttja i sitt projekt bör bero på följande faktorer:
- Uppgiftens storlek: Är uppgiften mycket liten lönar det sig ofta att skräddarsy. Det är ingen idé att ta till en tung komponent för att lösa ett litet problem som uppkommer en gång. Få IT-chefer skulle acceptera att en programmerare lägger 3 månader på att installera och lära sig en standardkomponent om uppgiften som ska lösas bara tar en dag att skräddarsy. Om problemet är återkommande kan det däremot vara bättre att använda standardkomponenter, eftersom man då kan börja dra nytta av de fördelar som beskrivs ovan.
- Organisationens generella strategi: Vart är organisationen på väg? Är organisationen nära ruinens brant? Då är det kanske ingen idé att tänka långsiktigt. Är organisationens ekonomi stabil? Då kan det vara en mycket god investering att låta teamet läsa in sig på den standardiserade komponenten.
5. Not invented here
I vissa organisationer kan det finnas en motvilja mot standardlösningar. Motviljan grundas på:
- En tro på att de komponenter som utvecklas lokalt är "bättre" än de komponenter som har blivit standard. Världens bästa programmerare jobbar ju (som alltid) i den aktuella organisationen.
- En allmän ovilja att pröva/lära sig nytt.
Fenomenet kallas för "Not invented here", och betyder något i stil med "Om det inte är uppfunnet här är det inget att ha". I en organsiation med denna attityd kan det vara svårt att införa standardkomponenter.
