Jeg er sikker på, at læseren af denne artikel enten selv har været med til at tage beslutning om implementering af et system og/eller har været den, der skulle implementere det. I så fald er der ingen tvivl om, at man også har været vidne til dele af implementeringen af systemerne, som ikke er optimale – men som i det mindste får softwaren i luften. Allerede her møder vi den tekniske gæld.
Hvad er teknisk gæld?
Teknisk gæld kommer oftest til udtryk på to forskellige måder:
- Et system har været operationelt i længere tid, men der har ikke været tid og ressourcer til at holde systemet opdateret med nyeste pakker og versioner. Dette gør ikke blot programmet mindre sikkert, men kan også gøre det sværere at vedligeholde på længere sigt – især hvis omkringliggende systemer ikke længere understøtter teknologien, det ældre system er bygget på, og viden om det er ved at gå tabt på grund af udskiftning i ressourcer.
- Den hurtige løsning, der virker her og nu. Bare fordi et nyt system bygges med de nyeste teknologier, betyder det ikke nødvendigvis, at du bliver fri for teknisk gæld. Ofte, når vi skal have nye systemer i luften – især dem, hvor der ikke før har været et system – så er man tilbøjelig til at lave den løsning, der virker lige her og nu, med løftet om, at man kommer tilbage og fikser det senere. Spoiler: Det gør man dog næsten aldrig, for det næste projekt står jo for døren – så der er ikke lige tid.
Hvorfor er teknisk gæld et problem?
Her kan man være tilbøjelig til at tænke: "Og hvad så? Systemet kører jo, det har det gjort i mange år, og vi sørger bare for, at der er nogle få folk, der holder det i live og fikser eventuelle bugs, der måtte opstå." Men det er lige præcis det, der kan blive problemet. Investering i vedligehold og reduktion af teknisk gæld kan virke som umiddelbart spild af ressourcer, for det er jo ikke, fordi systemet rigtig ændrer sig? Men disse bugs og andre fejl vil med al sandsynlighed blive flere og flere i takt med, at andre systemer opdateres – såsom hardware og afhængigheder til eksternt software. Lige pludselig har man sine udviklere til at sidde fuldtid og prøver at holde et system i live, i stedet for at implementere ny forretningskritisk funktionalitet.
Hvad er clean code-princippet?
Det ligger lidt i navnet: Man vil gerne holde koden så ren, simpel og forståelig som muligt. Det skal være nemt at teste og skal kun indeholde de ting, man faktisk har brug for. Selvom dette lyder, som om en udvikler har mindre at lave, så ligger der meget tid og mange kræfter i at overveje, hvordan det hele skal spille sammen – således at man kan reducere og/eller helt fjerne gentagelser af kode og funktioner samt gøre testbarheden af systemet nemmere og mere robust. Dette er også en øvelse i at begrænse sig, samtidig med at man holder sig fleksibel – således at ændringer kan justeres løbende i takt med, at systemet former sig, og forståelsen for problemet, man løser, bliver bedre og bedre.
Hvorfor bruge clean code som en del af løsningen?
Hvis du er udvikler, så har du sikkert prøvet at overtage et andet teams programmer eller en tidligere kollegas kode – og ofte har du sikkert tænkt: "Hvad i alverden bruges den her til?" Måske har du oplevet, at der er linjer på linjer af kode, som tilsyneladende ikke bruges længere, men du tør ikke slette dem – ligesom din tidligere kollega ikke turde.
Så du udvider også bare funktionen med hvad end, der skal til for at løse den nuværende fejl. Hvis du i stedet var blevet mødt af en kodebase, hvor tingene bestod af små funktioner, der var veldokumenterede, testede og blev brugt, så er opgaven med at forstå koden meget mindre – og du kan nu selv fjerne og ændre de ting, der er nødvendige, med ro i maven.
Det, man har opnået ved at have fokus på at holde kodebasen ren, minimal, testbar og dokumenteret, er, at alle ændringer, der sker i løbet af softwarens levetid, kan ske med fuld forståelse for konsekvensen i systemet – uden alt for meget tid brugt på gætværk og undersøgelse.
Med andre ord: Den tekniske gæld er ikke blot mindre – den er også meget nemmere at følge med i. Det skal dog nævnes, at det ikke bare handler om små funktioner og delelementer af systemer – men også om simple og læsbare funktioner. Brug hellere en ekstra linje eller to på at udspecificere koden, så den er nemmere at læse – både for dig selv og for andre.
Det lyder nemt – hvorfor gør vi ikke bare altid det?
Jeg er ikke i tvivl om, at mange af jer og jeres udviklere gør alt, hvad de kan, for at holde det rent og overskueligt. Men så er der jo bare lige de stunder: Der er et lille problem, der vil tage fem minutter at løse – og der er alligevel en masse andre ting, der skal fikses. Så tænker man: "Jeg kan hurtigt tjekke den af ved at lave det sådan her." Bum bum bum. En midlertidig løsning bliver permanent – og den er ikke rigtig dokumenteret. Næste gang kan vi ikke finde hoved og hale i, hvad vi har gjort og hvorfor – så i stedet for en ændring, der, hvis den blev gjort ordentligt, burde have taget 30 minutter, bruges der nu en time på at huske, hvad vi gjorde og hvorfor, inden vi kan gå i gang med at fikse det reelle problem.
Jeg er ikke udvikler – hvorfor skulle jeg bekymre mig om dette?
I så fald burde du nok faktisk være en af dem, der bekymrer sig allermest om dette emne. Chancen er, at du så enten er teamlead, projektleder eller har en anden funktion, hvor du beslutter, hvornår ting skal laves, hvor hurtigt det skal laves, og hvor mange ressourcer der skal bruges på vedligehold. Tænk på dette, når der estimeres, hvor lang tid ting tager – og vær med til at fostre et miljø, hvor det er værd at bruge tid på at følge clean code-principper.
Skal det gå hurtigt – fx ved release af et system tæt på deadline, så planlæg allerede nu at få udbedret de "midlertidige" løsninger efter release, når der er lidt mere ro på. For hvis den eneste gang, du faktisk allokerer tid til at kigge på teknisk gæld, er ved bugs eller når systemerne er helt udgået, så har du allerede tabt. Hvad der kunne være få timer om ugen spredt ud over år, er nu et årsværk i ressourcer, der skal bruges på at forstå et system og udrede eventuelle fejl og mangler og sikkert meget hurtigt, så det hele bare gentager sig selv.
Nu vil jeg gerne i gang – men vi har allerede mistet overblikket over systemet. Hvad gør vi?
Først og fremmest: Det er præcis det, der skal til for at opretholde et sundt og stabilt IT-landskab – og der er ingen skam i at indrømme, at et system er ved at gå tabt til teknisk gæld.
Dernæst skal det overvejes, hvad der skal til:
- Er det en simpel oprydning af systemet, hvor man går ind og laver funktioner til testbare enheder, opdaterer dokumentationen og fjerner død kode? Så tag det bid for bid, hvis systemet fungerer, som man ønsker i dag.
- Er det en modernisering og opdatering af systemet? Så bør man starte helt forfra ved tegnebrættet, så man får bygget et system, der har de funktioner, det har brug for, til at løse det forestående problem. Hvad end det er, så vil den tid, der bruges, komme tilbage hen ad vejen som langt mindre omkostningsfyldt vedligehold, både i tid og penge.
Modernisering og opdatering af systemer er velegnet til at sætte både nye og erfarne ressourcer til – da det er med til at modne forståelsen af systemet og skabe vidensdeling på tværs af erfaringer.
TL;DR:
Prioritér clean code som et værktøj mod teknisk gæld – og afsæt ressourcer til at holde systemer up-to-date. Foster et miljø, hvor der er plads og tid til at gøre tingene rigtigt – så systemer kan forblive moderne og stabile, indtil de skal udskiftes. Hvis man bliver tvunget til den hurtige løsning – så anerkend det, og planlæg allerede tid til at fikse det efter release. Ellers risikerer man, at det bliver starten på enden for et ellers velsmurt og veldokumenteret system.
Mangler du sparring på, hvordan du kommer videre i din digitalisering – eller vil du høre mere om, hvordan vi kan hjælpe dig med at reducere teknisk gæld og skabe fremtidssikre systemer? Så kontakt os på +45 61 77 70 70 eller skriv til rasmus.halvor@soprasteria.com
Kontakt os
Læs mere om vores projekter
Digitalisering i Radiometer Selvbetjening hos Telia Ny dataplatform hos Stokke Procesautomatisering hos Hovedstadens Beredskab Alle Projekter