Suche
Vier-Augen-Prinzip angewandt: Agile Review und Review for Eclipse

Bessere Software durch Codereviews

Simon Olofsson
© shutterstock.com/borisovv

Software effizient, wartbar und möglichst fehlerfrei zu entwickeln, ist keine triviale Aufgabe. Ein wesentlicher Faktor hierfür ist die frühzeitige Erkennung von Defekten. Dieser Artikel beschreibt Codereviews als wichtigen Bestandteil der agilen Softwareentwicklung und zeigt die praktische Umsetzung mittels Eclipse auf.

Eric S. Raymond beschreibt in einem Satz die Idee hinter Codereviews: „Given enough eyeballs, all bugs are shallow“ [1]. Das Vier-Augen-Prinzip gilt natürlich auch in der Softwareentwicklung und stellt eine einfache Methode dar, um Qualität und Wartbarkeit zu erhöhen. Der Austausch von Wissen ist ein weiteres Ziel von Codereviews.
Ein Review kann auf verschiedenen Ebenen und Stufen der Softwareentwicklung stattfinden. Das IEEE unterscheidet in dem Standard 1028-2008 Managementreviews, technische Reviews, Inspektionen, Walk-Throughs und Audits [2]. Dabei werden die unterschiedlichen Ziele (Tabelle 1), die Rollen der Beteiligten und die Durchführung des Reviews beschrieben. Im Folgenden nehmen wir Walk-Throughs unter die Lupe.

Reviewart Ziele
Managementreview Überwachung des Projektfortschritts; Anpassung von Zielen und Ressourcen
Technisches Review Konformität mit Spezifikationen und Plänen sicherstellen; Integrität von Änderungen beurteilen
Inspektion Anomalien finden; Lösungen und Qualität überprüfen
Walk-Through Anomalien finden; Alternativen untersuchen; Produkt verbessern; Möglichkeit zum Lernen
Audit Unabhängige Überprüfung der Konformität mit Standards und Bestimmungen

Tabelle 1: Die verschiedenen Reviewarten und ihre Ziele, nach IEEE 1028-2008

Das grundsätzliche Vorgehen ist bei Codereviews immer ähnlich: Ein vorher festgelegter Teil des Quellcodes wird von Entwicklern, die nicht an der Erstellung beteiligt waren, begutachtet und nach Fehlern durchsucht. Dadurch werden mögliche Fehler frühzeitig gefunden, und fehlerhafter Quellcode kann korrigiert werden. Je später im Entwicklungsprozess ein Fehler gefunden wird, desto aufwändiger und somit teurer ist seine Behebung. Die Diskussionen und Gespräche während eines Reviews ermöglichen einen Wissensaustausch und eine stetige Verbesserung der eigenen Kenntnisse.

Durchführung von Codereviews

Zur erfolgreichen Durchführung von Codereviews sollten diese in den Vorgehensprozess eingebunden werden. Wird Scrum eingesetzt, können beispielsweise kurze tägliche Reviews, in denen aktuelle Entwicklungen mit überschaubaren Änderungen besprochen werden, durch längere Codereviews am Sprint-Ende ergänzt werden. In den längeren Reviews können einzelne Komponenten ausführlicher begutachtet werden.
Die Akzeptanz von Reviews hängt davon ab, ob diese positiv wahrgenommen werden. Kritik und Verbesserungsvorschläge sollten sachlich vorgetragen werden, ohne den Autor des Codes persönlich anzugreifen. Für ein Problem gibt es immer mehrere Lösungen, und in manchen Fällen ist eine andere Lösung eleganter als die ursprünglich ausgewählte. Man sollte jedoch nicht aus einer gewählten Lösung auf die Fähigkeiten des Autors schließen. Wird der positive Aspekt nicht betont, entsteht schnell eine ablehnende Haltung gegenüber Codereviews.
Die direkte Kommunikation in einem persönlichen Gespräch ist die Grundlage, um konstruktive Kritik anbringen zu können. Reviewtools sollten diesen Prozess unterstützen und nicht ersetzen. Wichtig ist ebenfalls, dass Reviews regelmäßig stattfinden und nicht vom Quellcodeautor dominiert werden. Der sollte das Review vorbereiten und einen passenden Einstiegspunkt auswählen, sich danach aber zurückhalten. So behält der Reviewer die Kontrolle und kann die Geschwindigkeit selbstständig bestimmen. Als Einstieg in ein Review können beispielsweise die Benutzeroberfläche oder die zugehörigen Unit Tests dienen.
Als Voraussetzung für ein Codereview sollten alle automatisierten Test- und Prüfverfahren abgeschlossen und hierbei entdeckte Defizite behoben sein. Damit ist insbesondere gemeint, dass Unit Tests, automatisierte Checks (z. B. Checkstyle, Findbugs und PMD), statische Analysen und die kontinuierliche Integration vor einem Review stattfinden. Durch diese Voraussetzung wird deutlich, dass Reviews sinnvollerweise nach der Aufnahme in das Versionskontrollsystem (Commit) stattfinden sollten. Es kann nützlich sein, hierfür einen eigenen Feature-Branch zu verwenden, falls größere Nacharbeiten durch das Review erwartet werden.
Die Ergebnisse eines Codereviews sollten selbstverständlich dokumentiert werden, damit die gefundenen Schwachstellen behoben werden können. Hierzu ist es hilfreich, ein Tool in die Entwicklungsumgebung einzubetten, mit der das Review durchgeführt wird. Im Folgenden wird die Durchführung von Codereviews mit Eclipse und dazu passenden Plug-ins vorgestellt.

