Interview mit Rabea Gransberger

„TDD ist kein Ersatz für Code Reviews“
Kommentare

„Given enough eyeballs, all bugs are shallow“ – so beschrieb Eric S. Raymond einst das Prinzip hinter Code Reviews. Das angewandte Mehr-Augen-Prinzip mag altmodisch und mühselig erscheinen, ist aber ein probates Mittel zur Qualitätssicherung in der Softwareentwicklung. In ihrem Vortrag auf der diesjährigen JAX beantwortet Rabea Gransberger die wichtigsten Fragen zu Code Reviews: Welche Tools stehen zur Verfügung? Wo fängt man einen Review an? Wer ist für die Reviews zuständig? Wie formuliert man Verbesserungsvorschläge? usw. Einen kleinen Vorgeschmack hat sie uns in folgendem Interview gegeben.

Dein Thema auf der JAX sind Codereviews. Du gibst Tipps aus der Praxis. Doch fangen wir mal von vorne an: Weshalb ist es überhaupt wichtig, Codereviews durchzuführen?

Rabea Gransberger: Jeder hat sicherlich schon mal was von der 80/20-Regel oder dem Paretoprinzip gehört: Die ersten 80 Prozent einer zu programmierenden Funktion stellt man in 20 Prozent der Zeit fertig, und für die letzten 20 Prozent benötigt man 80 Prozent der Zeit. Das lässt sich nicht nur auf die Programmierung anwenden, sondern genauso lässt sich auch die Gesamtnutzungsdauer einer Software aufteilen: Die meiste Zeit verbringen wir letztlich damit, bestehenden Code zu warten, kleinere Fehler zu beheben oder kleine Erweiterungen zu entwickeln. Wenn der bestehende Code nicht vom ganzen Team lesbar ist, kann die Wartung jedoch deutlich mehr Zeit in Anspruch nehmen. Die Unsicherheit der Entwickler bei Änderungen wächst, und damit sinkt ggf. auch der Spaß an der Arbeit. Peer Code Reviews, bei denen wechselnde Teammitglieder den von anderen Teammitgliedern geschriebenen Code manuell inspizieren, können dafür sorgen, dass der Code leicht lesbar ist.

JAX 2015

JAX 2015

Die JAX (20.-24. April 2015) bildet mit der W-JAX Europas führende Konferenz-Serie für Enterprise-Technologien, agile Methoden und Software-Architekturen. Gemeinsam mit den begleitenden Business Technology Days und der BigDataCon verleiht sie IT-Professionals führender Unternehmen aller Branchen die entscheidenden Impulse für digitale Wertschöpfung und Innovation – zwei Mal im Jahr. Noch bis 12. Februar profitieren Sie von den Frühbucherrabatten. Mehr Informationen unter http://jax.de.

Zusätzlich können in Code Reviews Fehler vor dem Release gefunden werden, die von einem anderen Entwickler unbeabsichtigt eingebaut wurden. Mitten in der Programmierung einer neuen Funktion kommt z. B. ein Anruf dazwischen, und schon vergisst man an der einen oder anderen Stelle, einen Teil zu programmieren, der gerade noch fest im Kopf eingeplant war. Durch die manuelle Code-Inspektion können vor allem Problemstellen gefunden werden, die durch manuelles Testen unbemerkt bleiben, z. B. ein fehlender else-Block. Diese treten nämlich nur in sehr seltenen Fällen auf. Studien zeigen eine Reduktion der Fehler durch manuelle Code Reviews von bis zu 60 Prozent.

Einerseits geht es darum, Fehler aufzuspüren – andererseits sicher um das Thema Qualität: Wie stellt man sicher, dass alle Entwickler eines Projekts qualitativ gleichwertigen Code  – zum Beispiel im Sinne von Clean Code – schreiben?

Gransberger: Jedes Software-Projekt sollte vor dem Start Regeln definieren, wie der Code syntaktisch aufgebaut sein soll, welche Namenskonventionen zu befolgen sind und welche Frameworks wie eingesetzt werden sollen. Dabei kann es tatsächlich darum gehen, in welcher Zeile eine Klammer zu setzen ist oder wie Methoden für die Abfrage der Datenbank mit mehreren Parametern benannt werden.

