Kodekvalitet: 12 tegn på at din kodebase er sund (eller syg)

Kodekvalitet kan du godt vurdere selv, også selvom du aldrig har læst en linje kode. En sund kodebase viser sig i hverdagen: ændringer kommer i drift ofte og uden drama, fejl bliver fanget før kunderne ser dem, og systemet hænger ikke på én bestemt udvikler. Herunder er 12 tegn du kan tjekke med et login og et par spørgsmål, og hvad du gør hvis flere af dem peger den forkerte vej.

Jeg er freelanceudvikler og overtager og vedligeholder eksisterende systemer, så jeg har en interesse i emnet. Derfor er der også et afsnit om hvornår en rodet kodebase er helt i orden.

Den korte version

Tabellen samler de 12 tegn. Gå den igennem og sæt et kryds ved hvert tegn hvor din situation ligner kolonnen "Sygt" mere end "Sundt".

Min tommelfingerregel: 0-2 kryds er normalt for et system der har været i brug et stykke tid. 3-5 kryds betyder at nogen bør se koden igennem inden for de næste måneder. Ved 6 eller flere, eller et kryds ved tegn 5, 6 eller 10, bør du handle nu, fordi netop de tre tegn kan blive akutte fra den ene dag til den anden.

Tegnene hænger tæt sammen med hvordan et system bliver bygget og drevet. Den del gennemgår jeg i guiden til hvordan et softwareprojekt foregår fra idé til drift.

Tegn du kan se uden at åbne koden

De første fire tegn kræver ingen teknisk viden. Du kan se dem i din indbakke, på dine fakturaer og i hvad dine kunder klager over.

1. Ændringer kommer i drift ofte og uden drama

I en sund kodebase er en udgivelse en kedelig begivenhed. Små ændringer går live i løbet af ugen, og ingen holder vejret. I en syg kodebase samles ændringerne i store udgivelser et par gange om året, gerne om aftenen eller i weekenden, og der følger en runde brandslukning bagefter.

Forskningsprogrammet DORA undersøger hvordan softwarehold leverer, og måler blandt andet hvor ofte der udrulles, og hvor tit en udrulning skal rettes med det samme. Deres konklusion er at hastighed og stabilitet ikke er modsætninger: de bedste hold klarer sig godt på alle målene, og de svageste klarer sig dårligt på dem alle. Små, hyppige leverancer er også kernen i agil udvikling, som jeg sammenligner med den klassiske model i agil udvikling vs vandfald.

Sådan tjekker du det: Spørg hvornår der sidst blev sat noget i drift, og hvor mange gange det skete den seneste måned. Et system der sjældent ændres, behøver ikke udgivelser hver uge. Pointen er om en færdig ændring kan komme ud hurtigt når den skal.

2. Små ændringer koster små beløb

Et nyt felt i en formular, en ændret tekst i en e-mail eller en ekstra kolonne i en eksport bør tage timer, ikke uger. Når selv småting bliver til projekter, er det typisk fordi koden er viklet sammen, så én ændring kræver ændringer ti andre steder.

Ikke alt der ser lille ud, er lille. Et nyt felt kan godt skulle med i fakturaen, i rettighederne og i integrationen til regnskabssystemet. Forskellen ligger i forklaringen. Et sundt svar er konkret og nævner hvad der påvirkes. Et sygt svar er "det er mere kompliceret end det ser ud", hver gang.

Sådan tjekker du det: Find de seneste fem små ønsker og se hvor lang tid der gik fra ønske til drift, og hvordan estimatet passede med virkeligheden. Fordobles estimaterne igen og igen, er det et tegn.

3. Rettede fejl forbliver rettede

En fejl der er rettet, bør blive væk. I en syg kodebase dukker den samme fejl op igen efter et par måneder, eller rettelsen af én ting ødelægger noget et helt andet sted. Det kaldes en regression, og det skyldes oftest at der ikke er automatiske tests, som jeg vender tilbage til under tegn 9.

