Når udviklere undgår en bestemt del af koden, er årsagen næsten altid den samme: Ingen kan se, hvad der går i stykker, hvis noget ændres. Løsningen er at gøre det sikkert, før nogen prøver at gøre det pænt. Teamet skriver først automatiske test rundt om det eksisterende, så de opdager, når adfærden ændrer sig, og laver bagefter små ændringer en ad gangen. Det er et håndværk, som udviklerne kan. Ledelsens rolle er at give det tid, vælge det rigtige sted at begynde og lade være med at kræve en stor oprydning.
Sådan ser det ud fra ledelsesgangen
En direktør ser sjældent koden, men tegnene kan høres. Estimater bliver store, så snart et bestemt område nævnes. Teamet foreslår at bygge noget ved siden af i stedet for at ændre det eksisterende. Én person skal altid med ind over. Fejlrettelser i dette område giver nye fejl andre steder. Ønsker fra kunder bliver afvist med en forklaring, der lyder som “det er ret kompliceret”.
I virksomheder med gamle produkter er det gerne kernen: prisberegningen, afregningen, den store rapport. Altså den del, der bærer forretningen. Derfor har den fået lag på lag af ændringer gennem årene, og derfor er det både det sted, I oftest skal ændre, og det sted, I er mest bange for.
Hvorfor frygten er rimelig
Frygten er en korrekt risikovurdering. Uden automatiske test, som er små programmer, der kontrollerer, at koden gør det, den skal, er den eneste måde at vide, om noget virker, at bruge det. Mange år gammel kode har ingen test, og dens opførsel er kun beskrevet af sig selv. De, der skrev den, er ofte væk.
Det nytter derfor lidt at bede teamet om at tage sig sammen. Så længe de ikke kan se virkningen af en ændring, er forsigtighed det ansvarlige valg.
Rækkefølgen
1. Vælg ét område og sæt en ejer på. Tag det sted, hvor I faktisk skal lave noget i de kommende måneder. Oprydning uden en konkret anledning taber altid prioriteringen.
2. Kortlæg det, I har. Hvad går ind, hvad kommer ud, hvem kalder det, og hvilke særregler kender vi til? Spørg support og de ældste kolleger. Her kommer den viden frem, der aldrig er skrevet ned.
3. Skriv test rundt om det eksisterende. Testene fastholder det, koden gør i dag, også de underligheder, kunder har vænnet sig til. Fagfolk kalder dem karakteriseringstest, fordi de beskriver adfærden, som den er, frem for som den burde være. Brug gerne eksempler fra rigtige kørsler, renset for persondata. AI-værktøjer kan hjælpe med at læse koden og foreslå test, og en udvikler skal kunne stå inde for resultatet.
4. Lav små ændringer. Testene er nu sikkerhedsnettet. Hver ændring gøres så lille, at den kan forstås og fortrydes, og der udgives ofte. Det samme princip gælder mindre og hyppigere udgivelser i det hele taget.
5. Hold øje i drift. Følg fejl og måltal, når ændringen er ude, og hav en vej tilbage. Enkelte ændringer kan rulles ud til en lille gruppe kunder først.
Først når området kan ændres uden frygt, giver det mening at se på, om dele skal skiftes ud, se gradvis udskiftning i praksis.
Ledelsens del
Fire ting kan kun ledelsen gøre.
Gør det til en del af opgaven. Når en ny funktion rører området, indgår testene i estimatet. Så skal arbejdet ikke forsvares for sig selv.
Forvent mindre i starten. De første ændringer går langsomt, og de næste bliver hurtigere. Giv teamet lov til at sige det højt.
Hold mål på sikkerhed frem for skønhed. Spørg, om teamet kan ændre området uden frygt, frem for om det er blevet pænt. Det sidste er uden ende, og det første er en forretningsgevinst.
Hold skylden ude. Den gamle kode har båret forretningen i mange år. Den, der skrev den, gjorde det med det, de vidste dengang. Tales der nedsættende om koden, lukker de ældre kolleger af, og det er dem, I har brug for.
Hvor stopper man?
Kode, der virker og ligger stille, kan blive, hvor den er. Stop, når området er så sikkert, at den planlagte ændring kan laves, og tag det næste område, når I har en anledning. Sådan flytter arbejdet sig med forretningens behov, og gevinsten kan ses i hurtigere estimater på netop dette område. Placér det på listen over teknisk gæld, så det er synligt, hvad der er gjort, og hvad der ligger tilbage.
Det skal I lade være med
- At starte med en stor omskrivning af den farlige del · uden test ved ingen, om det nye gør det samme som det gamle.
- At lade en enkelt person gå i gang alene · så bliver viden ved med at sidde ét sted.
- At kræve en dato for “færdig” · det, I skal følge, er om næste ændring går lettere.
Det skal I kræve af den eksterne
- ☐ En anvisning på, hvor teamet skal begynde, og hvorfor netop dér.
- ☐ En enkel måde at følge fremskridtet på, som ledelsen kan forstå.
- ☐ Plads i køreplanen, der er aftalt med produktansvarlig og salg.
- ☐ Klare ejere for de områder, der er under arbejde.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når én udvikler kender hele koden · Hvorfor går udviklingen langsommere end før?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
