Hvordan evaluere og modernisere en eksisterende kodebase
En stegvis tilnærming med fokus på respekt, observasjon og mikro-evolusjon
Når man går inn i en etablert kodebase, møter man ikke bare teknologi. Man møter historie, kompromisser, tidligere teamdynamikker, tidsfrister, preferanser – og det som ofte er en stille kamp mellom ambisjon og leveranse. Det kan være fristende å starte moderniseringen umiddelbart: rydde, stramme inn, oppdatere alt som føles gammelt.
Men som jeg skrev i Det tause ansvaret: Å holde standardene samlet som tech lead må den som kommer inn i et nytt (eller gammelt) system først lytte. Ikke diktere. Ikke ommøblere. Ikke «fikse».
Modernisering begynner ikke med endring — den begynner med forståelse.
1. Start med observasjon, ikke forbedring
Når du entrer et eksisterende system:
- ikke refaktorer umiddelbart
- ikke introduser nye mønstre
- ikke flytt mapper bare fordi du kan
Begynn som en vanlig utvikler: plukk bugs, les pull requests, se hvordan teamet beveger seg.
Som beskrevet i Teknisk gjeld som et teamfenomen vokser teknisk gjeld ut av praksisene som allerede finnes i teamet. Du må forstå dem før du evaluerer dem.
2. Kartlegg før du konkluderer
Når du har fått den første følelsen av systemet, lager du en strukturert oversikt.
Teknisk kartlegging
- språk, rammeverk og runtime-versjoner
- build/deploy-pipelines
- testdekning og testtyper
- logging, observability, feilhåndtering
- sikkerhetspraksis (se eget punkt)
Strukturell kartlegging
- monolitt vs. microservices
- modulgrenser og avhengigheter
- API-design og eksterne kontrakter
- dataflyt, validering og domenemodellering
Sosial kartlegging
- hvem eier hva?
- hvilke uvaner har etablert seg?
- hvor oppstår friksjon?
- hvilke deler er «ingen tør å røre»?
Modernisering uten denne innsikten er ikke modernisering – det er støy.
3. Multi-repo og multi-språk: Slik får du overblikk
Store organisasjoner sitter sjelden på én kodebase – ofte mange, i flere språk, med ulik historikk.
Her gjelder et prinsipp som utforskes i Hvordan etablere tekniske standarder som faktisk etterleves:
Én felles kilde til sannhet – og lokale tilpasninger.
Praktiske grep
- lag en sentral “engineering standards”-repo for tverrgående praksiser
- dokumentér lokale avvik i TDR-er (Technical Decision Records)
- unngå kopiering – lenk til standardene
- skill mellom språk-spesifikke standarder og felles praksiser
Dette sikrer forutsigbarhet uten å fjerne fleksibilitet.
4. Sikkerhet først – alltid
I eldre kodebaser er sikkerhetsgjeld ofte det mest kritiske – og det minst synlige.
Her finnes ingen fleksibilitet, slik også beskrevet i Teknisk gjeld som et teamfenomen.
Typiske funn:
- secrets i kode
- manglende inputvalidering
- utdaterte biblioteker med kjente CVE-er
- usikre autentiseringsmønstre
- manglende logging av kritiske hendelser
Start her
- dependency scanning (Dependabot, Snyk)
- secret scanning og Key Vault-integrasjon
- felles sikkerhetsstandarder i den sentrale repoen
- PR-sjekker som stopper kritiske avvik
- inputvalidering som default-mønster
Sikkerhet er ikke “teknisk gjeld”.
Sikkerhet er risiko.
5. Mikro-evolusjon: Små steg, ingen revolusjoner
Når du forstår systemet, kan du begynne å forbedre det – men i små, trygge steg.
Dette innebærer å:
- forbedre én modul av gangen
- rydde litt hver gang du først er i koden
- introdusere nye mønstre i takt med teamet
- vise effekt i demoer, ikke bare i diff-visninger
Som i Standarder i praksis: Når bør man være rigid – og når bør man være fleksibel?: standarder fungerer bare når de er forankret i teamets rytme.
6. Hvordan motivere teamet til å ta tak i teknisk gjeld
Det hjelper ikke at du vil modernisere – teamet må ville det også.
Tre ting fungerer:
1. Gjør gjeld synlig
Teknisk gjeld er ofte usynlig for prioriteringsmøter.
Gjør den synlig i demoer, dashboards og beslutningsgrunnlag.
2. Knytt gjeld til opplevd smerte
Ikke si «Dette er dårlig design».
Si:
- «Dette gjør onboarding tregere.»
- «Dette gir oss feil som er vanskelige å debugge.»
- «Dette øker risiko i produksjon.»
Smerten er motivasjonen. Løsningen er modernisering.
3. Ta det inn i hverdagen
Et stort “refactor-epic” ingen har tid til, virker ikke.
Integrer forbedringer i alt teamet gjør – litt etter litt – slik anbefalt i boy scout-tankegangen bak gode standarder.
7. En stegvis oppskrift for trygg modernisering
Steg 1 – Observer
Lær systemet og teamet, uten å endre noe.
Steg 2 – Kartlegg
Teknisk, strukturelt og sosialt.
Steg 3 – Prioriter sikkerhet
Alt annet kan vente. Dette kan ikke.
Steg 4 – Etabler felles standarder og TDR-er
På tvers av repoer og språk.
Steg 5 – Moderne-by-default i ny kode
Ikke start med å omskrive alt gammelt.
Steg 6 – Mikroskopisk rydding
Forbedre hver gang du toucher koden.
Steg 7 – Involver teamet
Motivasjon kommer av eierskap, ikke instruksjon.
Steg 8 – Evaluer jevnlig
Standarder og modernisering må leve, ikke fryses.
Avslutning: Modernisering er relasjonelt arbeid
Å oppgradere en kodebase er ikke bare et teknisk prosjekt — det er et kulturelt prosjekt.
Det krever observasjon, respekt, psykologisk trygghet og en porsjon tålmodighet.
Gode tekniske valg fungerer bare når teamet er med.
Modernisering skjer ikke i store løft, men i små evolusjoner.
Og den starter alltid med det samme spørsmålet:
Hva skjer her – og hvorfor?
Når du først har svaret, kommer resten naturlig.
