God kode er som rene underbukser

14. august 2009 af Sara Redin | cms, kodning | Ingen kommentarer

Er programmeringsarbejdet på din CMS-løsning så godt at du nemt kan udskifte din implementeringspartner?

Består dit CMS den store helbredsundersøgelse?

En god udvikler jeg kender, plejede at sige, at ligesom man ville være ekstra opmærksom på, hvilket undertøj man tager på ved et lægebesøg, kunne han godt lide, at hans system så pænt ud, når andre skulle kigge i det. Sagen er den, at du jo aldrig kan vide om din dag ender ved lægen eller om du ender med at skulle invitere nye udviklere ind i dit CMS. Rent undertøj og god kode tænker man sjældent over når det bare er i orden, men det kan fylde alt når tingene spidser til.

Desværre kan det være svært for ikke-teknikere at se, om et system er gedigent kodet eller bare en stor lappeløsning – i hvert fald ved første kig. Over tid vil tegnene på at koden ikke er helt ren dog kunne aflæses af alle.

Er der tegn på problemer med din kode?

Rømmer din udvikler sig, når du spørger til, hvornår I skal opgradere til næste version? Er det svært at få nye funktionaliteter til at virke eller oplever du ofte, at små forbedringer på hjemmesiden skaber store, uforudsete sammenbrud? Måske har du også prøvet at skifte implementeringspartner, men har fundet, at estimatet for at sætte sig ind i dit system – selvom det er et standard CMS – virkede urealistisk højt. Måske har du nået så langt, at du føler dig stavnsbundet til din nuværende implementeringspartner og at du sidder fast i et system, der slet ikke holder det, det lovede, da du købte?

Hvordan fik du bremsespor i koden?

Hvis du er blevet så utilfreds med din løsning, at du overvejer at skifte CMS, er du ikke alene. Mange af dem, der ender med at skulle vælge en ny løsning før de havde tænkt sig, gør det fordi den de har, ikke kan repareres for rimelige penge. Inden du skifter er det dog en god idé at se på hvilke faktorer, der var med til at ødelægge din løsning:

1. Manglende erfaring i projektgruppen

Det er ikke en fordel, at være den første organisation, der implementerer en ny version af et hvilket
som helst system. Du skal helst kunne sammensætte et projektteam, hvor de centrale udviklere har arbejdet med systemet før. Hvis det ikke kan lade sig gøre kan du spare både tid og penge ved at vente til den nye version er blevet taget i brug af flere.

Hvis du selv mangler erfaring med og viden om det nye system er det en god idé at tale med andre kunder, som har været igennem et projekt med det system du har valgt, inden du gentager deres fejl. Stil også krav til at dine udviklere gør det samme og lav en aftale om hvem, der betaler udviklernes lærepenge igennem projektet.

2. Mangel på dedikerede ressourcer i projektet

Det er problematisk, hvis for mange af udviklerne på dit projekt ikke kan være tilknyttet projektet på fuld tid igennem hele forløbet. Sørg for at holde produktionsperioden så effektiv som muligt, sådan at de tilknyttede skal bruge mindst mulig tid på at sætte sig ind i projektets udvikling fra dag til dag. Ressourcer tilknyttet på fuld tid vil også helt naturligt være mere engagerede i dit projekt. Som kunde kan du sikre, at udviklere kan arbejde effektivt og dedikeret ved at prioritere test af delleverancer og besvarelse af spørgsmål. Der kan også være en fordel i at vente lidt længere med projektstart, hvis det betyder, at dine udviklere kan være allokerede til dit projekt fuld tid.

3. Sjuskede tests

Husk at teste ordentligt. Lad være med at stole på, at delleverancer er som de skal være, hvis du ikke har været dem helt igennem. Det er dit job at have en konstruktiv dialog med dit hold af udviklere. Fejl kan også være tegn på fundamentale misforståelser, som det er vigtigt du får aflivet inden hele løsningen skal kodes om for at problemet kan rettes.

4. Ingen tager ansvar for kodens fremtid

Udviklere, som ved at de skal lave opgraderingen til næste version af et system, er mere ansvarlige og engagerede i at fremtidssikre og dokumentere sin kode, for dem er det hjælp til selvhjælp. Det er måske også derfor, vi i vores erfa-netværk ofte oplever, at kunder med interne udviklere tit har nemmere ved at opgradere og optimere på sit CMS end kunder, hvor disse opgaver lægges ud af huset.

Sådan slipper du for dårlig kode

Hvis du vil gøre det så nemt og billigt som muligt at arbejde med forskellige implementeringspartnere, lave opgraderinger og ny funktionalitet, er følgende råd værd at overveje:

1. Undgå udskiftning af udviklere på projektet undervejs

Sørg for, at der i hvert fald er en eller to seniorudviklere med flere lignende projekter under bæltet tilknyttet igennem hele projektet.

2. Giv plads til oprydning og optimering af koden ved projektets afslutning

Kode er som en tekst; den skal redigeres og kortes ned for at være nem at finde rundt i for andre end dem, der har lavet den. Ligesom i en tekst kan ting formuleres langt eller kort og nogle gange kan et kort afsnit erstatte flere sider tekst. Ligesom når man skriver, kan det dog også være, at disse smarte løsninger først er synlige, når projektet er ved at være slut.

3. Test hele løsningen inden du godkender den endelige levering

Bliv ved med at teste hele løsningen, hver gang du får leveret en ny funktionalitet. Selv små ændringer kan have betydning for resten af løsningen så derfor skal du huske at genteste ting, som du har godkendt tidligere. Du kan med fordel bruge en automatiseret test som metodisk gennemløber hele løsningen og laver en rapport over fejl. Manuelle og automatiserede test supplerer hinanden godt, da de fleste mennesker ikke kan holde ud at teste de samme ting igen og igen. Undgå derfor også at bruge projektmodeller der er baseret på vandfaldsmodellen. Sørg for at du i dit projekt løbende får delleverancer og mulighed for at teste.

4. Overvej at lade koden blive valideret af en tredje part

Hvis det er vigtigt for din organisation at nemt kunne skifte mellem forskellige implementeringspartnere, skal dette måske testes i forbindelse med dit første projekt også? En måde at gøre det på er, at lade den næste fase af dit CMS-projekt blive udført af en ny implementeringspartner, eller at udskille en del af projektet som en opgave der SKAL laves af nogle andre end dem der har fået den større opgave med at etablere en ny platform.

Det betaler sig at have rene underbukser

I det lange løb kan det godt betale sig at have orden i sagerne. CMS-markedet er stadig umodent, der er stor udskiftning af personale ved implementeringspartnerne og du kan før end du tror det få behov for at invitere en ny udvikler ind i dit system.