Hvad er refaktorering?

Refaktorering er et af de begreber der let lyder som teknisk luksus, noget udviklere gerne vil bruge tid på, men som ikke giver forretningen noget. Det billede er forkert, og det kan blive dyrt. Her er hvad refaktorering faktisk er og hvorfor det er en af de klogeste investeringer i et system.

Hvad refaktorering er

Refaktorering er at forbedre kodens indre struktur uden at ændre hvad den gør. Systemet opfører sig nøjagtig på samme måde før og efter (samme knapper, samme svar, samme resultater), men under overfladen er koden blevet renere, tydeligere og lettere at arbejde i.

Tænk på det som at rydde op i et køkken og organisere det uden at skifte komfuret ud. Maden der laves, er den samme, men alt er hurtigere at finde, bordpladerne er ryddet, og den næste der skal lave mad, slipper for at lede. Koden gør det samme som før; den er bare lettere at bygge videre på.

Derfor bliver refaktorering ofte beskrevet som afdraget på teknisk gæld: Du betaler af på det fremtidige merarbejde der ellers hober sig op.

Hvorfor intet ses, men alt går hurtigere

Her ligger den almindelige misforståelse. Fordi refaktorering ikke tilføjer nogen funktion, ser brugeren, og ofte også kunden, ingen forskel overhovedet. Det kan føles som at have betalt for ingenting.

Men værdien ligger netop i det usynlige. Ren, velstruktureret kode er hurtigere at forstå, sikrere at ændre og lettere at bygge nyt i. En funktion der i en rodet kodebase ville have taget to uger og introduceret fejl, tager i en velholdt kodebase nogle dage og holder. Forskellen mærkes ikke i den enkelte ændring, men i tempoet over tid.

Uden løbende refaktorering går det den anden vej. Hver hurtig genvej og hver del der ikke er ryddet op i, lægger lidt mere træghed til indtil selv trivielle ændringer bliver dyre, langsomme og risikable. Koden “rådner” ikke af sig selv, men den tynger alt der bygges ovenpå.

Forskellen på refaktorering og omskrivning

Det er let at forveksle refaktorering med en omskrivning, men det er to forskellige ting med helt forskellig risiko. Refaktorering forbedrer den eksisterende kode i små og sikre trin mens en omskrivning smider den gamle løsning ud og bygger en ny fra bunden: et stort, dyrt og risikabelt projekt hvor man midlertidigt mister det gamle og afprøvede. Næsten altid er trinvis refaktorering det sikreste valg.

Et konkret scenarie

Lad os sige at et team skal tilføje en ny betalingsmetode i en tjeneste. De åbner den del af koden der håndterer betalinger, og opdager at den er rodet: Den samme logik er kopieret fem steder, navngivningen er forvirrende, og ingen tør rigtig røre ved den.

Vælger de bare at “klemme” den nye metode ind, vokser rodet, og den næste ændring bliver endnu værre. Vælger de i stedet først at refaktorere (samle den fælles logik ét sted og give tingene forståelige navne), tager det lidt længere tid denne gang, men adfærden er uændret, og den næste betalingsmetode bliver enkel at tilføje. De betalte af på gælden i stedet for at øge den.

Rådet: løbende, ikke som et stort projekt

Det vigtigste princip er at refaktorering skal indgå løbende i det almindelige arbejde, ikke spares sammen til et stort separat “oprydningsprojekt”. Det bedste tidspunkt til at forbedre en del af koden er når man alligevel arbejder i den for at bygge eller rette noget, for så sker oprydningen i samme åndedrag.

Et stort, selvstændigt refaktoreringsprojekt er sværere at retfærdiggøre, mere risikabelt og lettere at udskyde i det uendelige. Lidt ad gangen, ofte, som en naturlig del af hvert sprint, er både billigere og sikrere.

Vil I have at jeres system forbliver hurtigt og billigt at bygge videre på år efter år, bygger vi hos Weapp løbende pleje af koden ind i udviklingsarbejdet fra begyndelsen.