Hva sier en uavhengig kodegjennomgang om produktet ditt?
En uavhengig kodegjennomgang er når en tredjepart vurderer kodebasen din objektivt: arkitektur, kodekvalitet, sikkerhet og testdekning. Den er særlig verdifull ved leverandørbytte, før et oppkjøp eller ved mistanke om kvalitetsproblemer. Resultatet skal være et konkret beslutningsgrunnlag med prioriterte funn, ikke en liste med teknisk kritikk, og tas opp med dagens leverandør som forbedring snarere enn anklage.
De fleste kunder kan ikke lese koden de betaler for, og det er helt normalt. Men det gjør at kvalitetsproblemer kan ligge skjult helt til leveransene går tregere, feilene hoper seg opp eller en mulig kjøper begynner å stille spørsmål. En uavhengig kodegjennomgang er en måte å få et objektivt bilde av hva som faktisk er bygd, uten at du selv må forstå hver linje. Her ser vi på når den lønner seg, og hvordan du får et beslutningsgrunnlag ut av den.
Når en gjennomgang lønner seg
En kodegjennomgang koster tid og penger, så den bør ha en problemstilling. Fire situasjoner gjør den nesten alltid verdt pengene:
- Før et leverandørbytte. Før du flytter et system, vil du vite hva du arver: Hvor vanskelig blir det for et nytt team å ta over?
- Før et oppkjøp. Kjøper du et selskap, er koden en av selskapets største verdier. En gjennomgang avslører om verdien er reell eller bare en fasade.
- Ved mistanke om kvalitetsproblemer. Når alt tar lengre tid enn det burde og ingen kan forklare hvorfor, setter en gjennomgang ord på magefølelsen.
- Før oppskalering. Skal systemet vokse kraftig, vil du vite om arkitekturen holder, eller om den sprekker ved tidoblet last.
Uten en slik konkret grunn gir en rutinemessig gjennomgang sjelden nok verdi til å forsvare kostnaden.
Hva gjennomgangen faktisk omfatter
En seriøs gjennomgang nøyer seg ikke med å mene noe om kodestil. Den vurderer fire områder som til sammen gir et helhetsbilde.
| Område | Hva som vurderes |
|---|---|
| Arkitektur | Tåler strukturen fremtidige behov, eller er den en blindvei? |
| Kodekvalitet | Er koden lesbar og vedlikeholdbar, eller full av snarveier? |
| Sikkerhet | Finnes det kjente svakheter i håndtering av data, innlogging og avhengigheter? |
| Testdekning | Fanger testene feil før de når brukerne? |
I tillegg ser en god gjennomgang på dokumentasjonen og på hvor lett en ny utvikler kommer inn i koden, et mål som sier mye om hvor avhengig du er av akkurat det nåværende teamet. Bredden er poenget: En gjennomgang som bare kommenterer kodestil, går glipp av de dyre problemene, som ligger i arkitektur og sikkerhet.
Slik blir rapporten et beslutningsgrunnlag
En teknisk rapport full av sjargong er verdiløs for den som skal ta beslutningen. Krev derfor at rapporten er skrevet slik at du kan handle ut fra den.
- Prioriterte funn. Hvert problem skal klassifiseres etter alvorlighetsgrad slik at du ser hva som må utbedres nå, og hva som kan vente.
- Forretningskonsekvens, ikke bare teknikk. Et funn skal oversettes til risiko og kostnad: Hva kan skje hvis det ikke utbedres, og omtrent hva koster det å rette det?
- Konkrete eksempler. Svepende vurderinger som «koden er rotete» holder ikke. Funnene skal underbygges med faktiske eksempler, ellers kan de ikke imøtegås.
- Et sammendrag for beslutningstakere. Én side øverst som svarer på spørsmålet du stilte: Kan vi skalere, skal vi kjøpe, er det på tide å bytte?
Med en slik struktur blir rapporten et grunnlag du kan ta med til styret, ikke en perm for teknikerne.
Et scenario: gjennomgang før et oppkjøp
Et selskap skulle kjøpe en mindre konkurrent, mest for programvarens skyld. På overflaten så produktet godt bygd ut. En uavhengig gjennomgang viste at arkitekturen var sunn, men at testdekningen nesten ikke fantes, og at en sentral del hvilte på en utdatert komponent uten sikkerhetsoppdateringer.
Funnene veltet ikke handelen, men de endret den. Kjøperen forhandlet ned prisen med kostnaden for å utbedre manglene og fikk inn i avtalen at selgeren skulle rette det verste før overtakelse. Uten gjennomgangen hadde de betalt full pris for en skjult gjeld.
Å ta opp resultatet uten konflikt
Den mest følsomme delen er å presentere funnene for leverandøren som skrev koden. Gjør det som et felles forbedringsarbeid, ikke som en anklage. En kompetent leverandør kjenner ofte allerede til svakhetene og blir lettet over å få en prioritert liste de kan jobbe seg gjennom. Gå gjennom funnene saklig, be om leverandørens svar på hvert punkt og bli enige om en tiltaksplan.
Vil du ha et objektivt bilde av en kodebase før en beslutning, kan vi i Weapp gå gjennom den, eller ta det bredere grepet i en teknisk due diligence før et oppkjøp eller leverandørbytte.
Ofte stilte spørsmål
Når er det verdt å bestille en uavhengig gjennomgang?
Først og fremst før en avgjørende beslutning: et leverandørbytte, et oppkjøp, en større oppskalering eller når leveransene har blitt trege og fulle av feil uten forklaring. Da gir et objektivt bilde av kodebasen et grunnlag å ta beslutninger på. Å gå gjennom koden rutinemessig uten en konkret problemstilling gir sjelden nok verdi til å forsvare kostnaden.
Hva omfatter en kodegjennomgang?
En seriøs gjennomgang ser på fire områder: arkitekturen og om den tåler fremtidige behov, kodekvaliteten og lesbarheten, sikkerheten rundt vanlige svakheter, og testdekningen. Den vurderer også dokumentasjonen og hvor lett en ny utvikler kommer inn i koden. Bredden gjør at du får et helhetsbilde, ikke bare en mening om kodestil.
Blir ikke gjennomgangen partisk avhengig av hvem som gjør den?
Risikoen finnes, og derfor bør den som går gjennom koden, være uavhengig av både dagens leverandør og den som eventuelt vil ta over. En part som håper å vinne oppdraget, har insentiv til å svartmale. Be om en fagperson uten egeninteresse i utfallet, og krev at funnene underbygges med konkrete eksempler, ikke svepende vurderinger.
Hvordan tar vi opp resultatet med dagens leverandør?
Best som et felles forbedringsgrunnlag, ikke som en rettssak. En kompetent leverandør kjenner ofte allerede til svakhetene og tar gjerne imot en prioritert liste de kan jobbe seg gjennom. Presenter funnene saklig, be om leverandørens svar på hvert enkelt, og bli enige om en tiltaksplan. Målet er et bedre produkt, ikke å finne en syndebukk.