Som konsult får man ofta läsa annonser där Självgående, Innovativ, Teamplayer och Konsultmässighet är egenskaper som efterfrågas. Samtliga vedertagna termer som alla vet vad de betyder även fast alla tänker på olika saker när de läser orden. Men i mitt fall fick jag upp ögonen för egenskapen att ”skriva förvaltningsbar kod”. Under mina två år som konsult har jag hör termen flera gånger, inte bara från säljare och rekryterare utan även andra utvecklare och alltid haft en idé om vad som menas med uttrycket. Jag har dock märkt att min åsikt har förändrats med tiden. När jag fått mer erfarenhet av systemutveckling och förvaltning har mina tankar kring Förvaltningsbar Kod också utvidgats. Det tror jag är ett tecken på att meningen med uttrycket Förvaltningsbar Kod inte är lika givet som många tror. Detta är min resa när jag försökte få bättre förståelse för termen Förvaltningsbar Kod.
Hur svårt kan det vara?
Det finns säkert en tydlig definition, det är bara att googla och läsa. Mina sökningar genererar dessvärre enbart uppdragsbeskrivningar där ”skriva förvaltningsbar kod” eftersöks, samt diverse kurser som utlovar att lära ut kunskapen. Ingen av dessa tycks dock se något värde i att förtydliga sin användning av termen. Ytterligare utforskning av ämnet (däribland utökning till engelska källor med termen ”Developing maintainable software”) gav följande resultat.
En ”IEEE Standard Terminology” definition som lyder:
"The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment."
Samt en större mängd diskussioner som bygger på boken Clean Code av Rober C. Martin som består av en mängd riktlinjer på hur man bör skriva sin kod för att den ska vara lätt att förstå. Jag tänker inte återge mycket av bokens innehåll här men för den intresserade finns en utmärkt sammanfattning här.
När jag lyfte frågan till mina härliga kollegor på Agero var det alltid tester som togs upp först. Motivationen är att det bästa sättet att kunna ändra i och underhålla ett system är att ha många välskrivna tester som verifierar att systemet gör som det ska även efter förändringar. Tester är också viktiga verktyg för att förstå syftet med systemet. En viktig aspekt av förvaltning är att förstå verksamheten och hur de använder sitt system, begreppet Förvaltningsbar Kod innefattar också hur lätt det är för en ny utvecklare att sätta sig in i systemets användning. Vikten av tester och testdriven utveckling kan du läsa mer om här.
Utöver dessa kod-nära synvinklar på Förvaltningsbar Kod finns det även större perspektiv att begrunda. Det är ett känt problem att många banker har svårigheter att finna kompetenta utvecklare för förvaltning av deras äldre system. Detta är inte för att systemen nödvändigtvis är dåligt designade eller att de tillgängliga programmerarna inte är kompetenta, utan för att dessa system ofta är skrivna i programmeringsspråket COBOL. Arkitekturella val så som integrationer, beroenden till andra system, datahantering och teknikval har också en mycket stor inverkan på ett systems förvaltningsmöjligheter. Min personliga erfarenhet av system med dessa typer av brister är att det inte är möjligt att förenkla förvaltningen av systemet på efterhand med prydligare kod, Förvaltningsbar Kod kräver att arkitekturen underlättar förståelse av systemet.
Vad har jag lärt mig så långt?
Jag tycker mig ha identifierat 3 nivåer av konceptet Förvaltningsbar Kod.
1. Syntax – Är koden tydligt skriven? Koden borde vara så optimalt skriven som möjligt utan onödig komplexitet, med bra uppdelningar av metoder och variabler. Språkets syntax ska följas och koden ska vara tydligt formaterad.
2. Tydlighet och tester – Är det lätt att förstå varför koden gör som den gör? Klasser och metoder ska ha tydliga och beskrivande namn och ska endast göra en sak. Det borde finnas tester som täcker systemets funktioner och tydligt specificerar hur systemet ska fungera.
3. Arkitektur – Är systemet designat på ett bra sätt? Systemet borde vara tydligt avgränsat med syfte och verkan. De tekniker och övergripande designvalen som görs i systemet ska vara väl motiverade och genomtänkta.
Dessa 3 nivåer blir också dyrare att åtgärda under förvaltning om de har slarvats med under utvecklingen. Dålig formatering av koden kan man nästan lösa automatiskt idag med de avancerade IDE;er som finns att tillämpa. Otydlig kod utan tester är mycket svårare att förvalta då det är riskabelt att göra förändringar i koden eftersom det inte blir tydligt vilka konsekvenser det får i systemet. En bristande Arkitektur betyder extra komplexitet i varje ärende under förvaltning i bästa fall och att systemet fallerar totalt i de värsta.
Sanningen är nog att Förvaltningsbar Kod är en komplex term som kan syfta på olika saker beroende på i vilket situation den används. För utvecklare kan det antagligen röra sig om 1, 2 eller alla 3 av dessa nivåer beroende på omständigheterna. När orden står att läsa i en jobbannons för systemutvecklare misstänker jag att författaren sällan lagt denna nivå av energi på att undersöka sitt ordval. En troligare förklaring är att kunden vill ha ett system som inte blir allt för dyrt att underhålla och inte lagt mer tankar på saken.
Är du sugen på att bli en av oss? Kontakta då Amanda på amanda.oberg@agero.se, eller skicka in en ansökan till några av våra lediga tjänster.
-