Sådan tjekker du det: Kig i din supportindbakke eller dit opgavesystem. Er der fejl der er meldt to gange? Følger der en ny runde "nu virker X ikke" efter hver udgivelse?

4. Fejl bliver opdaget før dine kunder gør

Ingen systemer er fejlfri. Forskellen er om fejlene er kendte. I en sund opsætning logger systemet fejl i et overvågningsværktøj, fx Sentry eller Flare, og der er overvågning af om siden overhovedet svarer. Udvikleren får besked og har ofte rettet fejlen før nogen ringer.

I en syg opsætning hører du om fejl fra dine kunder, og ingen ved hvor mange fejl der egentlig sker.

Sådan tjekker du det: Spørg hvor mange fejl systemet logger om ugen, og hvem der får besked. Et sundt svar er et tal og et navn. "Det ved jeg ikke" er et svar i sig selv.

Tegn i hvordan arbejdet er organiseret

De næste fire tegn handler om mennesker og adgang. Efter min vurdering er de de vigtigste, fordi de afgør om du kan skifte udvikler, få hjælp i en krise og bygge videre uden at starte forfra.

5. Mere end én person kan arbejde i koden

Udviklere taler om busfaktoren: hvor mange personer skal forsvinde før projektet går i stå? Er svaret én, er det din største risiko, uanset hvor god koden ellers er. Ferie, sygdom eller en opsigelse kan stoppe al udvikling, også når der er en kritisk fejl.

Det gælder også når du arbejder med en freelancer som mig. Jeg er én person, og derfor bør koden ligge på din konto fra første dag og være dokumenteret, så en anden udvikler kan tage over.

Sådan tjekker du det: Spørg hvem der kunne rette en kritisk fejl hvis din udvikler var væk i en måned. Har du adgang til koden, kan du også se hvor mange forskellige navne der står i historikken det seneste år.

6. Du ejer koden og kan se historikken

Koden bør ligge i et versionsstyringssystem (Git) hos fx GitHub, GitLab eller Bitbucket, på en konto din virksomhed ejer. Udvikleren får adgang som bruger og kan fjernes igen. Historikken viser hvem der har ændret hvad og hvornår.

Det syge tegn er kode der kun findes på udviklerens computer eller server, en konto i udviklerens navn, eller at ingen helt ved hvor den nyeste version ligger.

Sådan tjekker du det: Bed om læseadgang og kig på de seneste 20 ændringer. Du behøver ikke forstå koden, men du bør kunne se at der sker noget, og beskeder som "rettet fejl i fakturaeksport" fortæller mere end "fix" og "wip". Kan du slet ikke få adgang, er det et rødt flag.

7. En ny udvikler kan komme i gang på en dag

En sund kodebase har en README-fil (en vejledning i roden af projektet) der forklarer hvordan man starter systemet, hvad det kræver, og hvordan det sættes i drift. En ny udvikler kan have det kørende på sin egen computer inden for en dag.

Kode der følger et udbredt framework og dets konventioner, er også lettere at overtage, fordi en ny udvikler genkender strukturen. Det er en af grundene til at jeg vælger Laravel som standard til webapps.

Sådan tjekker du det: Spørg hvor lang tid det tager en ny udvikler at få projektet op at køre. Et sundt svar er timer. Et sygt svar er "det er lidt besværligt, men jeg kan hjælpe".

8. Ændringer bliver tjekket før de går live

På mange hold går hver ændring gennem et ændringsforslag (pull request), som en kollega læser igennem. Samtidig tjekker automatiske værktøjer kodestil og typiske fejl, fx PHPStan til PHP og ESLint til JavaScript. I en syg kodebase går ændringer direkte fra én computer til drift, uden at nogen eller noget har kigget på dem.

