Å jobbe effektivt med drittkode

Sunday, December 6th, 2009
Skriv en kommentar

Michael C. Feathers’ Working Effectively with Legacy Code er en ikke direkte ukjent bok. Jeg leste den i sommer, som en slags forberedelse til å begynne i ny jobb. Den hjalp meg til å hoppe uredd og med stor iver inn en voksende kodebase med varierende kvalitet. For dem som ikke kjenner Michaels mesterverket fra før, her er en kort beskrivelse:

Uttrykket “Legacy Code” brukes i utgangspunktet om gammel kode, kode som man arver fra andre. Benevnelsen innebærer at det er vanskelig å forså hvordan koden fungerer, og det er vanskelig å gjøre endringer. Michael Fethers definisjon på Legacy Code er kode uten automatiserte tester, fordi slik kode nettopp er vanskelig å forstå og å endre. Kode med tester derimot vil gi deg øyeblikkelig tilbakemelding på om du har ødelagt noe, og om endringene du har gjor fungerer som forventet.

Working Effectively with Legacy Code handler i bunn og grunn kun om én ting; nemlig hvordan man får på plass automatiserte tester rundt kode som i utgangspunktet ikke er designet for det, slik at man kan jobbe videre med koden uten å være redd. Gjennom kapitler som I Don’t Have Much Time and I Have to Change It og I Don’t Understand the Code Well Enough to Change It lærer Michael oss pragmatiske og presise teknikker som gjør oss mere komfortable med å ta i “drittkode”.

Kapitler som I Can’t Get This Class into a Test Harness, med avsnitt som The Case of the Irritating Parameter og The Case of the Hidden Dependency er gull verdt, og åpner øynene dine for hvordan det som ser helt håpløst ut faktisk kan løses. Dette er en oppskriftsbok, med en lang liste teknikker Feathers har funnet effektive i sin praksis. Mange av teknikkene er fokusert rundt det å bryte avhengigheter, som for eksempel Break Out Method Object, Expose Static Method, Extract and Override Call, Extract Implementer, Pull Up Feature og Push Down Dependency.

Hvem som bør lese denne boken, og hvorfor..

Denne boken har gitt meg en helt ny holdning til “dårlig kode”. Kode som er vanskelig å endre og som ikke har enhetstester er ikke lenger noe jeg gruer meg til å ta i – jeg ser nå på det som en spennende utfordring. Jeg gleder meg til å sette tenna i metoder på over tusen linjer og ekstremt høy kompleksitet. Helt seriøst, denne boken har tatt noe av det jeg likte minst ved yrket mitt, og gjort det om til noe av det jeg liker mest!

Hvis du kun jobber i perfekte softwareprosjekter, med elegant kode og høy test coverage, så har du ikke bruk for Michaels bok.

Ikke særlig mange sliker jobber, er det vel?

Hvis du derimot er på et team som sliter med en stor og uregjerlig kodebase.., hvis dere har problemer med å få laget gode enhetstester – eller å komme i gang med automatisert testing i det hele tatt.., hvis dere ikke er fornøyd med kvaliteten på koden dere jobber med, og den er vanskelig å forstå.., ja, da er Working Effectively with Legacy Code et uvurderlig hjepemiddel som dere bare må lese med en eneste gang. Legg ned utviklingen et par-tre dager, det er det faktisk verdt om utviklerne lærer seg disse teknikkene og lar seg inspirere til å bruke dem.

Kategorier: Bøker, Testing / TDD.
RSS feed for kommentarene. Tilbaketråkk.

6 kommentarer til “Å jobbe effektivt med drittkode”

Torbjørn Says:
December 7th, 2009 at 7:42 am
Og tusen takk til Halvard som lånte meg boken. Snart på tide du får den tilbake nå..
Jonas Follesø Says:
December 7th, 2009 at 10:09 am
Helt enig! Sammen med Clean Code er dette en av bøkene “alle” utviklere burde lese. Den fokuserer på noe utrolig viktig og relevant for den jevne utvikler. De færreste jobber med green-field prosjekter eller de nyeste rammeverkene og API-ene. En bok som fokuserer på hvordan lykkes i en “håpløs” kodebase er gull verdt.

Selv har jeg lest boken i parallell med å jobbe med en større refaktorering av en grusom kodebase. Det har vært en utrolig gøy måte å jobbe på – hvor jeg både har gjort en bedre jobb, samtidig som jeg har hatt større utbytte av boksen siden jeg har hatt mulighet å prøve ideene i praksis.

Har funnet et par nye teknikker selv planlegger å dele på bloggen etter hvert :)

- Jonas
Jørgen Says:
December 7th, 2009 at 11:11 am
Interessant artikkel! Tror jeg skal begynne å kode igjen ;-) Halvard må få boken sin tilbake snart slik at vi kan ta tak i dette…
Øyvind Fanebust Says:
December 7th, 2009 at 11:49 am
Bra tips til alle som sliter med gammelt og ny drittkode. Denne boken er gull verdt!
Jon Arild Tørresdal Says:
December 9th, 2009 at 9:42 pm
Enig at dette er en veldig bra bok. I etterkant av utgivelsen av boken er definisjonen til Michael diskutert. Ikke alle var enig i den :-) Vet ikke om du husker vi diskuterte definisjonen av legacy code med Dan North? Han hadde også diskutert dette med Michael selv, og de var enige om at den ikke “var riktig”. Dvs den er mer i retning av kode som vanskelig lar seg endre, har mange uønskede dependencies osv. Dvs. det er kode som er testbar som er legacy kode.

Et annet aspekt jeg synes er viktig å få frem er at legacy kode nødvendigvis ikke gjelder gammel kode. Jeg har sett kode som kommer rett ut av ovnet som jeg vil definere som legacy. Dette er kansje å trekke selve begrepet litt langt, ettersom legacy (i den virkelige verden) oftest omhandler å overta noe fra andre (f.eks. arv), men når det gjelder fokuset og tema til boken vil jeg påstå det er mer riktig. M.a.o. boken er nyttig selv for de som jobber på greenfield prosjekter.

Et verktøy som er svært nyttig i arbeid med denne type kode er NDepend. Spesielt med tanke på å finne hvor de største utfordringene i koden er, samt å definere regler for uønskede dependecies e.l. Tenker vi kanskje skulle kjørt et legacy tema på NNUG… Jeg kjører gjerne en sesjon om NDepend.
Torbjørn Says:
December 9th, 2009 at 10:25 pm
Begrepet “Legacy Code” har blitt diskutert mye, men i forhold til boken er det ikke så veldig nøye. For som jeg påpeker handler boken om teknikker man kan bruke for å refakturere fra kode som ikke lar seg enkelt teste med automatisert testing, til kode som enklere lar seg teste. Min egen oversettelse – “drittkode” – var det begrepet jeg ble tilbudt når jeg spurte utviklermiljøet på twitter hva de ville ha oversatt legacy Code med. :)

Hvis folk ikke har sett NDepend in action fra før så tror jeg det vil kunne bli en populær sesjon på NNUG. Om man skal gå litt mer i dybden er det derimot et ganske tungt tema mener jeg, så da er jeg litt usikker.