Source Code Quality February 16, 2011 14:50 about 1 year ago
Hvad er kodekvalitet? I et stykke tid har jeg arbejdet i en IT organisation hvor de ofte bruger udtrykket kodekvalitet om alt fra en dårlig algoritme til design der stinker som en gamle elefant. Jeg ved hvad beautiful code er men jeg aner ikke hvad de taler om!
Kildekoden i forbindelse med softwareudvikling dele normalt op i to hovedgrupper hvor både pris og arbejde kan placeres. Første del er når selve koden skrives mens den anden er hele den periode hvor den vedligeholdes. Denne opdeling kaldes for 90-10 regelen fordi det erfaringsmæssigt har vist sig at det koster 10% at fremstille men hele 90% at vedligeholde.
I en fornuftig forretning vil man sikkert betragte softwaren som god kvalitet hvis den virker. Den sorte box. Vi går ud fra at de har betalt de første 10% denne applikation vil komme til at koste over de næste 5 år.
Men nu skilles vandene. For det kan faktisk lade sig gøre at spare penge. Hvis produktet virkeligt er at høj (kode) kvalitet vil det ikke nødvendigvis afspejle sig direkte i et produkt når det købes men først når det har været i drift i form af omkostninger.
Hvis produktet derimod er af ringe (kode) kvalitet kan det på sigt, ikke alene give langt større omkostninger men også reducere tilgængelighed for nye features. Produktet nedbringer den samlede profit og dermed sin livslængden.
Kodekvalitet er at “koden” er læsbar !
Hvorfor kaldet vi det kode. Burde det ikke bare være tekst? Det skal kunne læses af andre programører, og også gerne af andre, måske en forretningsperson. Det er ikke maskine til maskine men menneske til menneske interaktion at skrive kode. Faktisk er det dumt at vi skal bruge en programmør til at skrive “noget i kode” som han bagefter skal dokumentere fordi det er rodet, alle ved jo at en programmør ikke kan skive noget læsbart i et dokument. Gad vide om man kan være ordblind som programmør?
Lad og lege at softwaren er taget i drift og der er opstået en defekt. Det bliver nødvendigt at dykke ned i den sorte box. Alle vil med det samme slå sig selv på skulderen og fastslå at kodekvaliteten er ultra lav. Det er helt naturlig og kun fordi ingen forstå koden. Forhåbentligt, nogen gange har de ret.
Som regel er dykket i den sorte box som en repræsentation af de ressource der findes på det sted hvor software blev udviklet. Der vil ofte være et stort lighedstegn mellem ansattes engagement og deres subjektive opfattelse af kodekvalitet.
Kodekvalitet på dette niveau er meget individuelt men helt generelt kan man anføre en mængde datalogiske principper og mønstre hvormed kode kan identificeres. Hvordan disse datalogiske principper og mønstre bliver fortolket blandt medarbejderne er nok mest op til virksomhedens ansættelsespolitik. I denne proces er den fælles forståelse og commitment langt den vigtigste faktor.
I alt sin enkelthed har Ward Cunningham, udtalt at god kode er når man ser en rutine med et godt sigende navn som indeholder det man forventer, altså det svare til den opgave der løses. Kodekvalitet er ikke noget der pr automatik opstår første gang man skriver en metode. Hvis en metodes omverden ændre sig må man revurdere alle aspekter af metoden og tilpasse til den ønskede kvalitet.
Kodekvalitet handler mere om arbejdsmetode og disciplin fremfor selve implementeringen. Har man en klar holdning til kodekvalitet kunne man adobtere en udviklingsmetode der understøtter kodekvalitet som fx Test Driven Development. TDD beskriver processen som den vigtigste bestanddel for at opbygge, forbedre og vedligeholde en kodebase på en iterativ, sikker og robust måde.
Ydermere giver TDD en god sikkerhed når man har flere sideløbende versioner af soruce kode med forskellige fremgangsmåder. Metoden tilføre en mængde tests som skal kunne eksekveres mellem alle forandringer større end ca. 3 min. Korrekt udført giver denne metode alle i projektet en frihed til at kunne gøre noget ved problemerne frem for at sige “dette røre jeg ikke ved” og “if it works, don’t fix it”.
Komponentkvalitet
I bogen Struktureret System Analyse fra 70’erne er en udmærket beskrivelse hvordan man overholder en klar komponent opdeling. Bogen beskriver også på bedste vis hvorfor det er vigtigt? De fleste applikationer er opbygget i lag og hvert lag udfylder respektive opgaver. fx er det normalt at et lag håndter de persistente data nedadtil og andre lag opadtil behøver ikke koncentrere sig om hvordan fx det persistenlag er implementeret. Mellem de enkelte lag beskrives et interface så man indkapsler implementeringen bag disse interfaces på en simple og hensigtsmæssig måde. Al tilgang til et lag skal gå gennem interface for at overholde komponent tankegangen.
Når man som programmør skal implementere en ny funktionalitet er det vigtigt at man benytter de korrekte interfaces og ikke forbigår dem ved at referere objekter på den anden side af interfacet. Hvis disse interfaces ikke overholdes kan man skabe en lang række af potentielle problemer der rækker fra almindeligt rod til kompilere fejl. Det vigtigste issue ved komponent opdeling er dog af arkitektonisk art. Lead arkitekten bør tidligt i projektet fastlægge en komponentopdeling som tydeligt tager højde for alle eksterne systemgrænseflader og de interne komponent objekt hirakier og deres indbyrdes livforløb. Så behøver man ikke fucke det op med versionstyringssystemerne.
Blev jeg klogere af dette. Ja, det er gået op for mig undervejs at kodekvalitet har noget kulturelt over sig. Især hvis man befinder sig i en organisation der ikke kommer meget ud, de har ligesom deres egen syn på mange ting.. Også kodekvalitet
By Frank Vilhelmsen - 1 tag: architecture - Add comment