Wie schlimm ist es wirklich? Was eine zweiwöchige Codebase-Bewertung nicht-technischen Inhabern sagt

Die meisten Inhaber, die uns um eine Codebase-Bewertung bitten, vermuten bereits, dass die Antwort „nicht gut" lautet. Was sie wirklich brauchen, ist keine Bestätigung dieses Gefühls. Es ist eine priorisierte Liste, was falsch läuft, was die Behebung kosten wird und was bereits gut funktioniert, damit sie aufhören können zu raten und anfangen können zu entscheiden. Genau das soll eine zweiwöchige Codebase-Bewertung liefern, und es lohnt sich, konkret zu benennen, was am Ende auf dem Tisch landet, denn das Format ist genauso wichtig wie die Befunde selbst.

Warum eine Codebase-Bewertung zwei Wochen dauert, nicht länger

Eine Codebase-Bewertung ist kein vollständiges Audit. Wir haben an anderer Stelle beschrieben, was ein vollständiges PHP-Code-Audit kostet und was es abdeckt, und dieser Prozess kann bei einem großen System mehrere Wochen dauern. Eine zweiwöchige Bewertung ist anders zugeschnitten: Sie beantwortet eine einzige Frage, nämlich ob das System sicher genug ist, um weiter darauf aufzubauen, und das so schnell, dass noch Budget übrig bleibt, um im selben Quartal auf die Antwort zu reagieren.

Zwei Wochen reichen für einen erfahrenen Entwickler aus, um die Architektur zu lesen, die Anwendung lokal auszuführen, das Datenbankschema mit dem abzugleichen, was der Code tatsächlich tut, sich anzusehen, wie Deployments ablaufen, und mit denjenigen auf Ihrer Seite zu sprechen, die sich noch erinnern, warum bestimmte Entscheidungen getroffen wurden. Es reicht nicht, um jede Datei zu lesen, und das sollte auch nicht der Anspruch sein. Es geht um Urteilsvermögen, nicht um Vollständigkeit. Ein System mit 200.000 Zeilen PHP-Code muss nicht Zeile für Zeile gelesen werden, um zu wissen, ob die Authentifizierungsschicht solide ist oder ob Ihr Rechnungsjob nur eine fehlgeschlagene Migration von der Beschädigung von Kundendaten entfernt ist.

Was Sie bekommen

Das Ergebnis ist ein kurzer schriftlicher Bericht, meist zehn bis fünfzehn Seiten, gegliedert nach Schweregrad statt nach Datei oder Modul. Erwarten Sie drei Abschnitte.

Der erste listet auf, was jetzt sofort Aufmerksamkeit braucht: Sicherheitslücken, Risiken für die Datenintegrität, alles, was einen Ausfall oder einen Sicherheitsvorfall verursachen könnte, wenn es unbeachtet bleibt. Diese kommen mit einer verständlichen Erklärung des tatsächlichen Risikos, nicht mit einem Schweregrad-Wert aus einem statischen Analysetool. „Dieser Endpunkt akzeptiert unvalidierte Eingaben aus einem öffentlichen Formular und schreibt sie direkt in eine SQL-Abfrage" ist ein Befund. „47 SQL-Injection-Warnungen gefunden" ist das nicht, weil es nichts darüber verrät, welche davon real sind und welche nur Rauschen von einem Framework, das Eingaben an anderer Stelle bereits selbst escaped.

Der zweite Abschnitt behandelt das, was Sie im nächsten Jahr ausbremsen wird, wenn niemand sich darum kümmert: die Teile der Codebase, in denen jede Änderung dreimal so lange dauert wie nötig, meist weil es keine Testabdeckung gibt, oder weil eine einzige Klasse alles macht, oder weil dieselbe Geschäftslogik in vier verschiedenen Stellen kopiert wurde und niemand mehr daran denkt, alle vier zu aktualisieren. Das ist der Abschnitt, der erklärt, warum Ihre letzten zwei Feature-Anfragen länger gedauert haben, als der Entwickler versprochen hatte, und oft ist er der nützlichste Teil des Berichts für einen nicht-technischen Inhaber, weil er eine vage Beschwerde über langsame Lieferzeiten in konkrete, behebbare Ursachen verwandelt.

Der dritte Abschnitt ist bewusst kurz: was bereits gut läuft. Inhaber erwarten diesen Teil selten, und er ist wichtiger, als er aussieht. Ein Bericht, der nur Probleme aufzählt, lässt jede Codebase gleich verloren erscheinen, was weder zutrifft noch hilfreich ist. Wenn Ihre Testsuite tatsächlich funktioniert, Ihre Deployment-Pipeline solide ist oder die Kerngeschäftslogik gut organisiert ist, selbst wenn die Ränder unordentlich sind, müssen Sie das auch wissen, weil es beeinflusst, wo Sie Geld investieren.

Wie die Befunde priorisiert werden

Jeder Punkt im Bericht trägt zwei Zahlen: wie schlimm es ist, wenn sich nichts ändert, und wie viel Aufwand die Behebung ungefähr kostet. Ein fehlender Index, der einen selten genutzten Bericht langsam macht, ist ein echter Befund mit niedriger Priorität. Ein fehlender Index auf der Tabelle, die Ihr nächtlicher Rechnungsjob durchsucht, ist dasselbe technische Problem mit einer völlig anderen Priorität, weil die geschäftliche Auswirkung eine andere ist. Nur nach Schweregrad zu priorisieren, ohne das gegen Ihre tatsächliche Nutzung abzuwägen, führt zu Audits mit fünfzig „kritischen" Befunden, auf die niemand reagieren kann. Eine auf eine Geschäftsentscheidung ausgerichtete Codebase-Bewertung sollte eine Liste liefern, die Sie an denjenigen weitergeben können, der über das Budget entscheidet, mit den ersten drei Punkten bereits identifiziert.

Was ein nicht-technischer Inhaber vor der Beauftragung fragen sollte

Fragen Sie, was mit Schnellkorrekturen passiert, die nebenbei auffallen. Eine gute Bewertung wird eine Handvoll kleiner Probleme, Sicherheitspatches oder einen offensichtlichen Bug, notieren und manchmal direkt beheben, ohne das als Scope-Erweiterung zu behandeln. Fragen Sie, ob der Bericht konkrete Dateien und Klassen nennt oder ob er in Allgemeinplätzen spricht. Fragen Sie, wer die letzte Seite schreibt, denn die letzte Seite sollte Ihre eigentliche Frage direkt beantworten: Ist es sicher, darauf weiter aufzubauen oder nicht, und was kostet es, dorthin zu kommen. Wenn sich ein Angebot nicht schriftlich darauf festlegen kann, diese Frage zu beantworten, ist es nicht die Bewertung, die Sie suchen.

Es hilft auch zu fragen, was die Bewertung nicht sagen wird. Zwei Wochen fangen nicht alles ein, was ein sechswöchiges Audit finden würde, und sie liefern keinen vollständigen Sanierungsplan mit Stundenangaben für jede Behebung. Was Sie bekommen, sind genug Informationen für die nächste Entscheidung: so weitermachen wie bisher, Hilfe für bestimmte Problembereiche holen, oder das tiefere Audit beauftragen, weil die Bewertung etwas aufgedeckt hat, das es braucht.

Den Bericht nutzen, wenn Sie ihn haben

Der Bericht ist nur nützlich, wenn jemand auf die erste Seite reagiert. Wir haben Inhaber gesehen, die eine Bewertung beauftragt, gelesen, jedem Wort zugestimmt und dann sechs Monate nichts unternommen haben, weil niemand die Nachverfolgung übernommen hat. Die Lösung ist meist einfach: Bevor die Bewertung beginnt, legen Sie fest, wer auf Ihrer Seite den Bericht liest und wer befugt ist, die erste Runde von Korrekturen zu genehmigen. Diese Person muss die technischen Details nicht verstehen. Sie muss nur zu den drei obersten Punkten der Liste Ja sagen können.

Wenn der Bericht etwas Dringendes aufdeckt, eine Sicherheitslücke oder ein Datenintegritätsrisiko, sollte diese Arbeit sofort beginnen, getrennt von jedem längeren Gespräch darüber, ob der Rest des Systems refaktoriert oder neu gebaut werden soll. Die beiden Probleme laufen auf unterschiedlichen Uhren. Das eine muss diese Woche behoben werden. Das andere braucht eine Entscheidung, mit der Sie die nächsten Jahre leben können, und diese Entscheidung verdient mehr Zeit, als die Bewertung selbst benötigt. Wenn der Bericht auf tiefere strukturelle Probleme hinweist statt auf eine kurze Liste von Korrekturen, ist das meist der Punkt, an dem eine fortlaufende Code-Qualitätsberatung ansetzt und den Rückstand in geplanter Reihenfolge abarbeitet, statt ein Problem nach dem anderen zu löschen.

Eine zweiwöchige Codebase-Bewertung wird Ihnen nicht alles über Ihr System sagen, und das soll sie auch nicht. Sie soll „Ich weiß nicht, wie schlimm es ist" durch eine priorisierte, bezifferte Liste ersetzen, die Sie tatsächlich nutzen können. Wenn Sie vor einem System stehen, das niemand mehr vollständig versteht, und diesen Ausgangspunkt brauchen, schreiben Sie uns an hello@wolf-tech.io oder schauen Sie sich an, was wir unter wolf-tech.io machen. Wir sagen Ihnen ehrlich, ob zwei Wochen der richtige Umfang für Ihre Situation sind, oder ob Sie etwas Kürzeres oder Längeres brauchen.