Zeig’ mir Deinen Code und ich sage Dir wer Du bist.

Oftmals kommen Unternehmen mit der Bitte um einen Code-Review auf uns zu. Gründe dafür gibt es viele, jedoch dreht es sich meistens um schlechte Erweiter- und Wartbarkeit der Software und in der Konsequenz um eine langsame Entwicklungsgeschwindigkeit (höhere Kosten). Häufig sind diese Anwendungen dann neue Patienten für die Code-Clinic.

Aus unserer Sicht kann man diese Probleme oft von unten heraus aus dem Code angehen. Ein erster Schritt hierfür ist ein externer Code-Review. Eine (nicht unbedingt gegensätzliche) Alternative wäre ein verwandter und umfänglicher Architektur-Review, aber das ist eine Geschichte für einen anderen Tag.

Vorgehensweise

Wenn wir mit einem Kunden einen Code-Review angehen so folgt zunächst - wie bei fast allen unseren Beratungsleistungen - ein intensives Gespräch mit dem Auftraggeber. Hierbei werden zentrale Fragestellungen, Anforderungen und Ziele geklärt:

  • “Wo drückt der Schuh besonders?”
  • “Was sind Ihre Erwartungen an den Review?”
  • “Welche wichtigen Stakeholder sind beteiligt und was sind die Rahmenbedingungen?”

In der Regel sind anschließend noch weitere Interviews und Gespräche nötig. Auch wenn Code oftmals für sich steht, können Mitglieder des Entwicklungsteams und deren direktes Umfeld ebenfalls wichtige Hinweise und Einstiegspunkte für den Review geben. Außerdem bevorzugen wir im Zuge unserer Firmenphilosophie ein offenes und transparentes Vorgehen im Gegensatz zu reinen “undercover Aktionen”.

Sobald alle notwendigen Gespräche geführt sind, ziehen wir uns mit dem Quellcode des Projekts zurück und analysieren ihn. Geeignete Einstiegspunkte kristallisieren sich oft bereits bei den Vorgesprächen heraus. Zusätzlich liefern Tool-gestützte Analysen (beispielsweise durch SonarQube) sinnvolle Ansatzpunkte. Nicht zuletzt lernt man mit der Zeit, Probleme und Schwachstellen im Quellcode schnell zu erkennen.

Je nach Projektumfang werden die gewonnenen Erkenntnisse parallel durch Rückfragen beim Team vertieft und gestärkt und erste identifizierte Probleme werden bestätigt oder entkräftet.

Am Ende des Code-Reviews steht die Zusammenfassung der Ergebnisse und deren Präsentation. Je nach Wunsch kann dies persönlich (z.B. in Workshops), schriftlich durch ein ausgearbeitetes Review-Dokument oder auch auf andere Arten geschehen. In der Regel werden die identifizierten Themen dargestellt, bewertet und mit Verbesserungsvorschlägen und Lösungsansätzen versehen. Es versteht sich von selbst, dass wir unsere Kunden auf Wunsch auch bei der Umsetzung dieser Lösungen unterstützen.

Ergebnisse

Auch wenn jedes Projekt, jedes Team und jeder Code anders ist, existieren oft sehr ähnliche Probleme.

So treffen wir beispielsweise regelmäßig auf einen inkonsistenten Mix verschiedenster Entwicklungsstile, Formatierungen und Bezeichnungen. Dies führt zu schlechter Lesbarkeit und einer unübersichtlichen Codebasis. Neue Entwickler finden sich dort nur schwer zurecht und auch auf die Geschwindigkeit von bestehenden Entwicklern hat dies erheblichen Einfluss.

Ein anderes, häufiges Problem ist die schlechte Struktur und Testbarkeit des bestehenden Codes. Diese resultiert oft aus der Verletzung verschiedener, grundlegender Prinzipien der Softwareentwicklung (siehe auch SOLID) und führt letztlich zu monolithischen und aufwändig wartbaren Anwendungen.

Auch die erarbeiteten Lösungsstrategien haben oftmals Gemeinsamkeiten. So können häufig Tools helfen: Eine automatisierte Toolchain von der Formatierung, über alle Arten von Testing und Analysen bis hin zum Deployment in Produktion kann hier große Wirkung zeigen. Andere Maßnahmen können beispielsweise intensive Workshops oder Schulungen des Teams mit Fokus auf die beim Review identifizierten Aspekte sein.

Code-Reviews sind nicht nur im Nachgang bei Problemen nützlich sondern können bereits vorher zur Überprüfung der Code-Qualität als regelmäßiges Quality-Gate zum Einsatz kommen. Wir verwenden dieses Qualitätssicherungsinstrument selbst in unseren Projekten und bei unseren Teams. Meist übernimmt ein erfahrener Kollege aus einem anderen Team den Review. Dies ist eine Methode, wie wir die Code-Qualität in unseren eigenen Projekten optimieren und stellt eine wirkungsvolle Ergänzung von Team-internen Reviews dar.


About Marc Kannegiesser

Senior Java Developer / Architect


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.