Någon håller på att ge dig en kodbas — genom en övertagelse, en investering, ett leverantörsöverförande, eller en jobbtitel. Du har begränsad tid, och de som skrev den är motiverade att verka kompetenta.
Det här är ordningen jag arbetar i, och det är medvetet inte den ordning ingenjörer naturligt börjar med. Ingen skulle först fråga om kodstil.
1. Kan du bygga den?
Klona repositoriet på en ren maskin och följ README. Tid det.
Om en ny ingenjör inte kan få en körbar version på under en timme utan att fråga någon, det är ditt huvudsakliga fynd. Det betyder att onboarding tar veckor, kunskap bor i människor snarare än i repositoriet, och varje uppskattning du får är optimistisk. Allt annat på den här listan är mindre viktigt än det här.
2. Kan du släppa den?
Be att få se en deploy. Inte en beskrivning av en — en faktisk deploy, live.
- Hur långt från merge till produktion?
- Hur många människor måste göra något?
- Vad är rollback, och har det använts någonsin?
- Vem har signeringsnycklar och store-uppgifter? Det här har dödat fler förvärv än dålig kod.
Ett team som inte kan släppa när som helst kan inte heller fixa något när som helst. Det är inte ett kodkvalitetsproblem; det är ett affärskontinuitetsproblem.
3. Var läcker pengarna?
Sätt infrastrukturräkningen bredvid användarantalet. Avvikelser här är de billigaste vinsterna du hittar, och de säger dig hur noggrant allt byggdes.
4. Vad händer när det går sönder?
Be om de senaste tre incidenterna. Inte en statussida — den faktiska historien. Om det inte finns något svar, antingen övervakas ingenting eller ingenting är nedskrivet, och båda leder till samma fynd: du kommer att bli överraskad, och du vet inte varför.
Kontrollera crash-rapportering och felspårning, och om någon tittar på något av dem. En app som körs med 96% crash-free rate med ingen medveten om det säger dig exakt hur teamet arbetar.
Ett tvådagars schema som fungerar
Om du verkligen har två dagar, tillbringa dem så här snarare än att läsa kod från timme ett:
- Första morgonen — bygga och släppa. Klona, bygga, se en deploy. Två fynd före lunch, och de är vanligtvis de två som spelar roll.
- Första eftermiddagen — prata med ingenjörerna. Individuellt, inte som en grupp. Fråga vad de skulle fixa om de fick en gratis månad. Konsistensen av svaren säger dig lika mycket som själva svaren.
- Andra morgonen — prova koden. Auth, betalningar, den största filen, testsviten, beroendelistan. Begränsad till tre timmar.
- Andra eftermiddagen — åtkomst och ägandeskap. Konton, nycklar, licenser, kontrakt, data. Den tråkiga hälften, och hälften som blockerar affärer.
Lägg märke till att kodprovtagning är en fjärdedel av det. Det förhållandet överraskar ingenjörer och försäkrar alla andra, och det är korrekt.
Frågor som ger ärliga svar
Hur du frågar avgör vad du lär dig. Dessa fungerar:
- "Vad skulle du fixa om du hade en gratis månad?" Folk älskar att svara på detta och det avslöjar den verkliga skulden på nittio sekunder. "Ingenting" är själv ett svar, och inte ett bra.
- "Vilken del skulle du varna en ny anställd om?" Varje kodbas har en. Att bli berättad om det utan att be om det är ett bra tecken på teamet.
- "När gick något senast fel i produktion, och vad hände?" Testar om de har incidenter och om de lär sig av dem.
- "Vad skulle gå sönder om trafiken ökat 10×?" Ett bra team svarar omedelbar med en specifik komponent. Vagueness betyder att ingen har tänkt på det.
Undvik "är koden bra?" Du kommer att få ett defensivt svar som inte säger dig något, och du kommer att ha slösat den goodwill du behövde för de användbara frågorna.
5. Titta nu på koden — men bara på dessa
Du kommer inte att läsa en kodbas på två dagar, så försök inte. Prova medvetet:
- Autentiserings- och betalningsvägar. Där säkerhetsbuggar och juridisk exponering bor. Läs dessa ordentligt.
- Den största filen i repositoriet. Varje kodbas har en monster. Dess storlek säger dig hur länge teamet har varit under tryck utan att få betala ned skulden.
- Testsviten — körs den, och litar någon på den? Täckningsprocent är nästan meningslös. "Kör du tester innan du släpper, och fångar de någonsin något?" är den verkliga frågan.
- Beroendens ålder. Ett beroende tre större versioner bakom är ett planerat projekt som ingen har planerat.
- Commit-historik. Vem skrev det här faktiskt? Om 80% av commits kommer från en person som lämnar, köper du inte en kodbas — du köper en omskrivning.
6. Det juridiska lagret alla glömmer
- Licensgranskning. En copyleft-licens inuti en kommersiell produkt är ett verkligt problem, alltid uppdagad långt för sent.
- Äger de koden? Entreprenöravtal utan IP-överlåtelse är vanliga och dyra.
- Var finns personlig data, och vem kan nå den? Under GDPR blir det här ditt problem i det ögonblick du undertecknar.
- Tredjepartskonton. Store-annonser, domäner, molnkonton, analys. Allt som är registrerat på en personlig e-post är en gisslantsituation som väntar på att hända.
Fynd som bör påverka priset
Det mesta som en granskning visar upp är normalt — varje verklig kodbas bär skuld. Dessa är de som faktiskt är väsentliga:
- Ingen för närvarande anställd kan distribuera den.
- Signeringsnycklar, store-konton eller domäner kontrolleras inte av företaget.
- IP-kedjan är bruten.
- En person som lämnar skrev större delen av den.
- Ett beroende eller plattformskrav tvingar en omskrivning inom tolv månader.
Bara en av dessa handlar om kod. Teknisk granskning är mest inte teknisk — det handlar om huruvida kunskapen, åtkomsten och äganderätten faktiskt överförs med affären.
Hur det ser ut när det är bra
Du vet inom en timme. Bra team ger dig ett repositorio som bygger, ett dokument som förklarar varför saker är som de är, och en ingenjör som frivilligt avslöjar svaga punkter innan du hittar dem. Det sista är den starkaste signalen: människor som säger dig var likena är begravda är människor som har tänkt på likena.
Om du hellre inte kör det själv, det är exakt vad en produktgranskning är till för — en fast timma, en utifrån kommande åsikt, och inget incitament att vara artig om svaret.