Total omskrivning eller trinvis refaktorering: Hvad er rigtigt for jeres kodebase?
Tag udgangspunkt i trinvis refaktorering, og skriv kun om fra bunden når der er tydelige grunde til det. Totale omskrivninger bliver næsten altid undervurderet, for de starter fra nul og mister årevis af skjulte regler. Nyudvikling kan begrundes med en forældet platform eller en videreudvikling der er gået i stå. Ellers hæver du kvaliteten stykke for stykke i drift.
Før eller siden bliver ethvert system gammelt. Koden bliver sværere at ændre, nye funktioner tager længere og længere tid, og nogen foreslår det der lyder så befriende: Riv det hele ned og byg forfra. Fristelsen er stor, men statistikken er dyster. Her gennemgår vi hvordan du vejer en total omskrivning op mod en trinvis refaktorering og hvorfor det sidste som regel vinder.
Omskrivningens tiltrækning og dens fælde
At starte forfra på et blankt stykke papir er en af de mest forførende idéer inden for software. Den gamle kode er rodet og uforståelig mens det nye kun findes i hovedet: rent, elegant og færdigt. Fristelsen er at tro at en omskrivning er en genvej til orden.
Fælden ligger i hvad den gamle kode faktisk indeholder. Bag hver underlig linje ligger der ofte en grund: en fejl der blev rettet, et særtilfælde en kunde krævede, en regel en myndighed indførte. Det meste af det er udokumenteret og lever kun i koden. En omskrivning smider alt det væk og skal genopdage det, ét smertefuldt tilfælde ad gangen.
Samtidig står verden ikke stille. Det gamle system skal fortsætte med at fungere og udvikles mens det nye bygges. Du havner i et kapløb hvor målet flytter sig: Hver ny funktion i det gamle er endnu en som det nye mangler. Derfor bliver totale omskrivninger systematisk undervurderet i tid og omkostninger, og nogle gange bliver de aldrig færdige.
De kriterier der faktisk begrunder nyudvikling
Nogle gange er en omskrivning alligevel det rigtige. Men grundene skal være strukturelle, ikke æstetiske. “Koden er grim” er ikke nok: Grim kode der virker, kan refaktoreres. Det der begrunder nyudvikling, er forhindringer som refaktorering ikke kan komme uden om:
- Den underliggende platform er forældet eller usikker. Bygger systemet på teknologi der ikke længere får sikkerhedsopdateringer, eller på et grundlag der ikke kan opgraderes, er det et fundament man ikke kan refaktorere sig ud af.
- Kompetencerne er tørret ind. Hvis ingen længere kan eller vil vedligeholde teknologien, og der ikke kan rekrutteres folk til den, bliver systemet en blindgyde uanset hvor godt det fungerer i dag.
- Videreudviklingen er gået i stå. Når hver ny funktion tager urimeligt lang tid fordi koden aktivt står i vejen, og det gælder systemet som helhed snarere end en enkelt del, kan omkostningen ved at fortsætte overstige omkostningen ved at bygge nyt.
Bemærk at alle tre handler om at systemet som helhed sidder fast, ikke om at en bestemt del er rodet. Er problemet lokalt, er løsningen det også.
| Situation | Hælder mod |
|---|---|
| Rodet, men fungerende kode | Refaktorering |
| Forældet eller usikker platform | Nyudvikling |
| Ingen kan vedligeholde teknologien | Nyudvikling |
| Et enkelt modul bremser | Refaktorering af netop den del |
Refaktoreringsstrategien: hæv kvaliteten trinvis
Alternativet til den store omskrivning er at forbedre systemet stykke for stykke mens det lever videre. Det kaldes at refaktorere: at bygge om indvendigt uden at ændre hvad systemet gør udadtil.
Tanken er at udskifte én del ad gangen. Man afgrænser et område, forbedrer det, verificerer at alt stadig virker, og går videre til det næste. Brugerne mærker ingen afbrydelse. Og fordi hvert trin er lille, kan det rulles tilbage hvis noget går galt, i modsætning til en total omskrivning, hvor du ikke ved om det nye holder før alt skal skiftes på én gang.
Et almindeligt og gennemprøvet mønster er at lægge det nye gradvist rundt om det gamle: Ny funktionalitet bygges moderne, og ældre dele erstattes én efter én indtil det gamle til sidst kan udfases. Systemet er i drift og skaber værdi hele vejen i stedet for at stå i stillads i et år med usikkert udfald.
Et scenarie: to veje for samme system
Forestil dig et ti år gammelt ERP-system som er blevet tungt at udvikle på. Vej ét: Teamet river det hele ned og starter forfra. To år senere er det nye system næsten færdigt, men mangler en række små funktioner som har sneget sig ind i det gamle i mellemtiden, og budgettet er overskredet med god margin. Vej to: Teamet refaktorerer. De starter med det modul der bremser mest, får hurtigt sat skub i udviklingstempoet der og arbejder sig videre del for del. Efter samme tid er systemet mærkbart bedre, har leveret værdi hele vejen, og ingen har behøvet at holde vejret før en stor omlægning.
Det er ikke en jernregel: Nogle gange er vej ét det rigtige. Men udgangspunktet bør være vej to, netop fordi den holder risikoen lav og systemet levende.
Sådan vælger du
Stil tre spørgsmål. Er problemet strukturelt (platform, kompetencer, generelt udviklingstempo), eller er koden bare rodet? Kan vi fortsætte med at levere værdi mens vi forbedrer? Og har vi råd til den risiko en total omskrivning indebærer? Svarene peger næsten altid mod refaktorering, og gør de undtagelsesvis ikke det, ved du i det mindste hvorfor.
Vi i Weapp hjælper gerne med at aflæse hvor en kodebase er på vej hen og lægge en realistisk plan, som regel en trinvis. Se vores ydelser eller kontakt os, så kigger vi på jeres system sammen.
Ofte stillede spørgsmål
Hvorfor bliver totale omskrivninger så ofte undervurderet?
Fordi det gamle system, hvor rodet det end ser ud, bærer på årevis af opsamlede regler og særtilfælde som ingen har dokumenteret. En omskrivning starter fra nul og skal genopdage alt det, samtidig med at det gamle system fortsat udvikles. Det der ligner en genvej, bliver ofte et langt kapløb mod et bevægeligt mål.
Hvornår er det berettiget at bygge nyt fra bunden?
Når den underliggende platform er forældet eller usikker, når ingen længere kan eller vil vedligeholde teknologien, eller når hver ny funktion tager urimeligt lang tid fordi koden står i vejen. Det er strukturelle forhindringer som refaktorering ikke kan løse. Er problemet i stedet at koden er rodet, men virker, taler det meste for refaktorering.
Hvad betyder det at refaktorere?
At forbedre kodens struktur uden at ændre hvad den gør udadtil. Man rydder op og bygger om indvendigt stykke for stykke mens systemet fortsat fungerer for brugerne. Målet er at gøre koden lettere at vedligeholde og bygge videre på, uden den risiko og det stop som en total omskrivning indebærer.
Kan man refaktorere et system mens det er i drift?
Ja, og det er netop pointen. En trinvis refaktorering udskifter én del ad gangen mens resten lever videre. Brugerne mærker ingen afbrydelse, og hvert trin er lille nok til at kunne rulles tilbage hvis noget går galt. Det er langsommere end at tegne alt om på papiret, men dramatisk mindre risikabelt.
Hvad er risikoen ved at lade være og bare fortsætte med at lappe?
At den tekniske gæld vokser indtil hver ændring bliver dyr og risikabel, og systemet til sidst bremser hele forretningen. At lade være med at vælge er også et valg. Pointen med aktivt at tage stilling til refaktorering eller nyudvikling er at gøre noget ved forfaldet før det fremtvinger en panikbeslutning ved det næste sammenbrud.