Eine externe Sicht auf den eigenen Code

Ein Code-Review ist ein vergleichsweise kleiner Auftrag mit überdurchschnittlicher Wirkung, und trotzdem einer der selteneren. Der Grund ist meist nicht das Geld, sondern die Sorge vor dem Ergebnis. Dabei geht es nicht um eine Note für das Team, sondern um eine Landkarte: Wo steht die Anwendung, welche Stellen kosten im Alltag am meisten, und in welcher Reihenfolge lohnt es sich, sie anzugehen. Genau das ist gefragt, wenn eine Investitionsentscheidung ansteht oder eine größere Umstellung geplant wird.

Der Ablauf beginnt mit einem gemeinsamen Rundgang mit jemandem aus dem Team. Das spart erfahrungsgemäß Tage, weil bekannte Schwachstellen sofort benannt werden, statt dass sie erst gefunden werden müssen. Danach folgt die maschinelle Prüfung mit statischer Analyse und einem Blick auf die Composer-Abhängigkeiten, und darauf aufbauend die manuelle Durchsicht, in der die eigentlichen Befunde entstehen: der Schnitt der Architektur, der Umgang mit der Fachlogik, Rechteprüfungen an den Schnittstellen, Datenbankzugriffe in Schleifen, der Zustand der Tests.

Das Ergebnis ist immer ein schriftlicher Bericht. Er beginnt mit einer kurzen Zusammenfassung, die auch ohne technischen Hintergrund lesbar ist, und listet danach die Einzelbefunde nach Dringlichkeit, jeweils mit einer Einschätzung zu Aufwand und Wirkung. Diese Reihenfolge ist der eigentliche Wert: Fast jede gewachsene Anwendung hat eine lange Liste möglicher Verbesserungen, aber nur wenige davon zahlen sich wirklich aus. Der Bericht gehört dem Auftraggeber und darf ausdrücklich auch als Grundlage für Angebote anderer dienen.

Ein Punkt ist dabei wichtiger, als er klingt: der Ton. Bewertet wird die Sache, nicht die Person. Vieles, was heute unglücklich aussieht, war unter den damaligen Randbedingungen eine vernünftige Entscheidung, oft unter Zeitdruck. Ein Bericht, nach dem sich das Team vorgeführt fühlt, wird nicht umgesetzt und hat damit seinen Zweck verfehlt. Ebenso gilt: Wenn das Ergebnis lautet, dass der eingeschlagene Weg trägt, steht das genauso im Bericht.

Ein Review passt gut vor einer Modernisierung oder einem PHP-Update, weil es die Aufwandsschätzung dafür belastbar macht. Es lässt sich aber auch fortlaufend anlegen, als regelmäßiger Blick auf die Änderungen im Rahmen der laufenden Betreuung. Auf Wunsch schließt sich Mitarbeit bei der Umsetzung an; Bedingung ist das nicht.

Die Zusammenarbeit läuft standardmäßig zu 100 % remote und damit ortsunabhängig, direkt mit Auftraggebern, als Verstärkung für Agenturen und über IT-Vermittler. Für die Prüfung genügt lesender Zugriff; eine Vertraulichkeitsvereinbarung gibt es auf Wunsch vorab, lokale Kopien werden nach Abschluss gelöscht. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich, etwa für die Besprechung des Berichts mit dem Team.