Snart skal nogen overlade dig en codebase — gennem et opkøb, en investering, en leverandørovergang eller en stilling. Du har begrænset tid, og de mennesker, der skrev den, har interesse i at se kompetente ud.
Dette er den rækkefølge jeg arbejder i, og den er bevidst ikke den rækkefølge ingenører naturligt starter med. Ingen burde stille spørgsmål om kodestil som deres første spørgsmål.
1. Kan du bygge det?
Klon repository'et på en ren maskine og følg README'en. Tidsregner.
Hvis en ny ingeniør ikke kan få et kørende build på under en time uden at spørge andre, er det dit vigtigste fund. Det betyder, at onboarding tager uger, viden bor i mennesker snarere end i repo'et, og alle estimater du får er optimistiske. Alt andet på denne liste betyder mindre end dette.
2. Kan du release det?
Bed om at overvåge en deploy. Ikke en beskrivelse af én — en rigtig deploy, live.
- Hvor lang tid fra merge til production?
- Hvor mange mennesker skal gøre noget?
- Hvad er rollback'en, og er den nogensinde blevet brugt?
- Hvem holder signing keys og store credentials? Dette har slået flere opkøb ihjel end dårlig kode.
Et team, der ikke kan release on demand, kan heller ikke reparere noget on demand. Det er ikke et kodekvalitetsproblem; det er et business-continuity-problem.
3. Hvor løber pengene ud?
Sæt infrastrukturregningen ved siden af brugertallet. Uregelmæssigheder her er de billigste seire du finder, og de fortæller dig hvor omhyggeligt tinget blev bygget.
4. Hvad sker der når det bryder?
Spørg efter de tre seneste incidents. Ikke en status page — den rigtige historie. Hvis der ikke er et svar, er enten intet moniteret eller intet dokumenteret, og begge fører til samme fund: du vil blive overrasket, og du ved ikke hvorfor.
Tjek for crash reporting og error tracking, og om nogen ser på nogle af dem. En app der kører med 96% crash-free rate uden at nogen er klar over det fortæller dig præcis hvordan teamet opererer.
En to-dages plan der virker
Hvis du rent faktisk har to dage, brug dem sådan i stedet for at læse kode fra time et:
- Morgen dag et — build og release. Klon, build, overvåg en deploy. To fund til frokost, og de er sædvanligvis de to som betyder mest.
- Eftermiddag dag et — snak med ingeniørerne. Individuelt, ikke som en gruppe. Spørg hvad de ville reparere med en fri måned. Konsistensen af svarene fortæller dig lige så meget som svarene selv.
- Morgen dag to — sample koden. Auth, betalinger, den største fil, test suite'et, dependency-listen. Tidsbegrænset til tre timer.
- Eftermiddag dag to — adgang og ejerskab. Konti, keys, licenser, kontrakter, data. Den kedelige halvdel, og halvdelen som blokerer deals.
Læg mærke til at kodesnalting er en fjerdedel af det. Det forhold overrasker ingeniører og berolig alle andre, og det er korrekt.
Spørgsmål som får ærlige svar
Hvordan du stiller spørgsmål bestemmer hvad du lærer. Disse virker:
- "Hvad ville du reparere hvis du havde en fri måned?" Folk elsker at svare på dette og det afslører den rigtige gæld på halvfems sekunder. "Intet" er selv et svar, og ikke et godt.
- "Hvad er delen du ville advare en ny ansættet om?" Hver codebase har én. At blive fortalt det uden at blive spurgt er et godt tegn på teamet.
- "Hvornår gik noget sidste gang galt i production, og hvad skete der?" Tester om de har incidents og om de lærer af dem.
- "Hvad ville gå i stykker hvis trafikken gik op 10x?" Et godt team svarer med det samme med en specifik komponent. Uklarhed betyder at ingen har tænkt over det.
Undgå "er koden god?" Du får et defensivt svar der fortæller dig intet, og du har brugt det velvilje du skulle bruge til de nyttige spørgsmål.
5. Kig nu på koden — men kun på disse
Du læser ikke en codebase på to dage, så prøv ikke. Sample bevidst:
- Authentication- og betalings-søjerne. Hvor security bugs og juridisk eksponering bor. Læs disse ordentligt.
- Den største fil i repo'et. Hver codebase har ét monster. Dens størrelse fortæller dig hvor længe teamet har været under pres uden at kunne betale gæld ned.
- Test suite'et — kører det, og stoler nogen på det? Coverage-procent er næsten meningsløs. "Kører i tests før udgivelse, og fanger de nogen gang noget?" er det rigtige spørgsmål.
- Dependency-alder. En dependency tre major versions bagud er et planlagt projekt som ingen har planlagt.
- Commit-historie. Hvem skrev faktisk dette? Hvis 80% af commits kommer fra en person som forlader, køber du ikke en codebase — du køber en rewrite.
6. Det juridiske lag som alle glemmer
- Licens-audit. En copyleft-licens inde i et kommercielt produkt er et rigtig problem, altid opdaget alt for sent.
- Ejer de koden? Kontrakter med entreprenører uden IP-tildeling er almindelig og dyre.
- Hvor er persondata, og hvem kan nå det? Under GDPR bliver dette dit problem det øjeblik du skriver under.
- Tredjepartskonti. Store-oplistinger, domæner, cloud-konti, analytics. Alt registreret til en personlig email er en gisselindtagelsessituation der venter på at ske.
Fund der burde ændre prisen
Det meste som en audit finder er normalt — hver rigtig codebase bærer gæld. Disse er de der virkelig betyder noget:
- Ingen nuværende ansatte kan deploye det.
- Signing keys, store-konti eller domæner er ikke kontrolleret af virksomheden.
- IP-kæden er brudt.
- En person der forlader skrev det meste af det.
- En dependency eller platform-krav tvinger en rewrite inden for tolv måneder.
Kun ét af disse handler om kode. Teknisk due diligence handler mest ikke om teknik — det handler om hvorvidt viden, adgang og ejerskab faktisk overgår med dealen.
Hvad godt ser ud til
Du ved det inden for en time. Gode teams giver dig et repository som bygger, et dokument som forklarer hvorfor tingene er som de er, og en ingeniør som frivilligt nævner de svage pletter før du finder dem. Det sidste er det stærkeste signal der er: mennesker som fortæller dig hvor ligene ligger er mennesker som har været ved at tænke på ligene.
Hvis du hellere ikke vil køre dette selv, er det præcist hvad et product audit er til — en fast time, en uden-for-mening, og ingen grund til at være høflig omkring svaret.