Kaffepause

The boy scout rule og smidige prosjekter

Den originale speiderregelen sier at du skal etterlate leirplassen ryddigere enn den var da du fant den. Robert C. Martin overførte dette begrepet til programmering i sin bok om Clean Code. Her sier han at man alltid skal etterlate kode ryddigere enn man fant den.

It’s a challenge

Det høres enkelt ut, og i noen prosjekter kan det være overkommelig. I de fleste prosjekter derimot kan dette være en ganske stor utfordring. Koden man jobber med stammer kanskje fra en tid da Clean Code bare var en idé. Et ønske fra en utvikler som så seg lei av å bruke mange timer for å skjønne koden bak en relativt enkel funksjonalitet. En kodebase full av snarveier og hacks. I slike kodebaser er det vanskelig nok å få inn ny funksjonalitet om man ikke i tillegg skal forbedre den. Ofte vil du fortsette å jobbe med den opprinnelige kodebasen samtidig som du drømmer om å få implementere koden på nytt fra bunnen. Det du må huske er at alle snarveiene og hackene som regel er bugfixer eller ny funksjonalitet som er tilført i etterkant. Starter du fra bunnen av vil du ofte ende opp med å gjeninnføre gamle feil. Du risikerer også å gå i samme fella som de gikk i da den eksisterende kodebasen var ”state of the art”. Husk at den som skrev denne koden er like smart som deg og meg.

Rom ble ikke bygd på én dag

La oss ta en nærmere titt på regelen. ”Etterlat koden ryddigere enn den var da du fant den”. Det betyr ikke nødvendigvis at du skal revolusjonere den. Fikse alle problemene på en gang. Nei, se heller på hva som er de viktigste tiltakene du kan gjøre. Helst uten å bruke for lang tid. Kanskje utbedrer du bare en eller to ting, men neste gang noen jobber med samme klasse vil de utbedre enda flere ting. På denne måten vil kodebasen gradvis bli enklere å forstå, enklere å jobbe med og enklere å teste.

Så hvorfor er denne regelen så viktig for smidig utvikling?

Når man jobber smidig er det et prinsipp at man ikke skal lage mer enn det som er nødvendig. Derfor vil man alltid komme bort i kode som ikke er optimalisert for utvidelser og gjenbruk, eller for den ytelsen som er påkrevd osv. Det vil alltid være elementer som ved implementering ikke var nødvendig. I tillegg vil arkitekturen være mangelfull på enkelte områder når vi jobber smidig. Her vil speiderregelen være særdeles viktig for å bevare en god arkitektur og en enhetlig, enkel kodebase. Så hvordan skal du gå frem? Dersom koden nå trenger et lite løft på arkitekturen må du vurdere det arbeidet som må til. Er det veldig store/inngripende endringer kan det være fordelaktig å opprette en egen brukerhistorie på det, men dersom det et overkommelig stykke arbeid bør du gjennomføre det. Gjerne som en parprogrammeringsøkt. Dersom koden er veldig bra i utgangspunktet kan du investere litt tid i det kosmetsike som navngivning av metoder/variabler samt oppbyggingen av klassen med struktur og oversiktelighet. Hver gang du utvider en klasse er det ditt ansvar at koden har blitt bedre. Enklere. Det er ditt ansvar at koden er clean.

Tommy Bø er en erfaren seniorkonsulent i Visma Consulting og er fagmanager for faggruppen Software Craftsmanship. Tommy er generell ekspert på java og er opptatt av kodekvalitet, både at den skal være godt strukturert og lett å forstå og at den skal ha automatiserte tester som verifiserer forventet oppførsel og gjør koden lett å vedlikeholde. I tillegg jobber han mye med kontinuerlige leveranser og automatisering av prosesser rundt dette.
Kontakt Tommy: