Som beställare av IT-system och -applikationer ställs man ibland inför begreppet refaktorisering, vilket beskrivs som "kodförändringar som tjänar till att korrigera och ordna i källkoden" och som inte ger någon egentlig skillnad i funktion eller prestanda.
Motvind
Refaktorisering är ett ord och en beskrivning som inte sällan framkallar negativa reaktioner från icke-tekniker. Detta är helt förståeligt, eftersom det låter helt befängt att låta skriva om kod som redan gör det den ska. Ur beställarens synvinkel är det som att göra jobbet en gång till, vilket ses som ett rent slöseri. Denna omskrivning inför också en risk för ökade utgifter - alla kodändringar ska ju testas och just testning tenderar att på ett väldigt direkt sätt påverka beställarens vardag.
Denna tanke döljer dock en viktig insikt, nämligen att man som beställare inte alls vet hur denna "kod som gör det den ska" egentligen ser ut. Koden i en komplicerad funktion kan innehålla många försök, halva lösningar, ibland rena återvändsgränder – precis som vilket annat skrivet material som helst behöver det renskrivas innan det lämnas vidare. Att avstå från detta innebär med största sannolikhet ännu högre kostnader nästa gång någon rättning eller ändring av koden ska göras, än mer om den som ska utföra arbetet inte är samma person som skrev koden till att börja med.
Vad pratar vi om?
Här är det också på sin plats att ha klart för sig vad refaktorisering innebär. Ibland sätts den här etiketten på riktiga mastodont-uppgifter, som bytet av ett kommunikationsformat eller uppgraderingen av en databasmotor. Det här är dock exempel på vad som inte är refaktorisering.
Vem som först skrev om refaktorisering är höljt i historiens dunkel, men en av de mest kända utläggningarna i ämnet har gjorts av Martin Fowler i hans bok "Refactoring: Improving the design of existing code". Han angav denna förklaring av refaktorisering:
"Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant."
Det hela handlar alltså om att uppnå en synergieffekt av de små åtgärdernas summa. Man kan jämföra refaktorisering med små "städuppgifter", som att sortera och ordna en utskrift på tre sidor på skrivbordet eller att flytta en tallrik från en kökshylla till en annan. I sig själv är en sådan uppgift närmast skrattretande liten, men med ett ökat antal sådana små uppgifter kommer uppenbara vinster. Om man håller ordning på sina papper hela tiden så blir det mycket lättare att hitta det där avtalet som man letar efter. Om man kontinuerligt diskar så fort man använt något, så slipper man rensa diskbänk och diskho den dag man verkligen behöver ytan. Kontinuerlig refaktorisering är alltså ett sätt att i realiteten minska risken för, eller helst helt slippa, dessa stora och tidsödande renoveringar av koden som annars blir nödvändiga i framtiden.
Allmän uppfattning
Varför har då refaktorisering fått ett sådant rykte, och varför görs det som stora ”Big Bang”-modifieringar när auktoriteterna på området förespråkar motsatsen? Inte sällan handlar det om att utvecklarna inte lyckats med riktig refaktorisering, antingen på grund av okunskap, tidsbrist eller, låt oss vara ärliga, ovilja - precis som all annan städning kan detta vara riktigt tråkigt. Man är ofta fortfarande klar över att det behöver göras, och hoppas genom ett snabbt helhetsgrepp få den spretiga koden under kontroll.
Vissa har också menat att verksamheten och dess fokus på projektarbete gör sitt till för att frammana större åtgärder - det går inte att få loss resurser till en arbetsuppgift utan att ha en projektplan, vilket gör att man gärna tar till lite extra för att det ska se "riktigt" ut.
Detta för oss naturligt till hur refaktorisering egentligen bör hanteras inom en utvecklarorganisation. Att det rör sig om mycket små uppgifter innebär att de bör ingå som en självklar del av den ordinarie utvecklingsprocessen, på samma sätt som att man städar en arbetsstation efter sig innan man går vidare till nästa. Såklart måste "icke-funktionsförändringen" säkerställas, vilket naturligast sker genom applicerande av väl utformade automatiska tester på integrations- och BDD-nivå.
Slutord
Sammantaget innebär detta att man från beställar- och verksamhetshåll inte ska se refaktorisering som onödigt slöseri, utan som en naturlig del av ett välgjort utvecklingsarbete. Därmed ska man också kunna ställa krav på utvecklarna så att arbetet görs ordentligt och på så sätt att den nedlagda tiden ger maximalt utbyte. Resultatet av detta kommer att vara en renare och mer lättarbetad kod, högre kvalitet på arbetet och mer valuta för pengarna för beställaren.
Är du nyfiken på erat systems kodstandard? Kontakta oss genom att klicka på knappen nedan så kan vi hjälpa er.
