Total omskriving eller trinnvis refaktorering: Hva er riktig for kodebasen deres?
Ta utgangspunkt i trinnvis renovering, og skriv om fra grunnen bare når tydelige grunner tilsier det. Totale omskrivinger undervurderes nesten alltid, for de starter fra null og mister årevis med skjulte regler. Et nybygg kan være berettiget ved en utdatert grunnplattform eller stopp i videreutviklingen. Ellers hever du kvaliteten bit for bit i drift.
Før eller senere blir hvert system gammelt. Koden blir vanskeligere å endre, nye funksjoner tar stadig lengre tid, og noen foreslår det som høres så befriende ut: å rive ned alt og bygge opp igjen fra bunnen. Fristelsen er sterk, men statistikken er dyster. Her ser vi på hvordan du veier en total omskriving mot en trinnvis renovering, og hvorfor renoveringen som regel vinner.
Omskrivingens fristelse og felle
Å begynne med blanke ark er en av de mest forførende ideene i programvareverdenen. Den gamle koden er rotete og uforståelig, mens det nye bare finnes i hodet: rent, elegant og ferdig. Fristelsen er å tro at en omskriving er en snarvei til orden.
Fellen ligger i hva den gamle koden faktisk inneholder. Bak hver merkelig linje finnes det ofte en grunn: en feil som ble rettet, et spesialtilfelle en kunde krevde, en regel en myndighet innførte. Det meste av dette er udokumentert og lever bare i koden. En omskriving kaster alt dette og må gjenoppdage det, ett smertefullt tilfelle om gangen.
Samtidig står ikke verden stille. Det gamle systemet må fortsette å fungere og utvikles mens det nye bygges. Du havner i et kappløp der målet flytter seg: Hver ny funksjon i det gamle er enda en som det nye ikke har ennå. Det er derfor totale omskrivinger systematisk undervurderes i tid og kostnad, og noen blir aldri ferdige i det hele tatt.
Kriteriene som faktisk taler for nybygg
Noen ganger er omskriving likevel riktig. Men grunnene skal være strukturelle, ikke estetiske. «Koden er stygg» holder ikke: Stygg kode som fungerer, kan renoveres. Det som taler for et nybygg, er hindringer som renovering ikke kan komme rundt:
- Grunnplattformen er utdatert eller usikker. Bygger systemet på teknologi som ikke lenger får sikkerhetsoppdateringer, eller på en grunnmur som ikke kan oppgraderes, er det et fundament som ikke lar seg renovere bort.
- Kompetansen har forsvunnet. Hvis ingen lenger kan eller vil vedlikeholde teknologien, og hvis det heller ikke er mulig å rekruttere folk som kan den, blir systemet en blindvei uansett hvor godt det fungerer i dag.
- Videreutviklingen har stoppet opp. Når hver ny funksjon tar urimelig lang tid fordi koden aktivt står i veien, og når det gjelder systemet som helhet snarere enn én enkelt del, kan kostnaden ved å fortsette bli høyere enn kostnaden ved å bygge nytt.
Merk at alle tre handler om at systemet som helhet sitter fast, ikke om at en bestemt del er rotete. Er problemet lokalt, er løsningen det også.
| Situasjon | Peker mot |
|---|---|
| Rotete, men fungerende kode | Renovering |
| Utdatert eller usikker grunnplattform | Nybygg |
| Ingen kan vedlikeholde teknologien | Nybygg |
| Én enkelt modul bremser | Renovering av akkurat den delen |
Renoveringsstrategien: Hev kvaliteten trinn for trinn
Alternativet til den store omskrivingen er å forbedre systemet bit for bit mens det fortsatt er i drift. Det kalles å refaktorere: å bygge om innvendig uten å endre hva systemet gjør utad.
Tanken er å bytte ut én del om gangen. Man avgrenser et område, forbedrer det og verifiserer at alt fortsatt fungerer. Så går man videre til neste. Brukerne merker ingen avbrudd. Og fordi hvert trinn er lite, kan det rulles tilbake hvis noe går galt, i motsetning til en total omskriving, der du ikke vet om det nye holder før alt skal byttes på én gang.
Et vanlig og velprøvd mønster er å legge det nye gradvis rundt det gamle: Ny funksjonalitet bygges med moderne teknologi, og eldre deler erstattes én etter én inntil det gamle kan fases ut helt. Systemet er i drift og skaper verdi hele veien, i stedet for å stå i stillas i et år med usikkert utfall.
Et scenario: to veier for det samme systemet
Tenk deg et ti år gammelt ERP-system som har blitt tungt å videreutvikle. Den første veien: Teamet river ned alt og begynner på nytt. To år senere er det nye systemet nesten ferdig, men mangler en rekke småfunksjoner som har sneket seg inn i det gamle i mellomtiden, og budsjettet er overskredet med god margin. Den andre veien: Teamet renoverer. De begynner med modulen som bremser mest, får raskt opp utviklingstempoet der og jobber seg videre del for del. Etter like lang tid er systemet merkbart bedre og har levert verdi hele veien, og ingen har måttet holde pusten foran en stor omlegging.
Dette er ingen ufravikelig regel: Noen ganger er den første veien riktig. Men standardvalget bør være den andre veien nettopp fordi den holder risikoen lav og systemet levende.
Slik velger du
Still tre spørsmål. Er problemet strukturelt (grunnplattform, kompetanse, generelt utviklingstempo), eller er det bare at koden er rotete? Kan vi fortsette å levere verdi mens vi forbedrer? Og har vi råd til den risikoen en total omskriving innebærer? Svarene peker nesten alltid mot renovering, og gjør de unntaksvis ikke det, vet du i det minste hvorfor.
Vi i Weapp hjelper gjerne til med å vurdere hvor en kodebase er på vei, og med å legge en realistisk plan, som oftest en trinnvis. Se tjenestene våre eller ta kontakt, så ser vi på systemet deres sammen med dere.
Ofte stilte spørsmål
Hvorfor undervurderes totale omskrivinger så ofte?
Fordi det gamle systemet, uansett hvor rotete det ser ut, rommer mange år med oppsamlede regler og spesialtilfeller som ingen har dokumentert. En omskriving starter fra null og må gjenoppdage alt dette, samtidig som det gamle fortsetter å utvikles. Det som ser ut som en snarvei, blir ofte et langt kappløp mot et bevegelig mål.
Når er det berettiget å bygge nytt fra grunnen?
Når grunnplattformen er utdatert eller usikker, når ingen lenger kan eller vil vedlikeholde teknologien, eller når hver ny funksjon tar urimelig lang tid fordi koden står i veien. Dette er strukturelle hindringer som renovering ikke kan løse. Er problemet i stedet at koden er rotete, men fungerer, taler det meste for renovering.
Hva menes med å refaktorere?
Å forbedre strukturen i koden uten å endre hva den gjør utad. Man rydder og bygger om innvendig, bit for bit, mens systemet fortsetter å fungere for brukerne. Målet er å gjøre koden enklere å vedlikeholde og videreutvikle, uten den risikoen og det stoppet som en total omskriving innebærer.
Kan man renovere et system mens det er i drift?
Ja, og det er selve poenget. En trinnvis renovering bytter ut én del om gangen mens resten fortsetter som før. Brukerne merker ingen avbrudd, og hvert trinn er lite nok til at det kan rulles tilbake hvis noe går galt. Det går langsommere enn å tegne alt på nytt på papiret, men er dramatisk mindre risikabelt.
Hva er risikoen ved å la være og bare fortsette å lappe?
At den tekniske gjelden vokser helt til hver endring blir dyr og risikabel, og at systemet til slutt bremser hele virksomheten. Å ikke velge er også et valg. Poenget med å ta aktivt stilling til renovering eller nybygg er å gjøre noe med forfallet før det tvinger frem en panikkbeslutning ved neste havari.