Noen er i ferd med å overgi deg en kodebase — gjennom et oppkjøp, en investering, en leverandørhåndovring eller en jobbfunksjon. Du har begrenset tid, og folka som skrev den er motivert til å virke dyktige.
Dette er rekkefølgen jeg arbeider i, og den er bevisst ikke rekkefølgen ingeniører naturlig ville startet med. Ingen første spørsmål burde handle om kodestil.
1. Kan du bygge det?
Klon repositoriet på en ren maskin og følg README-en. Mål tiden.
Hvis en ny ingeniør ikke kan få et fungerende bygg på under en time uten å spørre noen, er det ditt hovedfunn. Det betyr at onboarding tar uker, kunnskapen lever i mennesker i stedet for i repoen, og hver estimat du får er optimistisk. Alt annet på denne listen er mindre viktig enn dette.
2. Kan du release det?
Be om å se en deploy. Ikke en beskrivelse av en — en faktisk deploy, live.
- Hvor lang tid fra merge til produksjon?
- Hvor mange mennesker må gjøre noe?
- Hva er rollbacken, og har den noen gang blitt brukt?
- Hvem holder signing keys og store credentials? Denne har drept flere oppkjøp enn dårlig kode.
Et team som ikke kan release on demand kan heller ikke fikse noe on demand. Det er ikke et kodekvalitetsproblem; det er et forretningskontinuitetsproblem.
3. Hvor lekker pengene?
Sett infrastrukturkostnaden ved siden av brukertallet. Anomalier her er de billigste vinnerne du finner, og de forteller deg hvor nøye tingen ble bygget.
4. Hva skjer når det knekker?
Be om de siste tre hendelsene. Ikke en statusside — den faktiske historien. Hvis det ikke finnes noe svar, er det enten ingenting som blir overvåket eller ingenting som er skrevet ned, og begge fører til samme funn: du vil bli overrasket, og du vil ikke vite hvorfor.
Sjekk for crash reporting og error tracking, og om noen ser på begge deler. En app som kjører med 96% crash-free rate mens ingen er klar over det forteller deg nøyaktig hvordan teamet opererer.
En to-dagers plan som fungerer
Hvis du virkelig har to dager, bruk dem slik i stedet for å lese kode fra time en:
- Morgen dag en — bygg og release. Klon, bygg, se en deploy. To funn før lunsj, og de er vanligvis de to som betyr noe.
- Ettermiddag dag en — snakk med ingeniørene. Individuelt, ikke som en gruppe. Spør hva de ville fikse hvis de fikk en gratis måned. Konsistensen i svarene forteller deg like mye som svarene selv.
- Morgen dag to — utvalg av koden. Auth, betalinger, den største filen, test suiten, avhengighetslisten. Tidsbegrenset til tre timer.
- Ettermiddag dag to — tilgang og eierskap. Kontoer, nøkler, lisenser, kontrakter, data. Den kjedelige halvdelen, og halvdelen som blokkerer avtaler.
Legg merke til at kodeutvalg er en fjerdedel av det. Det forholdet overrasker ingeniører og beroer alle andre, og det er riktig.
Spørsmål som får ærlige svar
Hvordan du spør bestemmer hva du lærer. Disse fungerer:
- "Hva ville du fikse hvis du hadde en gratis måned?" Folk elsker å svare på dette og det viser den virkelige gjelden på nitti sekunder. "Ingenting" er i seg selv et svar, og ikke et bra.
- "Hva er delen du ville advart en ny ansatt om?" Hver kodebase har en. Å bli fortalt om den uten oppfordring er et godt tegn om teamet.
- "Når gikk noe sist galt i produksjon, og hva skjedde?" Tester om de har hendelser og om de lærer fra dem.
- "Hva ville knekke hvis trafikken gikk opp 10×?" Et bra team svarer øyeblikkelig med en spesifikk komponent. Vagueness betyr at ingen har tenkt på det.
Unngå "er koden god?" Du får et defensivt svar som ikke forteller deg noe, og du vil ha brukt goodwillen du trengte for de nyttige spørsmålene.
5. Nå se på koden — men bare på disse
Du kommer ikke til å lese en kodebase på to dager, så prøv ikke. Utvalg bevisst:
- Auth og betalingsstiene. Hvor sikkerhetsbugs og juridisk eksponering lever. Les disse ordentlig.
- Den største filen i repoen. Hver kodebase har ett monster. Størrelsen forteller deg hvor lenge teamet har vært under press uten å få lov til å betale gjeld ned.
- Test suiten — kjører den, og stoler noen på den? Dekningsprosent er nesten meningsløs. "Kjører dere tester før release, og fanger de noen gang noe?" er det virkelige spørsmålet.
- Avhengighetsalder. En avhengighet tre major versjoner bak er et planlagt prosjekt som ingen har planlagt.
- Commit historikk. Hvem skrev dette egentlig? Hvis 80% av commits kommer fra en person som forlater, kjøper du ikke en kodebase — du kjøper en omskrivning.
6. Juridisk laget alle glemmer
- Lisensrevisjon. En copyleft lisens inne i et kommersielt produkt er et reelt problem, alltid oppdaget altfor sent.
- Eier de koden? Kontraktøravtaler uten IP-overdragelse er vanlige og dyre.
- Hvor er persondata, og hvem kan nå det? Under GDPR blir dette ditt problem det øyeblikket du signerer.
- Tredjepartskontoer. Store oppføringer, domener, sky-kontoer, analytics. Hva som helst registrert til en personlig e-post er en gisselsituasjon som venter på å skje.
Funn som bør endre prisen
Det meste av det som en revisjon finner er normalt — hver ekte kodebase har gjeld. Dette er de som er virkelig vesentlige:
- Ingen som er ansatt kan deploy den.
- Signing keys, store kontoer eller domener kontrolleres ikke av selskapet.
- IP-kjeden er brutt.
- En person som forlater skrev mesteparten av den.
- En avhengighet eller platformkrav tvinger en omskrivning innen tolv måneder.
Bare en av disse handler om kode. Teknisk due diligence er for det meste ikke teknisk — det handler om hvorvidt kunnskapen, tilgangen og eierskapet faktisk overføres med avtalen.
Hva bra ser ut som
Du vil vite det innen en time. Gode team gir deg et repository som bygges, et dokument som forklarer hvorfor ting er som de er, og en ingeniør som frivillig forteller de svake stedene før du finner dem. Den siste er det sterkeste signalet det finnes: folk som forteller deg hvor likene er begravet er folk som har tenkt på likene.
Hvis du heller ikke vil kjøre dette selv, er det nøyaktig hva en produktrevisjon er for — en fast time, en utenforstående mening, og ingen insentiv til å være høflig om svaret.