Aufmacherbild: 4-5 years boy is holding magnifying glass in front of his eye shot in studio on white background von Shutterstock / Urheberrecht: borisovv

[ header = Seite 2: Codereviews mit Eclipse ]

Codereviews mit Eclipse

Das wesentliche Artefakt eines Codereviews ist die Dokumentation der zu verbessernden Quellcodeteile. Die Überarbeitung des Codes sollte möglichst zeitnah zum Review erfolgen, damit offene Fragen geklärt werden können. Im einfachsten Fall wird der entsprechende Teil des Quellcodes mit einem Kommentar und einem Marker versehen. Neben „TODO“ bietet sich die Einführung eines eigenen Markers an (in Eclipse als „Task Tag“ bezeichnet) (Abb. 1). So können alle Kommentare eines Reviews schnell gefunden werden.

Abb. 1: Definition eines eigenen Task-Tags in Eclipse

Nachteile bei der Verwendung von einfachen Codekommentaren sind die fehlende Nachverfolgbarkeit und der nicht vorhandene Status. Oft ist es wünschenswert, die Kommentare eines bestimmten Reviews im Nachhinein zu sehen und zu überprüfen, ob die notwendigen Änderungen eingearbeitet wurden. Hiermit können interessante Metriken über die Wirksamkeit der Reviews erzeugt werden.
Die beiden Plug-ins „Agile Review“ und „Review for Eclipse“ bieten Unterstützung bei der Durchführung von Codereviews und eliminieren die obigen Nachteile. Ihr Funktionsumfang und ihre Einsatzmöglichkeiten sind dabei komplementär, sodass sie sich für unterschiedliche Anforderungen eignen.

Agile Review

Agile Review [4] für die empfehlenswerte Dokumentation zum Schnelleinstieg wird von vier Softwareentwicklern betreut und lässt sich über den Eclipse-Marketplace installieren. Der Fokus liegt vor allem auf der einfachen Erfassung von Kommentaren, die während des Reviews anfallen. Diese Kommentare können sich auf eine ganze Datei oder einen bestimmten Quellcodeabschnitt beziehen. Die einfache Bedienung von Agile Review wird durch eine übersichtliche Benutzeroberfläche unterstrichen.
Als Voraussetzung für ein Review wird ein Review Source Project benötigt, das die Kommentare eines Reviews abspeichert und in einem Versionskontrollsystem abgelegt werden kann, sodass es für alle Teammitglieder zugänglich ist. Es hat sich bewährt, für jedes Team ein eigenes Projekt anzulegen und für alle Reviews dieses Teams zu nutzen. In der AgileReview-Perspektive können im Review Explorer Reviews verwaltet werden. So ist es möglich, Reviews zu erstellen, zu löschen oder als aktiv zu markieren.
Nach der Erstellung eines Reviews kann eine Datei im Editor geöffnet und für die Auswahl ein Kommentar erstellt werden (über die Lupe mit dem Plus-Zeichen). An dieser Stelle im Quellcode wird ein Kommentar mit der Review-ID, dem Autor und der Kommentar-ID erstellt (Abb. 2). Der eigentliche Kommentar wird im Review Source Project in einer XML-Datei gespeichert. Zu jedem Kommentar können der Status, die Priorität und optional ein Adressat angegeben werden. Antworten auf Kommentare sind ebenfalls möglich.

Abb. 2: Erfassung eines Kommentars mit Agile Review

Die dritte Ansicht der Agile Review-Perspektive ist die Liste alle Kommentare. Diese kann sortiert und gefiltert werden, um eine passende Darstellung zu ermöglichen. Mit drei Ansichten (Verwaltung von Reviews, Erfassung von Kommentaren und Übersicht aller Kommentare) und der Speicherung von Reviews in XML-Dateien, die im Team geteilt werden können, gestaltet sich Agile Review sehr übersichtlich und ohne unnötige Extras. Zwei weitere nützliche Funktionen sind die Einstellungen von Agile Review, in denen unter anderem der Name des Autors konfiguriert werden kann, sowie die Möglichkeit, alle Kommentare eines Reviews aus den Quellcodedateien zu entfernen (im Kontextmenü eines Projekts AGILEREVIEW PROJECT CLEANUP auswählen).
Oftmals ist es hilfreich, Auswertungen der Reviews zu erstellen, um beispielsweise zu sehen, an welchen Stellen noch Anmerkungen offen sind oder wie viele Kommentare pro Review erstellt wurden. Agile Review bietet hierzu eine nützliche Exportfunktion an, die anhand einer Excel-Vorlage einen Report erstellt. Da die XML-Dateien jedoch sehr einfach aufgebaut sind, können sie auch anderweitig verarbeitet werden. Zu jedem Review gehört eine review.xml mit Metadaten (Name, Verantwortlicher, Beschreibung etc.) und für jeden Autor eine XML-Datei mit den zugehörigen Kommentaren (Listing 1).

<?xml version="1.0" encoding="UTF-8"?>
<de:comments  xmlns:de="…"
  <de:author name="Simon Olofsson"/>
  <de:files>
    <de:project name="TestProject">
      <de:folder name="src">
        <de:folder name="de">
          <de:folder name="olofsson">
            <de:file name="TestClass.java">
              <de:comment id="c0" author="Simon Olofsson" reviewID="Review 14.08.2013" creation-date="…"
                last-modified="…" priority="0" recipient="" status="0" revision="0">
                <de:text>Ein sprechender Variablenname wäre angebracht!</de:text>
                <de:replies/>
              </de:comment>
            </de:file>
          </de:folder>
        </de:folder>
      </de:folder>
    </de:project>
  </de:files>
</de:comments>

[ header = Seite 3: Review for Eclipse ]

Review for Eclipse

Review for Eclipse (R4E) ist ein Projekt aus dem Eclipse-Inkubator und wird vor allem von Ericsson- und Tasktop-Mitarbeitern entwickelt. Um die neuesten Features von R4E nutzen zu können, ist es empfehlenswert, einen Nightly Build zu verwenden. Ein solcher läuft in der Regel stabil. Das Benutzerhandbuch bietet einen umfangreichen Überblick über die angebotenen Funktionen [5]. Die Benutzeroberfläche besteht im Wesentlichen aus dem Review Navigator, der alle verfügbaren Elemente (Reviews, Anomalien etc.) darstellt. Zum Anzeigen und Bearbeiten von Elementeigenschaften wird die generische Properties-Ansicht von Eclipse verwendet. Kontextmenüs bieten an verschiedenen Stellen spezielle Aktionen, beispielsweise das Anlegen von Anomalien, an.
Vor der Erstellung eines Reviews muss eine Reviewgruppe angelegt werden. Anschließend wird ein Review mit Workflow definiert. Dabei wird zwischen Basis-, informellen und IEEE-1028-konformen, formellen Reviews unterschieden. Diese Workflows werden ausführlich im R4E-Benutzerhandbuch beschrieben und unterscheiden sich hauptsächlich in den formalen Anforderungen an die Definition von Reviewphasen, der Rollenverteilung der Reviewteilnehmer oder im Zustand der gefundenen Anomalien. Für den Einstieg ist ein Basisreview gut geeignet.
Nach dem Erstellen eines Reviews kann für eine beliebige Ressource eine so genannte Anomalie erfasst werden (Abb. 3). Auch in R4E wird zwischen globalen und auf eine Selektion bezogene Anomalien unterschieden. Die Position der Anomalie im Quellcode wird separat in einer XML-Datei hinterlegt, sodass der eigentliche Quellcode unverändert bleibt. Diese Metadaten können ebenfalls in einem Versionskontrollsystem abgelegt werden.

