Har du ansvar för, eller jobbar med, system som är svåra att underhålla? Är kodbasen stor och komplex med några år på nacken? Får du känslan av att varje förändring i koden ytterligare bidrar till systemets förfall och att det är helt hopplöst att få till några förbättringar?
Vore det inte skönt att vända den negativa trenden till en positiv, där varje förändring istället bidrar till att förbättra koden. Att på sikt få nöjdare användare, gladare utvecklare, snabbare förändringar och färre fel? Hav förtröstan, det är möjligt!
Det första steget mot bättre kod är att utvecklingsteamet kommer överens om att tillsammans vända trenden. Konkret så lovar de sig själva och varandra att varje funktionell förändring som görs från och med nu kommer att innefatta en portion refaktorisering och förbättringar.
När ett krav medför att en del av koden behöver ändras, så görs en snabb översyn av den delen av koden. Teamet behöver fundera på:
- Hur ser koden ut idag?
- Hur vill vi att den ska se ut istället?
- Vilka förbättringar finns att göra här, stora som små?
Även små förbättringar är viktiga, och när man väl fått undan de mindre bristerna kan det vara lättare att ta itu med de större. Vilka förbättringar man väljer att genomföra påverkas bland annat av:
- hur ofta den aktuella delen av systemet brukar behöva förändras
- hur kritisk den är för verksamheten
- kvalitén på den aktuella koden i relation till kod i resten av systemet
- omfattningen av den funktionella förändringen som ska genomföras
När alla utvecklare jobbar enligt ovanstående överenskommelse och successivt bidrar till att vända trenden kommer resultaten att märkas efter en tid. Kod som ändras ofta kommer att få mest omsorg och störst mängd förbättringar, vilket förhoppningsvis också leder till att den blir lättare att förändra. Att all kod aldrig kommer att vara perfekt är dock ett faktum som man får acceptera. Glöm inte att kod som löser någons problem är värdefull kod.
En framgångsfaktor är att de förbättringar som görs har en riktning över tid. Initialt räcker det med en enkel målbild. Förståelsen av vilken typ av kod som eftersträvas vidareutvecklas under arbetets gång genom att teamet samarbetar och pratar om koden och hur den utvecklas.
En målbild kan innehålla konkreta exempel på problem och hur de bör angripas, tabellen nedan listar några exempel. Håll listan kort, och fokusera på de förbättringsområden som teamet tror har störst förbättringspotential.
| Problem | Nuläge | Önskat läge | Motivering |
|---|---|---|---|
| Anemisk domänmodell | Affärslogik som hör till ett specifikt domänobjekt ligger i services utanför domänmodellen (exempel: InvoiceHelper, CustomerHelper) | Logiken bör flyttas in i domänobjekten | För att minska duplicering, samla affärsregler |
| Affärslogik i databasen | Affärslogik implementerad i stored procedures i databasen | Logiken bör flyttas in i domänobjekten | För att öka testbarheten, separation of concerns |
| Återuppfinna hjulet | Egenutvecklad kod för funktioner som finns i standard-API:er eller tredjepartsbibliotek (exempelvis StringUtils, DateUtils, CollectionUtils, IOUtils, …) | Använd standard-API:er och tredjepartsbibliotek | För att minska mängden kod som behöver underhållas och minska antalet buggar |
| Library explosion | Många olika sätt, i egen kod och/eller tredjepartsbibliotek, för att göra samma sak (exempelvis loggning sker med flera olika ramverk, att läsa in en fil görs på olika sätt, jämföra datum, generera och tolka XML) | Återanvändning och likformighet | Minska duplicering, felkällor, lättare att verifiera och ändra |
| Avsaknad av automatiserade tester | Saknar automatiserade tester | Har automatiserade tester, som samtidigt dokumenterar affärsregler | Regressionstestning efter kodförändringar tar inte lika lång tid |
Teamet kommer också att behöva skaffa sig kunskap och erfarenhet av att skriva tester för och refaktorisera legacy-kod samt att i praktiken implementera de mönster som eftersträvas. Genom parprogrammering kan teammedlemmarna lära varandra olika refaktoriseringstips, tekniker för att skriva läsbar kod och allmänt förfina sitt hantverk. Några exempel på relevanta böcker för att ytterligare berika teamet med kunskap är: “Working effectively with legacy code” av Michael Feathers, “Refactoring” av Martin Fowler och “Clean Code” av Robert C. Martin.
Teamet kan också behöva bryta gamla inlärda beteenden. Exempelvis:
- att alltid gå direkt på den förändring som är beställd, vilket kan göra att det tar emot att lägga tid på att refaktorisera – eftersom detta inte i sig förändrar kodens beteende
- svårighet att avsluta refaktoriseringen och komma till skott med den beställda förändringen
- att skriva/ändra kod utan att ha test för vad du vill göra
Beteenden tar ofta tid att förändra, varför det är bra att ge sig själv just tid till detta samt att stötta varandra i förändringsprocessen. Se till att all kod som teamet arbetar med blir granskad av minst två personer, ännu fler om området är viktigt. Granska ofta och odramatiskt samt eftersträva ett prestigelöst förhållningssätt. Som granskare är det bra att ställa frågor istället för att direkt fälla omdömen.
För att lyckas med detta ser jag att följande behövs:
- En överenskommelse inom teamet om att vända trenden, helst också tillsammans med produktägaren.
- En gemensam målbild av hur koden borde se ut, och vad som bör förbättras.
- Ett gemensamt och kontinuerligt lärande genom parprogrammering och kodgranskningar.
Målet är att lyfta kodbasen närmare ett önskat läge. Var dock medveten om att all kod aldrig kommer att bli perfekt. Fokusera på att göra små förbättringar hela tiden. Små förändringar är lättare att genomföra i det dagliga arbetet, men ger stor effekt över tid.
Droppen urholkar stenen, inte genom sin kraft, utan genom att falla ofta. – Ovidius (43 f.Kr.-17 e.Kr)
Är du intresserad av att lära dig mer om Clean Code? Under våren kommer Citerus hålla ett frukostseminarium i ämnet, håll ögonen öppna!