Hvad siger et uafhængigt code review om dit produkt?
Ved et uafhængigt code review vurderer en tredjepart din kodebase objektivt: arkitektur, kodekvalitet, sikkerhed og testdækning. Det er særligt værdifuldt ved et leverandørskifte, før et opkøb eller ved mistanke om kvalitetsproblemer. Resultatet skal være et konkret beslutningsgrundlag med prioriterede fund, ikke en liste med teknisk kritik, og tages op med den nuværende leverandør som en forbedring snarere end en anklage.
De fleste kunder kan ikke læse den kode de betaler for, og det er helt normalt. Men det betyder at kvalitetsproblemer kan ligge skjult længe indtil leverancerne bliver langsommere, fejlene hober sig op eller en mulig køber begynder at stille spørgsmål. Et uafhængigt code review er en måde at få et objektivt billede af hvad der faktisk er bygget, uden selv at skulle forstå hver linje. Her ser vi på hvornår det kan betale sig og hvordan du får et beslutningsgrundlag ud af det.
Hvornår et code review kan betale sig
Et code review koster tid og penge, så det skal have et konkret spørgsmål. Fire situationer retfærdiggør det næsten altid:
- Op til et leverandørskifte. Før du flytter et system, vil du vide hvad du arver: Hvor svært bliver det for et nyt team at tage over?
- Før et opkøb. Køber du en virksomhed, er koden et af dens største aktiver. Et review afslører om værdien er reel eller bare en facade.
- Ved mistanke om kvalitetsproblemer. Når alt tager længere tid end det burde og ingen kan forklare hvorfor, sætter et review ord på mavefornemmelsen.
- Op til en skalering. Skal systemet vokse kraftigt, vil du vide om arkitekturen kan bære eller om den revner ved ti gange så meget belastning.
Uden sådan en konkret anledning giver et rutinemæssigt review sjældent nok værdi til at retfærdiggøre omkostningen.
Hvad et code review faktisk omfatter
Et seriøst review nøjes ikke med at have meninger om kodestil. Det vurderer fire områder, som tilsammen giver et helhedsbillede.
| Område | Hvad der vurderes |
|---|---|
| Arkitektur | Kan strukturen bære fremtidige behov, eller er den en blindgyde? |
| Kodekvalitet | Er koden læsbar og til at vedligeholde, eller fuld af genveje? |
| Sikkerhed | Er der kendte svagheder i håndteringen af data, login og afhængigheder? |
| Testdækning | Fanger testene fejl før de når brugerne? |
Ud over dem ser en god reviewer på dokumentationen og på hvor let en ny udvikler kommer ind i koden, et mål der siger meget om hvor afhængig du er af netop det nuværende team. Bredden er pointen: Et review der kun kommenterer kodestilen, overser de dyre problemer, som ligger i arkitektur og sikkerhed.
Sådan bliver rapporten et beslutningsgrundlag
En teknisk rapport fuld af jargon er værdiløs for den der skal træffe beslutningen. Kræv derfor at rapporten er skrevet så man kan handle på den.
- Prioriterede fund. Hvert problem skal klassificeres efter alvor så du kan se hvad der skal udbedres nu og hvad der kan vente.
- Forretningsmæssig konsekvens, ikke kun teknik. Et fund skal oversættes til risiko og omkostning: Hvad kan der ske hvis det ikke bliver udbedret, og cirka hvad koster det at rette?
- Konkrete eksempler. Generelle vurderinger som “koden er rodet” er ikke gode nok. Fundene skal underbygges med faktiske eksempler, ellers kan de ikke imødegås.
- Et resumé til beslutningstagerne. En side øverst der svarer på det spørgsmål du stillede: Kan vi skalere, skal vi købe, er det tid til at skifte?
Med sådan en struktur bliver rapporten et grundlag du kan tage med til bestyrelsen, ikke et ringbind til teknikerne.
Et scenarie: code review op til et opkøb
En virksomhed skulle købe en mindre konkurrent, primært for dens software. På overfladen så produktet velbygget ud. Et uafhængigt review viste at arkitekturen var sund, men at testdækningen var næsten ikkeeksisterende og at en central del hvilede på en forældet komponent uden sikkerhedsopdateringer.
Fundene væltede ikke handlen, men de flyttede den. Køberen forhandlede prisen ned med omkostningen ved at udbedre manglerne og skrev ind at sælgeren skulle rette det værste før overtagelsen. Uden reviewet havde de betalt fuld pris for en skjult gæld.
At tage resultatet op uden konflikt
Den mest følsomme del er at præsentere fundene for den leverandør der skrev koden. Gør det som et fælles forbedringsarbejde, ikke som en anklage. En kompetent leverandør kender ofte allerede svaghederne og bliver lettet over en prioriteret liste at arbejde sig igennem. Gennemgå fundene sagligt, bed om leverandørens svar på hvert punkt og bliv enige om en handlingsplan.
Vil du have et objektivt billede af en kodebase op til en beslutning, kan vi hos Weapp gennemgå den eller gå bredere til værks med en teknisk due diligence op til et opkøb eller et leverandørskifte.
Ofte stillede spørgsmål
Hvornår er det værd at bestille et uafhængigt code review?
Først og fremmest op til en afgørende beslutning: et leverandørskifte, et virksomhedsopkøb, en større skalering, eller når leverancerne er blevet langsomme og fyldt med fejl uden forklaring. Så giver et objektivt billede af kodebasen et grundlag at træffe beslutninger på. At lave review rutinemæssigt uden et konkret spørgsmål giver sjældent en værdi der retfærdiggør omkostningen.
Hvad omfatter et code review?
Et seriøst review ser på fire områder: arkitekturen og om den kan bære fremtidige behov, kodekvaliteten og læsbarheden, sikkerheden i forhold til almindelige svagheder samt testdækningen. Det vurderer også dokumentationen og hvor let en ny udvikler kommer ind i koden. Bredden gør at du får et helhedsbillede og ikke kun en mening om kodestil.
Bliver reviewet ikke farvet af hvem der laver det?
Risikoen er der, og derfor bør revieweren være uafhængig af både din nuværende leverandør og af den der eventuelt vil overtage. En part der håber at vinde opgaven, har et incitament til at male billedet sort. Bed om en reviewer uden egeninteresse i udfaldet og om at fundene underbygges med konkrete eksempler og ikke med generelle vurderinger.
Hvordan tager vi resultatet op med den nuværende leverandør?
Bedst som et fælles grundlag for forbedringer, ikke som en retssag. En kompetent leverandør kender ofte allerede svaghederne og tager gerne imod en prioriteret liste at arbejde sig igennem. Præsentér fundene sagligt, bed om leverandørens svar på hvert enkelt og bliv enige om en handlingsplan. Målet er et bedre produkt, ikke at udpege en skyldig.