Refactoring - att skriva om och förbättra din kod

(29 december 2009) Vi börjar med tipset:

Refactoring

Refactoring betyder ungefär "skriva om koden så att den blir bättre". Man ändrar alltså koden utan att lägga till ny funktionalitet. Martin Fowlers bok "Refactoring: Improving the Design of Existing Code" (ISBN 978-0201485677, 464 sidor) handlar om just detta.

"Refactoring" är en bokklassiker pga sitt budskap: kod är någonting som måste underhållas för att den inte ska förfalla. Bokens budskap är jättebra! Den som letar efter något att (streck)läsa får dock leta någon annanstans. Boken består till 90% av regler för omskrivning av kod (de flesta triviala) och lämpar sig bäst som uppslagsverk. Du kan dessutom läsa om omskrivningarna på Fowlers webbplats för Refactoring. Det jag gillar mest med boken är de insikter Fowler delar med sig av i början av boken. Det är dem jag skriver om här.

Det känns inte bra

Er programkod innehåller förmodligen delar som är bra och delar som är mindre bra. Så hur vet man vad som behöver ändras? Nu är ju ingenting svart eller vitt och koden är inte bara bra eller dålig. Fowler definierar en mängd markörer (s.k. code smells) som indikerar vilka delar av koden som behöver tillsyn.

Man vill undvika att gå till sina kollegor, peka på kod och säga "Det känns inte bra". Istället kan du säga "Här har vi ett fall av feature envy" eller "inappropriate intimacy". Det är mer konstruktivt eftersom varje code smell kan åtgärdas med specifika omskivningsregler. Läs mer om code smells här.

Ett radikalt förslag

Fowler skriver att han brukar praktisera följande:

Detta kanske låter helt vansinnigt vid första anblicken. Men man anar ändå vad Fowler är ute efter. Om man har kod som knappt någon förstår vid första anblicken så är det skäl nog att skriva om den (se även artikel om bra kod). Fowler förutsätter förstås riktigt bra enhetstester. Men för icke-trivial kod så blir det väldigt dyrt att nå den täckning som behövs. Läs mer om enhetstestning i en annan artikel.

Med detta sagt så måste det kännas befriande att jobba som Fowler förespråkar. Alla har nog sett kod som "fungerar" och inte får röras, men som är helt obegriplig (och förmodligen trasig). Fowlers förslag är raka motsatsen mot en "don't fix what's not broken"-mentalitet. Och det kan ju aldrig vara fel.

Bota din beslutsångest

En aha-upplevelse som Fowlers bok gav mig var denna:

Detta tips kan tillämpas när du tvingas välja mellan olika likvärdiga designalternativ. Normalt sett grunnar man över sitt beslut för att hitta det bästa alternativet. När man sen valt är man fast (iallafall kan det kännas så). Fowlers angreppssätt är något helt annat: välj ett designalternativ som ligger nära de andra. Det behöver inte vara så noga vilket, bara det är lätt att ångra.

Den stora fördelen med Fowlers sätt är att det lyfter en stor börda från programmeraren. Man behöver inte våndas och fundera på om dina designval är perfekta. Du väljer ett alternativ och sätter igång. Blir det fel kan du ändra senare. Refactoring är en av de viktigaste verktygen i agila metoder som Extreme programming. Man implementerar, testar, ändrar och testar tills man når ett bra resultat.

När allt går att ångra finns det inga ursäkter för att inte sätta igång direkt. Gör några ändringar, se hur det blir. Blir det inte bra, så ändra tillbaka. Pröva något annat. Kod är någonting som hela tiden ändras. Jag säger som Kent Beck, grundaren av Extreme programming: Embrace change!