Abb. 3: Erfassung einer Anomalie mit Review for Eclipse

Neben dieser grundlegenden Reviewfunktionalität bietet R4E tiefergehende Funktionen an. So gibt es sowohl eine LDAP-Anbindung, um Benutzerdaten zentral zu verwalten, als auch SMTP-Unterstützung zum Versenden von Benachrichtigungen per E-Mail. Versionskontrollsysteme können integriert werden (momentan Git und Subversion), hierdurch können die Änderungen (Commits) einem Review unterzogen werden. Für informelle und formelle Reviews können Regeln definiert werden, die reviewübergreifend verwendet werden können. Zur Auswertung eines Reviews kann ein Bericht erzeugt werden, der Informationen über das Review und den damit verbundenen Aufwand enthält.

Fazit

Sowohl Agile Review als auch Review for Eclipse sind für Codereviews gut geeignet. Beide Tools haben jedoch ihren eigenen Schwerpunkt. Agile Review konzentriert sich auf die Grundfunktionen und bietet eine übersichtliche Benutzeroberfläche. Statt einfacher Kommentare im Quellcode wird eine Referenz abgespeichert, die einen Status und eine Priorität besitzt. Für viele Anwendungsfälle ist dies ausreichend. Die Einarbeitung ist in kurzer Zeit erledigt und die pragmatischen Ansätze der Entwickler, wie die Speicherung der Kommentare in einem eigenen Eclipse-Projekt, sind sinnvoll und einfach.
Einen ganz anderen Ansatz haben die Entwickler von Review for Eclipse gewählt. Auch hier sind zwar „Basisreviews“ vorgesehen. Seine ganzen Möglichkeiten offenbart R4E allerdings erst bei informellen und formellen Reviews. Leider ist die Benutzeroberfläche diesen Möglichkeiten nicht gewachsen. Häufig muss zwischen dem Review Navigator und dem Properties-Editor gewechselt werden. Insgesamt würde dieses Plug-in durch eine eigene, aufgeräumte Perspektive und Konfigurations-Wizards übersichtlicher werden. Das Benutzerhandbuch ist umfangreich und muss oft konsultiert werden.
Einen grundsätzlichen Designunterschied gibt es zwischen Agile Review und R4E bezüglich der Verbindung der Kommentare bzw. Anomalien und dem betreffenden Quellcodeabschnitt. Aus dem Quellcode die Metadaten zu referenzieren bietet den Vorteil, dass bei Refactorings die Referenz erhalten bleibt, aber dafür der Quellcode mit zusätzlichen, nicht unmittelbar verständlichen Kommentaren erweitert wird. Dies umgeht Review for Eclipse und speichert die Referenzen auf den Quellcode in den Metadaten. Insbesondere bei großen Projekten und Komponenten, die von mehreren Teams in unterschiedlichen Reviews begutachtet werden, ist das sicherlich sinnvoll.
Unabhängig davon, welches der beiden Tools gewählt wird, auf die Vorteile von Codereviews sollte kein Entwicklungsteam verzichten. Die positiven Auswirkungen auf die Qualität und der Wissenstransfer sind gute Gründe für den Einsatz von Reviews. Der zeitliche Aufwand kann verringert werden, wenn in den Reviews überschaubare Quellcodeabschnitte betrachtet werden. Dies erfordert eine regelmäßige und häufige Durchführung von Codereviews. Nach einer gewissen Eingewöhnungszeit ist das Team eingespielt und die Reviews gehören zum täglichen Ablauf dazu.

Geschrieben von
Simon Olofsson
Simon Olofsson
Simon Olofsson, Senior Developer bei der Content Management AG, entwickelt seit mehreren Jahren verteilte Systeme mit Java-EE- und Webtechnologien. Er interessiert sich dabei insbesondere für den Einsatz von modernen Programmiersprachen und -methoden.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.