Viele dieser simplen Regeln können bereits durch Formatierungsvorlagen und Code-Templates in der Entwicklungsumgebung eingestellt werden und müssen daher von den Entwicklern nicht explizit beachtet werden. Zusätzlich gibt es bestehende Tools wie Checkstyle, in denen vordefinierte Regeln konfiguriert und sogar eigene Regeln definiert werden können und dann in die Entwicklungsumgebung integriert werden. Dadurch erhält der Entwickler ein direktes Feedback, und der manuelle Aufwand eines strukturellen Reviews entfällt.

Stattdessen kann der Blick auf größeren Themen wie den Einsatz von Design Patterns zum Aufbau der internen und externen APIs gelenkt werden. Während man selber seinen Code beim Programmieren absolut verständlich findet, stellt sich das häufig für andere Entwickler anders dar. Wenn eine Methode nicht verständlich ist, fehlt nicht etwa ein Kommentar, sondern die Methode trägt vielleicht einen falschen Namen, der eine andere Bedeutung nahe legt.

Die Annahme „Ich verstehe den Code nicht, weil ich nicht so gut im Programmieren bin wie der, der den Code geschrieben hat“ ist leider immer noch weit verbreitet, nach meiner Ansicht aber falsch. Ein manueller Code Review eines anderen Entwicklers kann diese Stellen aufdecken, und in einem Gespräch können bessere Lösungswege erörtert werden. Ziel ist es, dass jeder Entwickler etwas dazu lernt und Code Reviews als positive Kritik und Weiterentwicklungsmöglichkeit aufgefasst werden.

Durch diese konstruktiven Hinweise anderer Programmierer erreichen nach und nach alle Teammitglieder das gleiche Niveau.

Rabea GransbergerRabea hat Informatik an der Universität Bremen studiert und das Studium 2008 mit einem Diplom abgeschlossen. Seitdem arbeitet sie als Softwareentwicklerin, Abteilungsleiterin und Projektleiterin bei MEKO-S. Ihr ist es besonders wichtig, qualitativ hochwertigen Code zu schreiben und die Entwickler in ihrem Team entsprechend fortzubilden. Dieser Bereich zählt auch zu ihren Hauptthemen für Vorträge auf diversen Konferenzen und an User-Group-Abenden. Hauptsächlich programmiert Rabea an dem Eclipse-RCP/RAP-basierten Projekt OTIS. Im Jahr 2012 hat Rabea die Java User Group Bremen gegründet und leitet diese seitdem. Neben der Softwareentwicklung ist Rabea leidenschaftlicher Fußballfan und bei jedem Spiel im heimischen Weserstadion zu finden.

Was würdest du jemandem entgegenhalten, der sagt: „Wir machen TDD – dann brauchen wir keine Reviews mehr!“

Gransberger: Der Ansatz des Test Driven Development möchte sicherstellen, dass der Code von Anfang an getestet wird und so nach Möglichkeit weniger Fehler enthält. Test Driven Development kann aber auch dabei helfen, besseren Code zu entwickeln, da die Testfälle einen guten Blick auf die Nutzung der in der Entwicklung befindlichen API bieten. Schwachstellen wie z. B. zu starke Kopplung können dadurch direkt vermieden werden.

Wenn jeder Entwickler jedoch allein für sich Testfälle und APIs schreibt, fehlt der Blick eines anderen Entwicklers, der die oben genannte Lesbarkeit des Codes aus einem anderen Blickwinkel überprüfen kann. TDD kann daher nicht als Ersatz für Code Reviews gesehen werden.

Eine Möglichkeit, Reviews parallel zur Entwicklung durchzuführen, die sich mit TDD verbinden lässt, ist das Pair Programming. Die Entwickler können über Namensgebung und API-Design diskutieren und sich so gemeinsam verbessern. Durch wechselnde Paarungen wird das Wissen so im ganzen Team verteilt. Ein weiterer positiver Aspekt ist, dass man vom Partner sogar Tipps erhält, wie man die Entwicklungsumgebung oder den Rechner insgesamt noch effizienter nutzen kann, z. B. durch die Verwendung von Shortcuts.

Im Eclipse-Kontext ist das Tool Gerrit weit verbreitet. Welche Werkzeuge kannst du zur Unterstützung von Reviews empfehlen – und warum?

