Codebasis für ein Code-Audit vorbereiten: Was du vor dem Start aufräumen solltest

Irgendwo zwischen der Vertragsunterzeichnung und dem ersten Tag des Auditors machen die meisten Teams genau das Falsche: Sie versuchen hektisch, die Codebasis vorzeigbar zu machen. Dieser Beitrag behandelt die Code-Audit-Vorbereitung so, wie wir sie uns von jedem Kunden wünschen würden. Die zwei Wochen vor einem Audit entscheiden darüber, wie nützlich der Abschlussbericht wird, und fast nichts von dieser Zeit sollte in das Polieren von Code fließen. Sie sollte in Zugänge, Dokumentation und ehrlichen Kontext fließen. Ein vorbereiteter Kunde bekommt Findings, die gegen seine realen Risiken gewichtet sind. Ein unvorbereiteter bezahlt den Auditor dafür, Dinge per Reverse Engineering herauszufinden, die das Team an einem Nachmittag hätte aufschreiben können.

Wir haben bereits beschrieben, was ein vollständiges Application-Audit untersucht und woran du erkennst, dass deine Codebasis eines braucht. Dies ist der praktische Begleittext dazu. Du hast dich für ein Audit entschieden, der Starttermin steht im Kalender, und du willst so viel wie möglich für dein Geld bekommen.

Code-Audit-Vorbereitung: die zwei Wochen vor dem Start

In diesem Zeitfenster zählen vier Vorarbeiten mehr als alles andere. Keine davon verändert Produktionscode.

Eine laufende Umgebung, die der Auditor wirklich nutzen kann

Die häufigste Verzögerung in Audit-Engagements ist das Aufsetzen der Umgebung. Wenn ein neuer Entwickler drei Tage und zwei Chat-Threads braucht, um deine Anwendung lokal zum Laufen zu bringen, verbrennt der Auditor dieselben drei Tage, und du bezahlst jeden einzelnen davon.

Lass vor dem Starttermin jemanden, der das Setup nicht gebaut hat, deine README auf einer sauberen Maschine durchgehen. Repariere, was dabei bricht. Docker hilft, aber das Tooling ist zweitrangig. Was zählt, ist, dass "klonen, installieren, starten, einloggen" ohne Stammwissen funktioniert. Wenn eine realistische lokale Umgebung außer Reichweite ist, weil das System von Daten oder Diensten abhängt, die du nicht replizieren kannst, sag das vorab und stelle stattdessen eine Staging-Umgebung mit repräsentativen Daten bereit. Ein Auditor, der Code nur lesen und nie ausführen kann, findet trotzdem vieles, aber die Findings zu Performance und tatsächlichem Verhalten unter Last werden schwächer ausfallen.

Eine einseitige Beschreibung der Deployment-Pipeline

Schreib auf, wie Code in Produktion gelangt: was einen Build auslöst, was die CI ausführt und was sie überspringt, wer deployen darf, wie Datenbank-Migrationen ausgeführt werden und wie ein Rollback in der Praxis aussieht, nicht in der Theorie. Eine Seite reicht.

Wenn sich das Schreiben dieser Seite als schwierig herausstellt, ist diese Schwierigkeit selbst ein Finding, und es ist besser, du entdeckst sie als der Auditor. Teams sind oft überrascht von ihrer eigenen Antwort auf die Frage, was zwischen Merge und Produktion läuft. Die Seite erspart dem Auditor außerdem, die Pipeline aus CI-Konfigurationsdateien ableiten zu müssen, was länger dauert und die informellen Schritte übersieht.

Eine Shortlist der Module, die dir Sorgen machen

Auditoren priorisieren, denn kein Audit liest jede Zeile mit derselben Aufmerksamkeit. Du weißt, wo die Leichen liegen: das Billing-Modul, das niemand anfassen will, die organisch gewachsenen Berechtigungsprüfungen, die Service-Klasse mit 4.000 Zeilen, deren Änderung drei Entwickler stillschweigend verweigern. Benenne diese Bereiche explizit, und das Audit investiert seine Tiefe dort, wo dein Risiko tatsächlich sitzt.

