Kodgranskning

Inför ett leverantörsbyte eller en större satsning är frågan inte om koden är snygg. Frågan är vad som händer om nyckelpersonen slutar, hur lång tid en ändring tar att få ut i produktion, och vilka beroenden som kräver en stor uppgradering den dag en säkerhetsfix bara finns för nya versioner.

Vad du får

En skriftlig sammanfattning som går att läsa utan att vara utvecklare, med riskerna rangordnade efter vad de kan kosta och hur troliga de är. Det är en genomlysning, inte en fullständig revision: vi pekar ut det som luktar illa och var det är värt att gräva djupare. Vi skiljer på det som bör åtgärdas först, det som kan planeras in senare, och det som ser illa ut men sällan ändras och därför kan vänta. Vi skriver också vad vi inte kunde bedöma, och varför.

Vad vi tittar på

• Beroenden. Vilka ligger flera huvudversioner efter, och vad krävs för att komma ikapp? Kostnaden syns inte i vardagen, men den dag en säkerhetsfix bara finns för en nyare version blir uppgraderingen brådskande.
• Ledtid och driftsättning. Hur lång tid tar det från commit till produktion, och hur ofta släpps det?
• Testtäckning på de viktigaste flödena. Den säger hur mycket av en ändring som går att kontrollera automatiskt, och hur mycket som måste klickas igenom för hand.
• Ändringsfrekvens ur versionshistoriken. Vilka filer ändras mest? Det säger var arbetet sker, och tillsammans med intervjuerna varför.
• Kunskapsspridning. Vilka delar förstås bara av en person?

Hur lång tid tar en granskning?

Det beror på systemets storlek, hur många system som ingår och hur många personer vi behöver prata med. Vi ger en uppskattning när vi sett kodbasen och vet vilka som går att intervjua. Intervjuerna hoppar vi inte över: versionshistoriken säger vad som ändrats, men inte varför något är byggt som det är. Metoden för att räkna om fynden till kronor står i vad kostar teknisk skuld?.