Gransberger: Gerrit ist nur eines von vielen Tools, die beim manuellen Durchgehen von Code durch einen anderen Entwickler unterstützend eingesetzt werden können. Diese Werkezuge bieten die Möglichkeit, ein Changeset/Commit/Patch, also ein Paket von Code-Änderungen, zu einem Review bereitzustellen. Dabei werden die von Entwicklern gemachten Änderungen am Code wie in einem Diff-Editor hervorgehoben und Werkzeuge zur Navigation und vor allem zum Erstellen von Kommentaren angeboten. Die Kommentare des Reviewers können an eine Codestelle angeheftet werden und teilweise auch mit Prioritäten und Klassifizierungen (wie Unschönheit oder Fehler) versehen werden.

Nach Abschluss des Reviews wird der Entwickler benachrichtigt und kann die markierten Codestellen und Kommentare durchgehen, Verbesserungen vornehmen und ggf. Nachfragen als weitere Kommentare hinterlegen. Danach wird der Code erneut zum Review eingereicht. Dadurch können Diskussionen zum Code zeitlich versetzt und auch über das Internet von Remote-Entwicklern geführt werden.

Da wir in unserem Team kein Git verwenden, können wir Gerrit leider nicht nutzen. Ähnliche weitere Werkzeuge habe ich bisher erfolglos getestet. Häufig verrutschen die Kommentare, die Werkzeuge sind nicht in die Entwicklungsumgebung integriert, benötigen einen separaten Webserver oder sind mit der verwendeten Versionsverwaltung nicht kompatibel. In Vorbereitung auf meinen Vortrag bei der JAX werde ich die aktuellen Versionen dieser Systeme erneut testen.

Momentan werden Issues über unseren Issue Tracker zum Review eingetragen. Der Code wird mit dem integrierten Diff-Viewer betrachtet, und Kommentare werden von uns mit simplen Tags wie //FIXME und //TODO, jeweils mit der ID aus dem Bugtracker oder dem Kürzel des Entwicklers versehen, direkt im Code erfasst. Diese Kommentare werden in die Versionskontrolle zum dem Issue mit eingecheckt und dem Entwickler wieder zugewiesen.

Für den automatischen Review kann ich weitere Tools wie FindBugs, JaCoCo oder auch kostenpflichtige Software wie Coverity empfehlen. FindBugs und Coverity finden durch statische Analyse des vorliegenden Codes Anti-Pattern und mögliche Fehler und geben dem Entwickler auch eine Erklärung, warum der vorliegenden Code möglicherweise Fehler enthält. Durch den Einsatz von Code Coverage Tools wie JaCoCo kann die Abdeckung des Code mit Testfällen überprüft werden. Code-Fragmente, die nicht durch Testfälle abgedeckt sind, sollten bei Änderungen einem manuellen Review unterzogen werden.

Die Entwicklungsumgebungen bieten mittlerweile ebenfalls bereits integrierte Tools zur statischen Code Analyse, z. B. durch zusätzliche Compilerparameter, die auf mögliche NPEs oder komplexe Codefragmente hinweisen.

Und vielleicht hast du zum Schluss noch einen exklusiven Tipp parat, der sich als Erfolgsfaktor bei Codereviews bewährt hat?

Gransberger: Das Wichtigste: Einen Anfang zu finden. Das ist am einfachsten durch die Konfiguration von Tools wie FindBugs und Checkstyle möglich. Dann können zusätzlich noch stichprobenartig einzelne kleinere Funktionen einem manuellen Review unterzogen werden. Sie werden überrascht sein, wie viele Fehler sich in kleinen Code-Abschnitten verstecken können.

Den Erfolg von Code Reviews in Zahlen darzustellen ist sicherlich schwierig. Der zeitliche Aufwand von manuellen Code Reviews kann sehr abschreckend wirken. Die Verbesserung der Code-Qualität, das Auffinden von Fehlern vor dem Release und das Voneinander-Lernen werden die Geschwindigkeit der Entwicklung über einen längeren Zeitraum jedoch deutlich erhöhen. Hinzu kommen die höhere Zufriedenheit der Kunden und der geringere Supportaufwand durch weniger Fehler als positive Faktoren hinzu. Eine Kombination der zuvor genannten Tools und manuellen Reviews hat bei uns zu einer deutlichen Steigerung von Qualität und zu einer erhöhten Kundenzufriedenheit beigetragen. Trotz des zunächst abschreckenden Zusatzaufwands kann ich toolgestützte und manuelle Code Reviews nur empfehlen.

Aufmacherbild: „picture of human hand with magnifying glass in front of digital code with bugs, software testing concept“ von shutterstock.com / Urheberrecht: Shai_Halud

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -