Vad är refaktorering?
Refaktorering är att förbättra kodens interna struktur utan att ändra vad den gör utåt. Beteendet är detsamma före och efter, men koden blir renare, tydligare och lättare att bygga vidare på. Det är amorteringen på teknisk skuld – inget syns för användaren, men allt framtida arbete går fortare. Det bör ske löpande, inte samlas till ett stort projekt.
Refaktorering är ett av de begrepp som lätt låter som teknisk lyx, något utvecklare vill hålla på med men som inte ger verksamheten något. Den bilden är fel, och den kan bli dyr. Här är vad refaktorering faktiskt är, och varför det är en av de klokaste investeringarna i ett system.
Vad refaktorering är
Refaktorering är att förbättra kodens inre struktur utan att ändra vad den gör. Systemet beter sig exakt likadant före och efter – samma knappar, samma svar, samma resultat – men under ytan har koden blivit renare, tydligare och lättare att arbeta i.
Tänk på det som att städa och organisera ett kök utan att byta ut spisen. Maten som lagas blir densamma, men allt går snabbare att hitta, ytorna är fria och nästa person som ska laga något slipper leta. Koden gör samma sak som förr; den är bara lättare att bygga vidare på.
Det är därför refaktorering ofta beskrivs som amorteringen på teknisk skuld – du betalar av på det framtida merarbete som annars byggs upp.
Varför inget syns men allt går fortare
Här sitter den vanliga missförståndet. Eftersom refaktorering inte lägger till någon funktion ser användaren – och ofta beställaren – ingen skillnad alls. Det kan kännas som att man betalat för ingenting.
Men värdet ligger just i det osynliga. Ren, välstrukturerad kod är snabbare att förstå, säkrare att ändra och lättare att bygga nytt i. En funktion som i en rörig kodbas hade tagit två veckor och introducerat buggar, tar i en välvårdad kodbas några dagar och håller. Skillnaden märks inte i den enskilda ändringen, utan i tempot över tid.
Utan löpande refaktorering går det åt andra hållet. Varje snabb genväg och ostädad del lägger på lite mer tröghet, tills även triviala ändringar blir dyra, långsamma och riskabla. Koden “ruttnar” inte av sig själv – men den tynger ner allt som byggs ovanpå.
Skillnaden mot omskrivning
Det är lätt att blanda ihop refaktorering med att skriva om, men de är olika saker med helt olika risk. Refaktorering förbättrar den kod som finns, i små och säkra steg, medan en omskrivning kastar den gamla lösningen och bygger en ny från grunden – ett stort, dyrt och riskfyllt projekt där man tillfälligt förlorar det beprövade gamla. Nästan alltid är stegvis refaktorering det tryggare valet.
Ett konkret scenario
Säg att ett team ska lägga till en ny betalmetod i en tjänst. De öppnar den del av koden som hanterar betalningar och upptäcker att den är rörig: samma logik är kopierad på fem ställen, namngivningen är förvirrande, och ingen vågar riktigt röra den.
Väljer de att bara “klämma in” den nya metoden växer röran, och nästa ändring blir ännu värre. Väljer de i stället att först refaktorera – samla den gemensamma logiken på ett ställe, ge saker begripliga namn – tar det lite längre den här gången, men beteendet är oförändrat och nästa betalmetod blir enkel att lägga till. De amorterade på skulden i stället för att öka den.
Rådet: löpande, inte som ett stort projekt
Den viktigaste principen är att refaktorering ska ingå löpande i det vanliga arbetet, inte sparas ihop till ett stort separat “städprojekt”. Bästa tillfället att förbättra en del av koden är när man ändå är inne i den för att bygga eller fixa något – då sker städningen i samma andetag.
Ett stort, fristående refaktoreringsprojekt är svårare att motivera, mer riskabelt och lättare att skjuta upp i all oändlighet. Lite i taget, ofta, som en naturlig del av varje sprint, är både billigare och tryggare.
Vill ni att ert system ska förbli snabbt och billigt att bygga vidare på år efter år, bygger vi på Weapp in löpande omsorg om koden i utvecklingsarbetet från början.
Vanliga frågor
Vad är skillnaden mot att skriva om koden?
Refaktorering förbättrar den befintliga koden i små, säkra steg utan att ändra vad den gör. En omskrivning kastar den gamla lösningen och bygger nytt från grunden. Refaktorering är lågrisk och pågår löpande; en omskrivning är ett stort, riskfyllt projekt där man tillfälligt tappar det gamla. Oftast är stegvis refaktorering det klokare valet.
Varför ska vi betala för något som inte syns?
Därför att det som inte syns avgör hur fort och säkert allt annat går. Refaktorering håller koden begriplig, så att nya funktioner kan byggas snabbare och med färre fel. Utan den växer den tekniska skulden tills även små ändringar blir dyra och riskabla. Ni betalar antingen lite löpande, eller mycket senare.
Vad är teknisk skuld i sammanhanget?
Teknisk skuld är det framtida merarbete som byggs upp när kod skrivs snabbt eller lämnas ostädad. Precis som ett lån samlar den ränta: ju längre den ligger, desto trögare blir varje ny ändring. Refaktorering är sättet att amortera på den skulden, så att den inte växer sig ohanterlig.
När bör man refaktorera?
Löpande, som en naturlig del av arbetet. Bästa tillfället är när man ändå är inne i en del av koden för att bygga eller fixa något – då städas den samtidigt. Att i stället spara ihop all refaktorering till ett stort separat projekt är dyrare, mer riskabelt och svårare att motivera. Lite i taget, ofta, är regeln.
Innebär refaktorering någon risk?
Risken är låg när det görs rätt: i små steg med bra tester som bekräftar att beteendet är oförändrat. Faran uppstår när man tar för stora kliv på en gång eller saknar tester som fångar om något gått sönder. Med rätt arbetssätt är refaktorering ett av de säkraste sätten att förbättra ett system.