Checkliste für die technische Due-Diligence einer Codebasis

Jemand wird Sie gleich mit einer Codebasis konfrontieren — durch eine Akquisition, eine Investition, eine Supplier-Übergabe oder einen neuen Job. Sie haben wenig Zeit, und die Leute, die den Code geschrieben haben, wollen kompetent wirken.

Das ist die Reihenfolge, in der ich vorgehe, und sie ist bewusst nicht die Reihenfolge, mit der Engineers normalerweise anfangen. Niemand sollte als erstes nach Code-Style fragen.

1. Können Sie den Build machen?

Clonen Sie das Repository auf einer sauberen Maschine und folgen Sie dem README. Stoppen Sie die Zeit.

Wenn ein neuer Engineer ohne Nachfragen nicht in unter einer Stunde zu einem funktionierenden Build kommt, ist das Ihre wichtigste Erkenntnis. Das bedeutet: Onboarding dauert Wochen, Wissen lebt in Menschen statt im Repo, und jede Schätzung, die Sie bekommen, ist optimistisch. Alles andere auf dieser Liste ist weniger wichtig.

2. Können Sie es deployen?

Fragen Sie, ob Sie einen Deploy beobachten dürfen. Nicht eine Beschreibung — einen echten Deploy, live.

• Wie lange dauert es von Merge bis Production?
• Wie viele Menschen müssen etwas tun?
• Wie geht ein Rollback, und wurde er schon verwendet?
• Wer hat die Signing Keys und die Store Credentials? Das hat schon mehr Akquisitionen zerstört als schlechter Code.

Ein Team, das nicht on Demand deployen kann, kann auch nicht on Demand etwas fixen. Das ist kein Code-Quality-Problem; das ist ein Business-Continuity-Problem.

3. Wo läuft das Geld weg?

Legen Sie die Infrastruktur-Rechnung neben die Benutzer-Zahlen. Anomalien hier sind die billigsten Wins, die Sie finden werden, und sie zeigen, wie sorgfältig das System gebaut wurde.

4. Was passiert, wenn es kaputt geht?

Fragen Sie nach den letzten drei Incidents. Nicht die Status Page — die echte Geschichte. Wenn es keine Antwort gibt, wird entweder nichts monitored oder nichts dokumentiert, und beides führt zur gleichen Erkenntnis: Sie werden überrascht, und Sie wissen nicht warum.

Prüfen Sie auf Crash Reporting und Error Tracking, und ob jemand das überhaupt liest. Eine App mit 96% crash-free Rate, bei der niemand das mitbekommt, sagt alles über das Team.

Ein Zwei-Tage-Plan, der funktioniert

Wenn Sie wirklich zwei Tage haben, nutzen Sie sie so, nicht ab Stunde eins mit Code lesen:

1. Morgen eins — Build und Deploy. Clonen, Builden, Deploy beobachten. Zwei Erkenntnisse bis Mittag, und sie sind normalerweise die, die zählen.
2. Nachmittag eins — mit den Engineers reden. Einzeln, nicht als Gruppe. Fragen Sie, was sie in einem freien Monat fixen würden. Wie konsistent die Antworten sind, sagt genauso viel wie die Antworten selbst.
3. Morgen zwei — Code sampeln. Auth, Payments, die größte Datei, die Test Suite, die Dependency Liste. Limitiert auf drei Stunden.
4. Nachmittag zwei — Access und Ownership. Accounts, Keys, Lizenzen, Verträge, Daten. Der langweilige Teil, und der Part, der Deals blockiert.

Beachten Sie: Code Sampling ist nur ein Viertel davon. Das Verhältnis überrascht Engineers und beruhigt alle anderen, und es ist richtig.

Fragen, die ehrliche Antworten geben

Wie Sie fragen, bestimmt was Sie lernen. Diese funktionieren:

• "Was würden Sie fixen, wenn Sie einen freien Monat hätten?" Leute beantworten das gerne, und es bringt die echte technische Schulden in 90 Sekunden ans Licht. "Nichts" ist selbst eine Antwort, und keine gute.
• "Was ist die Stelle, die Sie einer neuen Hire warnen würden?" Jede Codebasis hat eine. Dass Ihnen jemand unprompted von ihr erzählt, ist ein gutes Zeichen für das Team.
• "Wann ist zuletzt etwas in Production schiefgelaufen, und was ist passiert?" Prüft, ob sie Incidents haben und ob sie davon lernen.
• "Was würde brechen, wenn der Traffic 10× ansteigt?" Ein gutes Team antwortet sofort mit einer spezifischen Komponente. Vagueness bedeutet: niemand hat drüber nachgedacht.

Vermeiden Sie "Ist der Code gut?" Sie bekommen eine defensive Antwort, die nichts sagt, und Sie haben den Goodwill verpulvert, den Sie für die wichtigen Fragen brauchten.

5. Jetzt den Code anschauen — aber nur diese

Sie werden in zwei Tagen keine Codebasis komplett lesen, also versuchen Sie das gar nicht. Sampeln Sie gezielt:

• Die Authentication und Payment Paths. Wo Security Bugs und Legal Exposure leben. Lesen Sie diese richtig.
• Die größte Datei im Repo. Jede Codebasis hat ein Monster. Ihre Größe zeigt, wie lange das Team unter Druck war, ohne Schulden bezahlen zu dürfen.
• Die Test Suite — läuft sie, und traut jemand ihr? Coverage-Prozentuale sind fast bedeutungslos. Die echte Frage ist: "Laufen Sie Tests vor dem Release, und fangen sie jemals etwas?"
• Dependency-Alter. Eine Dependency drei Major Versions hinter ist ein geplantes Projekt, das niemand geplant hat.
• Commit History. Wer hat das wirklich geschrieben? Wenn 80% der Commits von einer Person kommen, die geht, kaufen Sie nicht eine Codebasis — Sie kaufen einen Rewrite.

6. Die Legal-Schicht, die alle vergessen

• Licence Audit. Eine Copyleft-Lizenz in einem Commercial Product ist ein echtes Problem, immer viel zu spät entdeckt.
• Gehört denen der Code? Contractor Agreements ohne IP Assignment sind häufig und teuer.
• Wo sind Personendaten, und wer kann darauf zugreifen? Unter DSGVO wird das ab Unterschrift Ihr Problem.
• Third-Party Accounts. Store Listings, Domains, Cloud Accounts, Analytics. Alles, das auf eine persönliche Email registriert ist, ist eine Hostage Situation, die wartet.

Erkenntnisse, die den Preis ändern sollten

Was ein Audit meistens findet, ist normal — jede echte Codebasis hat Schulden. Das sind die, die wirklich Material sind:

• Niemand, der aktuell da ist, kann es deployen.
• Signing Keys, Store Accounts oder Domains sind nicht vom Unternehmen kontrolliert.
• Die IP-Kette ist unterbrochen.
• Eine Person, die geht, hat die Mehrheit geschrieben.
• Eine Dependency oder Plattform-Anforderung zwingt einen Rewrite in weniger als 12 Monaten.

Nur einer davon ist über Code. Technische Due Diligence ist meistens nicht technisch — es geht darum, ob Wissen, Access und Ownership tatsächlich mit dem Deal übergehen.

Wie es aussieht, wenn es gut läuft

Sie wissen es in einer Stunde. Gute Teams geben Ihnen ein Repository, das buildet, ein Dokument, das erklärt, warum die Dinge so sind, und einen Engineer, der die schwachen Stellen freiwillig nennt, bevor Sie sie finden. Das letzte ist das stärkste Signal: Leute, die Ihnen sagen, wo die Leichen begraben sind, sind Leute, die über die Leichen nachgedacht haben.

Wenn Sie das nicht selbst machen wollen, ist das genau, wofür ein Product Audit ist — eine feste Stundenzahl, eine externe Meinung, und kein Grund, höflich zu sein.