Manche Kunden zögern an dieser Stelle, weil das Zeigen auf Schwachstellen sich wie ein Geständnis anfühlt. Es ist das Gegenteil. Jede Stunde, die der Auditor nicht damit verbringt, zu entdecken, was du schon wusstest, ist eine Stunde für das, was du nicht wusstest.

Die Incident-Historie

Sammle die Produktions-Incidents der letzten zwölf Monate. Wenn ihr Postmortems schreibt, trage sie zusammen. Wenn nicht, reicht eine schlichte Liste: Datum, Symptom, was es behoben hat. Incidents häufen sich um dieselben architektonischen Schwächen, und diese Häufung zeigt einem Auditor auf eine Weise, wo er graben sollte, die keine statische Analyse leisten kann.

Was dein Auditor vom Team braucht

Über diese Vorarbeiten hinaus wird ein guter Auditor vor dem ersten Tag vier Dinge anfragen.

Die ursprünglichen Anforderungen, in welcher Form auch immer sie überlebt haben. Die Codebasis implementiert Entscheidungen, und ohne die Anforderungen dahinter kann ein Auditor bewusste Trade-offs nicht von Unfällen unterscheiden. Alte Tickets, ein Spezifikationsdokument, sogar ein aufgezeichneter Walkthrough mit dem Gründer funktionieren.

Die bekannten Problemzonen, aufgeschrieben von den Leuten, die täglich im Code arbeiten. Das überschneidet sich mit deiner Sorgen-Shortlist, geht aber weiter: flakige Tests, langsame Endpoints, seltsame Daten in alten Zeilen, dieser eine Cronjob, den niemand versteht.

Die aktuelle Teststrategie und ihr Tooling. Nicht nur die Coverage-Zahl, sondern welche Suites existieren, was in der CI läuft und was lokal, und ob das Team einem grünen Build genug vertraut, um darauf zu deployen. Ein Auditor liest Testqualität ganz anders, wenn er weiß, dass das Team die Suite als Dekoration behandelt.

Lesezugriff auf den Produktions-Monitoring-Stack, egal welcher es ist. Error-Tracking, Logs, Metrik-Dashboards. Zehn Minuten in einem echten Error-Tracker ordnen die Prioritäten eines Audits oft stärker neu als ein Tag Code-Lektüre.

Noch etwas, und es ist der günstigste Punkt auf dieser Liste: Benenne eine Kontaktperson, die während des Engagements zwei bis drei Stunden pro Woche für Fragen aufbringen kann. Audits geraten häufiger durch unbeantwortete Fragen ins Stocken als durch technische Hindernisse.

Was du vor einem Audit nicht tun solltest

Zwei Vorbereitungsinstinkte schaden dem Ergebnis aktiv, und beide sind verbreitet.

Räume nicht auf, um technische Schulden zu verstecken. Auditoren haben alles gesehen: die auskommentierten Blöcke, das TODO von 2019, den kopierten Controller. Eine kosmetische Säuberung in der Woche vor dem Audit verbirgt nichts davon, denn die Struktur darunter verrät es. Was die Säuberung stattdessen erreicht: Sie verschmutzt die Git-Historie, unmittelbar bevor jemand anfängt, sie zu lesen, und die Git-Historie ist eine der ergiebigsten Quellen eines Audits. Churn-Maps, Blame-Einträge und Commit-Muster zeigen, wie das Team wirklich mit dem Code arbeitet. Begrabe das unter einem Formatierungs-Commit über tausend Dateien, und du hast dafür bezahlt, dein eigenes Beweismaterial zu vernichten. Die Schulden sind genau das, was du begutachten lässt. Lass sie sichtbar sein.

Aktualisiere keine Dependencies direkt vor dem Audit. Ein frisches Framework- oder Library-Upgrade macht es schwer zu erkennen, welche Probleme seit Jahren im System sind und welche letzten Dienstag angekommen sind. Das Audit schreibt Verhalten am Ende der falschen Ära der Codebasis zu, und die Remediation-Prioritäten kommen falsch heraus. Wenn ein Upgrade aus Sicherheitsgründen dringend ist, mach es und sag es dem Auditor. Ansonsten friere Dependency-Änderungen von zwei Wochen vor dem Start bis zur Lieferung des Berichts ein.