Ærligt talt har en freelancer der arbejder alene, ikke altid en kollega til at læse med. Så skal automatiske værktøjer og tests bære mere af vægten, og ved store ændringer kan det være pengene værd at få en anden udvikler til at kigge med.

Sådan tjekker du det: Spørg hvad der sker fra en ændring er færdig, til den er i drift. Har du adgang til GitHub, kan du se om der er ændringsforslag med grønne flueben fra de automatiske tjek.

Tegn du kan spørge din udvikler om

De sidste fire tegn ligger under motorhjelmen. Du kan ikke se dem selv, men du kan stille et konkret spørgsmål til hvert af dem og vurdere om svaret er konkret eller undvigende.

9. Der er automatiske tests, og de kører ved hver ændring

Automatiske tests er kode der tjekker koden: at en kunde kan logge ind, at en faktura bliver regnet rigtigt, at den samme tid ikke kan bookes to gange. De kører automatisk hver gang der laves en ændring, og fejler en test, kommer ændringen ikke i drift.

Antallet af tests siger ikke så meget i sig selv, og 100 % testdækning er ikke målet. Det vigtige er at de arbejdsgange der tjener penge, er dækket. Hvorfor det også betaler sig i små projekter, har jeg skrevet om i indlægget om automatiserede tests og hvad de sparer.

Sådan tjekker du det: Spørg hvilke af dine vigtigste arbejdsgange der er dækket af tests, og hvad der sker hvis en test fejler. Det sunde svar er "så kommer ændringen ikke ud".

10. Framework og sprog får stadig sikkerhedsrettelser

Frameworks og programmeringssprog har en udløbsdato. Laravel giver sikkerhedsrettelser i 2 år pr. version, og ifølge Laravels supportpolitik mister Laravel 12 dem 24. februar 2027. PHP får 4 års support pr. version, og sikkerhedsrettelserne til PHP 8.2 stoppede 31. december 2026.

Når supporten udløber, holder systemet ikke op med at virke. Det holder bare op med at blive lappet, og næste offentlige sikkerhedshul bliver ikke rettet i din version. Hvorfor det koster at vente, og hvordan du opdaterer sikkert, står i indlægget om opdatering af framework og pakker.

Sådan tjekker du det: Spørg hvilken version af framework og sprog systemet kører, og hvornår supporten udløber. Svaret kan du selv slå op på de officielle sider.

11. Der er et testmiljø og en fast vej til drift

Et testmiljø (staging) er en kopi af systemet hvor ændringer prøves af før de går live. Selve udrulningen bør ske automatisk med et værktøj, fx GitHub Actions eller Laravel Forge, så den foregår på samme måde hver gang og kan rulles tilbage.

Det syge tegn er filer der kopieres manuelt til den live server, eller ændringer der laves direkte i drift. Så er der ingen vej tilbage når noget går galt.

Sådan tjekker du det: Spørg hvordan en ændring kommer fra udviklerens computer til den live server, og hvordan I ruller tilbage hvis en udgivelse går galt. Et godt tegn er også at du selv kan prøve nye funktioner i testmiljøet før de går live.

12. Teknisk gæld bliver nævnt og betalt af

Teknisk gæld er de genveje der er taget for at levere hurtigere, og som skal betales tilbage senere med renter i form af langsommere ændringer. Alle systemer har noget. I en sund kodebase kan udvikleren nævne de to-tre største stykker gæld, og der bliver løbende brugt tid på at rydde op.

Det syge tegn er de to yderpunkter: enten er alt angiveligt fint, fordi ingen kigger, eller alt er så slemt at det skal skrives om fra bunden. Hvordan du taler om gælden som leder, gennemgår jeg i teknisk gæld forklaret for ledere.

Sådan tjekker du det: Spørg hvilke tre ting i koden din udvikler helst ville rydde op i, og hvad det koster at lade være.

Hvornår en rodet kodebase er helt i orden

