En uafhængig gennemgang af koden er en vurdering, hvor en erfaren udvikler uden tilknytning til jeres leverandør læser koden og beskriver, hvad vedkommende finder. Gennemgangen kan sige noget om kvalitet, tekniske risici og hvor afhængige I er af bestemte personer eller teknologier. Den kan ikke sige, om produktet er det rigtige, om leverandøren er ærlig, eller hvor længe næste funktion tager. Den er mest værd, når ledelsen har stillet et klart spørgsmål på forhånd og skal bruge svaret i sin egen planlægning.
Hvad en gennemgang kan svare på
En gennemgang (code audit eller second opinion) er nyttig til spørgsmål som disse:
- Er koden til at arbejde videre på? Er den opdelt, så ændringer kan laves ét sted, eller hænger alt sammen med alt?
- Hvor ligger de tekniske risici? Gamle komponenter, adgangskoder skrevet direkte i koden, manglende sikkerhedskopier eller steder, hvor en enkelt fejl kan vælte meget.
- Hvor afhængige er I? Kan andre udviklere tage over, eller er der opbygget særheder, som kun én kan finde rundt i? Se også når én udvikler kender hele koden.
- Er arbejdsgangen sund? Viser historikken i kodelageret faste kodegennemgange, test og små ændringer?
- Stemmer det med det, I har fået at vide? Findes det, der er beskrevet i rapporterne, også i koden?
Svarene bliver bedst, når de sammenholdes med et formål. Samme kode kan være fin til en lille prototype og uholdbar til et produkt med mange kunder, og derfor skal den, der gennemgår, vide, hvad produktet skal kunne.
Hvad en gennemgang ikke kan svare på
Gennemgangen er et øjebliksbillede. Den kan vise tegn på, at teamet har travlt eller mangler erfaring, men den afgør ikke, om leverandøren har handlet forkert eller svigtet en aftale. Det kræver, at nogen sammenholder koden med det aftalte, og i en tvist er det en sag for advokat og eventuelt en sagkyndig.
Den kan heller ikke måle, om produktet passer til markedet eller om brugerne vil betale. Og den kan sjældent give et præcist tal for, hvor lang tid en omskrivning tager. Den kan give et velbegrundet skøn, men et skøn er det. Teknisk gæld kan beskrives, men hvor meget der skal betales af, er en ledelsesbeslutning, se teknisk gæld forklaret for ledelsen.
Bedre værktøjer gør ikke forskellen mindre. Automatiske scanninger kan finde mange kendte fejl i komponenter og koden, men de kan ikke vurdere, om opbygningen passer til jeres produkt. Får I en rapport, der blot er output fra et værktøj, har I købt en liste uden en vurdering.
Sådan stiller I spørgsmålet
Skriv formålet ned på én side, før nogen går i gang:
- Hvilken beslutning skal gennemgangen hjælpe med?
- Hvad skal produktet kunne de næste to år?
- Hvilke dele er vigtigst?
- Hvad bekymrer os konkret?
- Hvilken form skal svaret have?
Bed om en kort ledelsesdel i almindeligt sprog, en liste over fund sorteret efter betydning og forslag til næste skridt. Bed også om det, der er godt. En rapport, der kun finder fejl, siger mest om, hvad en anmelder forventes at aflevere, og alle kodebaser har ting, der ser mærkelige ud for en ny læser.
Afgrænsningen er vigtig. En stikprøve af de vigtigste dele giver ofte det meste af svaret, mens en fuld gennemlæsning sjældent svarer sig, medmindre der er særlige grunde.
Sådan inddrager I den nuværende leverandør
Gennemgangen bliver bedre og mere fair, når den nuværende leverandør ved besked og kan forklare baggrunden. Mange valg, der ser forkerte ud, havde en grund. Stramme tidsplaner eller et ønske fra jer selv kan have ført til det, en ny læser ser.
Præsenter det som en normal kontrol af jeres egen investering. Bed leverandøren om en kort gennemgang af produktets opbygning til den, der skal læse koden, og lad leverandøren kommentere udkastet, før det er færdigt. Så kan misforståelser rettes, og I bevarer samarbejdet, hvis det skal fortsætte.
Hold øje med, hvem der vælger den, der gennemgår. Foreslår en ny leverandør at gøre det, er den ikke uafhængig, for den står til at vinde opgaven. Læs de tre spørgsmål til den slags forslag, hvis I står dér.
Tjek også, at I har ret til at vise koden til en tredjepart. Se aftalen med leverandøren, og indgå en skriftlig fortrolighedsaftale med den, der læser koden. Tvivl af den slags tager I med en advokat. Koden skal I i øvrigt selv kunne hente, se ejer I selv koden og kontiene.
Når svaret er kommet
Læg rapporten ind i jeres egen planlægning. Find de punkter, der skal handles på nu, dem, der skal med i køreplanen, og dem, I bevidst lader ligge. Giv punkterne en ejer, og følg op. En rapport i en skuffe forandrer ingenting.
Stod I i en situation, hvor projektet var kørt fast, er næste trin at bruge svaret, når I skal vælge vej videre, se brændt af et udviklingshus.
Det skal I lade være med
- At bestille en gennemgang uden et spørgsmål · så får I en liste, I ikke kan bruge.
- At holde leverandøren helt ude · I mister baggrunden og måske samarbejdet.
- At lade en kommende leverandør bedømme koden · den har en interesse i svaret.
- At læse rapporten som en dom · den er et grundlag for en beslutning.
Det skal I kræve af den eksterne
- ☐ Åbenhed om bindinger til jeres leverandører og mulige afløsere.
- ☐ Klar beskrivelse af, hvad der er set, og hvad der ikke er set.
- ☐ En ledelsesdel, som en ikke-teknisk stifter kan læse.
- ☐ Fund sorteret efter betydning for jeres formål.
- ☐ Fortrolighed om kode og forretning.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skal produktet skrives om? · Sådan styrer I en udviklingsleverandør, der bygger produktet
