10 ting udviklere gør for meget ud af i store it-projekter

Der er skrevet tykke lærebøger om at udvikle forretningssystemer, men nogle gange kommer man til at bruge for mange kræfter på noget, der ikke gør projektet bedre.

Når man går i gang med at udvikle et stort forretningssystem, så skal den have med alle de gode råd og best practices, lærebøgerne kan diske op med. Eller skal man nu også det? Udvikler og blogger Subhas Dandapani sætter i et blogindlæg et stort spørgsmålstegn ved mange af de ting, der ofte bliver forsøgt i store it-projekter.

1. Udviklerne er klogere end forretningen

Når man som udvikler tænker, at man er langt kløgtigere end de kolleger, der normalt hører til i det, der betegnes som 'forretningen', så kaster man sig også ud i et håbløst kapløb om at lave et system, der opfylder alle de problemstillinger og ønsker, forretningen kan finde på.

Men hvis man løser 1.000 problemer, så skal folkene fra forretningen nok komme med 10.000 ny problemer, de også gerne vil have løst. Der kommer altid flere krav - aldrig færre - og det er ikke en kamp, udviklerne kan vinde.

2. Logikken skal kunne genbruges

Denne faldgrube kendes fra flere store offentlige it-projekter. Man har haft et ønske om at designe en stor logikmotor, der kan bruges af alle dele af systemet. Det kræver generalisering, og det er svært. Derfor bruger man mange kræfter på at lave én motor, der kan alt, når det havde været mere økonomisk blot at lave en lille tilpasset motor til hver enkelt del af systemet.

3. Alt skal være generisk

Lige som arkitekturen kan være generisk, så kan man også prøve at ville lave generiske enkeltkomponenter. Eksempelvis er der ingen grund til at lave en generisk komponent, der kan tale med en database, når en specifik komponent havde været lettere at have med at gøre.

4. Alt skal pakkes ind

I stedet for blot at tage et eksternt bibliotek som det er, så er der stadig mange, der bruger 'wrappers', når der skal bruges noget eksternt. Det er der ifølge Subhas Dandapani ingen grund til i dag.

5. Blinde kvalitetskriterier

Det er muligt at skrive noget så simpelt som Hello World på en så kompliceret måde, at det fylder flere hundrede kodelinjer, men til gengæld opfylder mange af de velmente råd til, hvordan man skriver god kode.

Her kan eksempelvis brugen af interfaces i nedarvning være mere skidt end godt.

6. Alt nyt skal bruges

Mange sprog vil gerne kunne alt, og derfor bliver der tilføjet koncepter, der tidligere var begrænset til specialiserede sprog. Men det betyder ikke, at man skal kaste sig over ting som Generics, Mocks eller Enums, bare fordi det er nyt og smart. Der skal være en grund til at bruge det.

7. Store begreber som 'skalerbart' og 'sikkert'

Når der bliver stillet krav til, at et system skal være 'sikkert', 'skalerbart' eller kunne 'konfigureres', 'udvides' og 'vedligeholdes', så risikerer man at bruge kræfter på noget, der aldrig bliver nødvendigt.

Eksempelvis kan man kræve, at det skal være nemt at skifte den underliggende database ud med en anden, men det er et scenarie, der sjældent bliver brugt i systemets levetid, og kræver en del udviklingsressourcer.

8. Opfinde noget nyt

Det kan være meget tilfredsstillende at skabe et nyt redskab, der lige løser tingene lidt bedre, end det, der allerede findes. Og hvis man gør det til open source, så kan hele verden jo bidrage med at vedligeholde det?

Problemet er, at man ender med at bruge mange kræfter på den efterfølgende vedligeholdelse, for det er ikke sikkert, der er nogen andre, der vil bidrage. Kræfterne er bedre brugt på at bygge videre og bidrage til de værktøjer, der allerede findes.

9. Rør ikke ved noget der virker

Hvis systemet virker, så er der ingen grund til at ændre det, eller sådan kan man fristes til at tænke. Men hvis man skal bygge noget nyt oven på det eksisterende fundament, så er det en god idé lige at tjekke, om det nu også er det bedste grundlag for at nå dér, hvor man gerne vil hen.

10. Tidsplanen holder

Ting tager altid længere tid, end man regner med. Hvis du har travlt, så ender du på et tidspunkt med noget kode, der kunne have været bedre, hvis du havde haft mere tid. Så afsæt tid nok, selvom du gerne vil vise, at du kan kode i et væsentligt højere tempo, end George R. R. Martin skriver romaner. Tænk mere som Scotty på U.S.S. Enterprise og giv et højt tidsestimat.

Læs hele Subhas Dandapanis indlæg for uddybning af de enkelte punkter.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mogens Bluhme

"Eksempelvis kan man kræve, at det skal være nemt at skifte den underliggende database ud med en anden, men det er et scenarie, der sjældent bliver brugt i systemets levetid, og kræver en del udviklingsressourcer."

Det kan da kun give lockin - hvis vi som udgangspunkt ser bort fra NoSQL-databaser bør man som udgangspunkt undgå features, som tit er proprietære á lá stored procedures.

I virkeligheden bør man måske interessere sig for deklarative sprog til interface med SQL-databaser i stedet for artefacts som PLSQL, Hibernate osv.

  • 3
  • 0
Log ind eller Opret konto for at kommentere