De 12 tegn måler hvordan systemet opfører sig, ikke om koden er pæn. Kode som en udvikler kalder grim, kan sagtens virke fint og være billig at ændre. Og der er situationer hvor flere syge tegn er et fornuftigt valg:

• En prototype eller MVP der skal teste en idé. Her er fart vigtigere end orden. Men tegn 5, 6 og 10 gælder stadig, og virker idéen, skal oprydningen med i næste budget.
• Et system der sjældent ændres og kører stabilt. Så betyder tegn 1-3 mindre. Tegn 10 betyder stadig noget hvis systemet er på nettet og behandler persondata.
• Et system der skal udskiftes inden for et år. Brug ikke penge på oprydning. Sørg for sikkerhedsrettelser, backup og adgang til data, og læg pengene i det nye system.

Der er også tilfælde hvor du ikke har brug for en ekstern udvikler som mig. Har du et internt udviklingshold, så start med at stille dem spørgsmålene nedenfor. Det er billigere end en ekstern gennemgang, og et godt hold svarer gerne. Kører du på en standardløsning som Shopify uden egen kode, er det leverandørens opdateringer du skal holde øje med, ikke en kodebase.

Næste skridt: lav et sundhedstjek på en time

Book en time med din udvikler, stil spørgsmålene herunder og skriv svarene ned. Send dem gerne på forhånd, så der er tid til at finde tal og versioner frem.

Er svarene konkrete, har du sandsynligvis en sund kodebase. Er de vage, eller får du ikke svar, er det i sig selv et tegn, og så kan en uvildig gennemgang give dig et billede du kan træffe beslutninger på. På siden om vedligehold og videreudvikling af eksisterende systemer kan du se hvordan jeg overtager kode: direkte kontakt med mig, og koden bliver på din konto.

Ofte stillede spørgsmål

Kan man måle kodekvalitet med et værktøj?+

Ja, delvist. Værktøjer som SonarQube, PHPStan og ESLint kan finde kompleks kode, dobbelt kode og typiske fejl, og de giver dig tal. Tallene siger dog intet om hvorvidt systemet løser din forretnings behov, eller om én person sidder på al viden. Brug værktøjerne som supplement til de 12 tegn, ikke i stedet for dem, og bed udvikleren forklare hvad tallene betyder for dig.

Hvordan spørger jeg min udvikler uden at det virker som mistillid?+

Sig som det er: du vil forstå risikoen i det system din forretning hviler på. En god udvikler er vant til spørgsmålene og svarer gerne, fordi svarene også dokumenterer det arbejde der er gjort. Bliver udvikleren afvisende eller undvigende, er det værd at notere sig.

Skal en syg kodebase skrives om fra bunden?+

Sjældent. En omskrivning tager typisk længere tid end forventet, og imens skal det gamle system stadig holdes kørende. Oftest er det billigere at rydde op bid for bid: først sikkerhed, adgang og tests af de vigtigste arbejdsgange, derefter de dele der ændres oftest. En fuld omskrivning er mest fornuftig når teknologien er opgivet, eller forretningen har ændret sig så meget at systemet løser et andet problem.

Hvor lang tid tager en gennemgang af en kodebase?+

Det afhænger af systemets størrelse, men en første gennemgang af en typisk webapp kan ofte klares på en til få dages arbejde. Den giver overblik over versioner, tests, sikkerhed, adgang og de største risici. En dybere gennemgang med en plan for oprydning tager længere tid. Bed om en fast pris på den første gennemgang, så du ved hvad overblikket koster.

Gælder tegnene også for kode skrevet med AI?+

Ja. AI-værktøjer kan skrive meget kode hurtigt, men tegnene handler om hvordan koden bliver testet, udgivet, overvåget og overdraget, og det løser AI ikke af sig selv. Apps bygget hurtigt med værktøjer som Lovable eller Bolt kan sagtens mangle tests, fejlovervågning og en fast vej til drift. Gå derfor de samme 12 tegn igennem, uanset hvem eller hvad der har skrevet koden.