Hva er refaktorering?

Refaktorering er et av de begrepene som lett høres ut som teknisk luksus, noe utviklere gjerne vil drive med, men som ikke gir virksomheten noe. Det bildet er feil, og det kan bli dyrt. Her går vi gjennom hva refaktorering faktisk er, og hvorfor det er en av de klokeste investeringene i et system.

Hva refaktorering er

Refaktorering vil si å forbedre den indre strukturen i koden uten å endre hva den gjør. Systemet oppfører seg nøyaktig likt før og etter (de samme knappene, de samme svarene, de samme resultatene), men under overflaten har koden blitt renere, tydeligere og lettere å jobbe i.

Tenk på det som å rydde og organisere et kjøkken uten å bytte ut komfyren. Maten som lages, blir den samme, men alt er raskere å finne, benkeplatene er ryddet, og den neste som skal lage mat, slipper å lete. Koden gjør det samme som før; den er bare lettere å bygge videre på.

Derfor beskrives refaktorering ofte som nedbetaling av teknisk gjeld: Du betaler ned på det fremtidige merarbeidet som ellers bygges opp.

Hvorfor ingenting vises, men alt går raskere

Her ligger den vanlige misforståelsen. Fordi refaktorering ikke legger til noen funksjon, ser brukeren (og ofte også kunden) ingen forskjell i det hele tatt. Det kan føles som om man har betalt for ingenting.

Men verdien ligger nettopp i det usynlige. Ren, velstrukturert kode er raskere å forstå, tryggere å endre og lettere å bygge nytt i. En funksjon som i en rotete kodebase ville ha tatt to uker og ført med seg nye feil, tar i en velholdt kodebase noen dager og holder. Forskjellen viser seg ikke i den enkelte endringen, men i tempoet over tid.

Uten løpende refaktorering går det motsatt vei. Hver rask snarvei og hver del som ikke ryddes, gjør systemet litt tregere å jobbe i. Til slutt blir selv trivielle endringer dyre, trege og risikable. Koden «råtner» ikke av seg selv, men den tynger ned alt som bygges oppå.

Forskjellen på refaktorering og omskriving

Det er lett å blande sammen refaktorering og omskriving, men det er to ulike ting med helt ulik risiko. Refaktorering forbedrer koden som finnes, i små og trygge steg, mens en omskriving kaster den gamle løsningen og bygger en ny fra grunnen av: et stort, dyrt og risikofylt prosjekt der man midlertidig mister det utprøvde gamle. Nesten alltid er trinnvis refaktorering det tryggere valget.

Et konkret scenario

Si at et team skal legge til en ny betalingsmetode i en tjeneste. De åpner den delen av koden som håndterer betalinger, og oppdager at den er rotete: Den samme logikken er kopiert på fem steder, navngivingen er forvirrende, og ingen tør egentlig å røre den.

Velger de bare å «presse inn» den nye metoden, vokser rotet, og neste endring blir enda verre. Velger de i stedet å refaktorere først, altså samle den felles logikken på ett sted og gi ting forståelige navn, tar det litt lengre tid denne gangen, men oppførselen er uendret, og neste betalingsmetode blir enkel å legge til. De betalte ned på gjelden i stedet for å øke den.

Rådet: løpende, ikke som et stort prosjekt

Det viktigste prinsippet er at refaktorering skal inngå løpende i det vanlige arbeidet, ikke spares opp til et stort, separat «ryddeprosjekt». Det beste tidspunktet for å forbedre en del av koden er når man uansett er inne i den for å bygge eller rette noe, for da skjer ryddingen i samme slengen.

Et stort, frittstående refaktoreringsprosjekt er vanskeligere å forsvare, mer risikabelt og lettere å utsette i det uendelige. Litt om gangen, ofte, som en naturlig del av hver sprint, er både billigere og tryggere.

Vil dere at systemet skal forbli raskt og billig å bygge videre på år etter år, bygger vi i Weapp løpende rydding i koden inn i utviklingsarbeidet fra start.