Normale Feature-Arbeit kann durchgehend weiterlaufen. Ein Audit liest einen Snapshot plus Historie; es verlangt nicht, dass der Code stillhält.

Aus Findings ein Remediation-Backlog machen

Ein brauchbarer Bericht kommt mit nach Schweregrad geordneten Findings und Empfehlungen zur Behebung. Die Übersetzung in ein echtes Backlog ist der Punkt, an dem vorbereitete Kunden wieder davonziehen, weil sie jedes Finding auf den gesammelten Kontext abbilden können: welches Modul es berührt, welche Incidents es erklärt, wem der Bereich gehört.

Widersteh dem Drang, alles einzuplanen. Nimm zuerst die kritischen Punkte, Sicherheitsthemen vor allem anderen. Such dann die Findings, die andere Findings blockieren, denn ein entwirrter Abhängigkeitsgraph macht oft zehn nachgelagerte Punkte billiger. Gib jedem akzeptierten Finding einen Owner und eine grobe Größe, leg das Ergebnis neben deine Feature-Roadmap und entscheide die Aufteilung bewusst, statt die Dringlichkeit entscheiden zu lassen. Und lies den Bericht nach neunzig Tagen erneut, denn ein Bericht, den niemand wieder liest, ändert nichts.

Wenn die Findings eher auf ein längeres Modernisierungsvorhaben hindeuten als auf eine Liste von Fixes, ist das eine andere Art von Projekt, und wie wir das angehen, haben wir unter Legacy-Code-Optimierung beschrieben.

Der Fragebogen, den wir vor jedem Audit verschicken

Vor jedem Engagement schickt Wolf-Tech dem Kunden einen kurzen Fragebogen. Die Antworten formen den Audit-Plan, und die Fragen taugen zugleich als Selbsttest, den du heute durchführen kannst.

1. Was hat das Audit ausgelöst, und in welche Entscheidung sollen seine Ergebnisse einfließen?
2. Wer hat das System ursprünglich gebaut, und wer aus dieser Gruppe arbeitet noch daran?
3. Welche Teile der Anwendung vermeidet das Team, und was passiert, wenn es sie nicht vermeiden kann?
4. Wann habt ihr zuletzt deployt, und wie lange hat das Deployment von Anfang bis Ende gedauert?
5. Was passiert, wenn ein Deployment schiefgeht?
6. Welches Modul würde am meisten wehtun, wenn es an einem Freitagnachmittag ausfällt?
7. Was ist nach eurem Wissen bereits kaputt, und womit habt ihr euch arrangiert?
8. Was war der schlimmste Produktions-Incident des vergangenen Jahres, und was hat sich danach geändert?
9. Welches Test-Tooling läuft heute, und vertraut das Team einem grünen Build?
10. Wenn das Audit nur eine Frage mit Sicherheit beantworten könnte, welche würdest du stellen?

Kunden, die diese Fragen sorgfältig beantworten, bekommen ein schärferes Audit, weil der Plan bei ihren Risiken beginnt statt bei generischen Checklisten. Kunden, die oft mit "nicht sicher" antworten, bekommen ebenfalls etwas Wertvolles: eine Vorschau auf das, was das Discovery-Interview zutage fördern wird.

Wenn ein Audit bei dir ansteht oder du gerade entscheidest, ob du eines brauchst, beschreibt unsere Seite zu Code Quality Consulting, wie wir diese Engagements durchführen. Und wenn du ein zweites Paar Augen auf deine Vorbereitung selbst haben willst, schreib an hello@wolf-tech.io oder schau auf wolf-tech.io vorbei. Eine gut vorbereitete Codebasis macht die Rechnung nicht wie von Zauberhand kleiner, aber sie sorgt dafür, dass die Rechnung Findings kauft statt Setup-Zeit.