Total omskrivning eller stegvis renovering – vad är rätt för er kodbas?
Utgå från stegvis renovering och skriv om från grunden bara när tydliga skäl motiverar det. Totala omskrivningar underskattas nästan alltid, för de börjar om från noll och tappar år av dolda regler. Nybygge kan motiveras av en förlegad grundplattform eller stopp för vidareutveckling – annars höjer du kvaliteten bit för bit i drift.
Förr eller senare åldras varje system. Koden blir svårare att ändra, nya funktioner tar allt längre tid, och någon föreslår det som låter så befriande: riv allt och bygg om från början. Lockelsen är stark, men statistiken är dyster. Här är hur du väger en total omskrivning mot en stegvis renovering – och varför det senare oftast vinner.
Omskrivningens lockelse och dess fälla
Att börja om från ett blankt blad är en av de mest förföriska idéerna i mjukvara. Den gamla koden är rörig och obegriplig, medan det nya finns bara i huvudet – rent, elegant och färdigt. Frestelsen är att tro att en omskrivning är en genväg till ordning.
Fällan ligger i vad den gamla koden faktiskt innehåller. Bakom varje underlig rad finns ofta ett skäl: en bugg som rättades, ett specialfall en kund krävde, en regel någon myndighet ställde. Det mesta av det är odokumenterat och lever bara i koden. En omskrivning kastar allt det och måste återupptäcka det, ett smärtsamt fall i taget.
Samtidigt står inte världen still. Det gamla systemet måste fortsätta att fungera och utvecklas medan det nya byggs. Du hamnar i en kapplöpning där målet rör sig: varje ny funktion i det gamla är en till som det nya inte har än. Det är därför totala omskrivningar systematiskt underskattas i tid och kostnad – och ibland aldrig blir klara alls.
Kriterierna som faktiskt motiverar nybygge
Ibland är omskrivning ändå rätt. Men skälen ska vara strukturella, inte estetiska. “Koden är ful” räcker inte – ful kod som fungerar går att renovera. Det som motiverar ett nybygge är hinder som renovering inte kan komma runt:
- Grundplattformen är förlegad eller osäker. Bygger systemet på teknik som inte längre får säkerhetsuppdateringar, eller på en grund som inte går att uppgradera, är det ett fundament man inte kan renovera bort.
- Kompetensen har torkat ut. Om ingen längre kan eller vill underhålla tekniken, och den inte går att rekrytera på, blir systemet en återvändsgränd oavsett hur väl det fungerar idag.
- Vidareutveckling har stannat. När varje ny funktion tar orimligt lång tid för att koden aktivt står i vägen, och det gäller systemet som helhet snarare än en enskild del, kan kostnaden för att fortsätta överstiga kostnaden för att bygga nytt.
Notera att alla tre handlar om att systemet som helhet sitter fast, inte om att en viss del är stökig. Är problemet lokalt, är lösningen det också.
| Situation | Lutar mot |
|---|---|
| Stökig men fungerande kod | Renovering |
| Förlegad eller osäker grundplattform | Nybygge |
| Ingen kan underhålla tekniken | Nybygge |
| En enskild modul bromsar | Renovering av just den delen |
Renoveringsstrategin: höj kvaliteten stegvis
Alternativet till den stora omskrivningen är att förbättra systemet bit för bit medan det fortsätter att leva. Det kallas att refaktorera: bygga om invändigt utan att ändra vad systemet gör utåt.
Tanken är att byta ut en del i taget. Man ringar in ett område, förbättrar det, verifierar att allt fortfarande fungerar, och går vidare till nästa. Användarna märker inget avbrott. Och eftersom varje steg är litet går det att backa om något går fel – till skillnad från en total omskrivning, där du inte vet om det nya håller förrän allt ska bytas på en gång.
Ett vanligt och beprövat mönster är att lägga det nya gradvis runt det gamla: ny funktionalitet byggs modernt, och äldre delar ersätts en efter en tills det gamla till slut kan pensioneras. Systemet är i drift och skapar värde hela vägen, i stället för att ligga i byggställning i ett år med osäker utgång.
Ett scenario: två vägar för samma system
Tänk ett tio år gammalt affärssystem som blivit trögt att utveckla. Väg ett: teamet river allt och börjar om. Två år senare är det nya systemet nästan klart, men saknar en rad småfunktioner som smugit in i det gamla under tiden, och budgeten är passerad med god marginal. Väg två: teamet renoverar. De börjar med den modul som bromsar mest, får snabbt loss utvecklingstakten där, och arbetar sig vidare del för del. Efter samma tid är systemet påtagligt bättre, har levererat värde hela vägen, och ingen har behövt hålla andan inför en stor omkoppling.
Det är inte en regel utan huvudet i väggen – ibland är väg ett rätt. Men förvalet bör vara väg två, just för att den håller risken låg och systemet levande.
Så väljer du
Ställ tre frågor. Är problemet strukturellt – grundplattform, kompetens, generell utvecklingstakt – eller bara att koden är stökig? Kan vi fortsätta leverera värde medan vi förbättrar? Och har vi råd med den risk en total omskrivning innebär? Svaren pekar nästan alltid mot renovering, och gör de undantagsvis inte det, vet du åtminstone varför.
Vi på Weapp hjälper gärna till att läsa av vart en kodbas är på väg och lägga en realistisk plan – oftast en stegvis. Se våra tjänster eller hör av dig så tittar vi på ert system tillsammans.
Vanliga frågor
Varför underskattas totala omskrivningar så ofta?
För att det gamla systemet, hur rörigt det än ser ut, bär på år av samlade regler och specialfall som ingen dokumenterat. En omskrivning börjar om från noll och måste återupptäcka allt det, samtidigt som det gamla fortsätter att utvecklas. Det som ser ut som en genväg blir ofta en lång kapplöpning mot ett rörligt mål.
När är det befogat att bygga nytt från grunden?
När grundplattformen är förlegad eller osäker, när ingen längre kan eller vill underhålla tekniken, eller när varje ny funktion tar orimligt lång tid för att koden står i vägen. Det är strukturella hinder som renovering inte kan lösa. Är problemet i stället att koden är stökig men fungerar, talar det mesta för renovering.
Vad menas med att refaktorera?
Att förbättra kodens struktur utan att ändra vad den gör utåt. Man städar och bygger om invändigt, bit för bit, medan systemet fortsätter fungera för användarna. Målet är att göra koden lättare att underhålla och bygga vidare på, utan den risk och det stopp som en total omskrivning innebär.
Kan man renovera ett system medan det är i drift?
Ja, och det är själva poängen. En stegvis renovering byter ut en del i taget medan resten fortsätter att leva. Användarna märker inget avbrott, och varje steg är litet nog att kunna backas om något går fel. Det är långsammare än att rita om allt på papper, men dramatiskt mycket mindre riskabelt.
Vad är risken med att låta bli och bara fortsätta lappa?
Att teknisk skuld växer tills varje ändring blir dyr och riskabel, och systemet till slut bromsar hela verksamheten. Att inte välja är också ett val. Poängen med att aktivt ta ställning till renovering eller nybygge är att göra något åt förfallet innan det tvingar fram ett panikbeslut vid nästa haveri.