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.