MVKJG 6: Lär dig om refactoring

Efter ett alldeles för långt uppehåll tar jag åter upp skrivandet av serien Men vad kan jag göra? – tips om saker som du kan göra idag, helt utan att be om tillstånd, för att förbättra tillståndet i ditt aktuella projekt.

Varje gång jag hör någon berätta om ett stycke särskilt hemsk kod de sprungit på kommer jag att tänka på när jag hittade en klass som var 17000 rader lång. Någonstans mitt i denna kompakta massa text fanns två metoder. Den ena hette “up”, den andra “down”. Båda var ganska långa och, visade det sig, helt identiska. Eller inte helt – ett tecken skilde faktiskt. Där det stod ett plus i den ena stod det ett minus i den andra. Det tog en stunds betraktande och ett diff-program för att ställa diagnosen. Sådan är klipp-och-klistra-programmeringens logik. Den enes snabba fix blir den andres huvudbry. Denna monsterklass var representativ för hela kodbasen.

Mitt uppdrag i projektet var väldigt tydligt definierat. Jag skulle vidareutveckla en viss modul i koden. Minnet av hur det kändes när jag först såg den kod jag förväntades bygga vidare på lever kvar. Självklart var den, som man brukar säga, nästan klar och bara några små tillägg skulle göras.

Den del av koden jag fick tilldelad var inte 17000 rader lång. Tvärtom var det en ganska kort klass. En kort och kompakt klass. En tät massa av kryptiska variabler och villkorssatser. Det jag kände när jag tittade på den var fruktan. Fruktan att jag inte skulle klara den uppgift jag fått tilldelad.

Jag minns inte om jag köpte Martin Fowlers lysande bok om refactoring efter min sammanstötning med detta monster till källkod, eller om jag just hade råkat köpa den. Hur det än var så räddade den boken mig.

Fowler beskrev i sin bok hur man kunde jobba i små kontrollerade steg för att omvandla oläsbar kod till läsbar kod. Han visade hur man försiktigt men målmedvetet kunde omforma spaghettikod till små kontrollerbara bitar.

Jag skred till verket metodiskt och omsorgsfullt. Eftersom jag jobbade i Visual Basic 6 hade jag inte tillgång till några automatiska verktyg för refactoring, men Fowlers instruktioner kunde följas steg för steg. Långsamt gjorde jag koden mer hanterbar. Jag bytte obegripliga variabelnamn mot begripliga. Jag bröt ned långa metoder i kortare, och gav dem mer passande namn. Jag tog bort överflödig kod. Jag strukturerade och städade, hela tiden efter Fowlers recept som visade hur jag kunde göra ändringarna på ett tryggt sätt. För första gången kände jag mig som en riktig programmerare (språket till trots skulle vissa säga). Till slut kunde jag göra de tillägg jag blivit ombedd att göra.

Fowlers definition på refactoring var “små designförändringar som inte ändrar kodens beteende”. Idag verkar en vanligare tolkning av termen vara “blandade tekniska förändringar av större och mindre sort”. Den sortens ändringar har vi redan tillräckligt av, men den sort Fowler avsåg är det fortfarande brist på. Därför, om du vill göra en skillnad redan idag, lär dig först vad refactoring betyder. Lär dig sedan att använda tekniken i praktiken. Förmodligen har du redan upptäckt att det finns inbyggt stöd för refactoring i ditt utvecklingsverktyg, så idag är det lättare än någonsin att börja skriva kod som andra inte behöver frukta att ta över, och det – det är att göra världen till en lite bättre plats.

– – –

Övningar

1. Vilken bok skulle kunna rädda dig ur situationen du befinner dig i just nu? Beskriv din situation för en vän eller kollega du litar på och fråga om de har ett tips på en bok som skulle kunna hjälpa dig.
2. Är begreppet refactoring känt bland de du jobbar med? Fråga några kollegor om hur de definierar refactoring.