Kontinuierliche Code-Reviews mit Subversion und Eclipse

Inhaltsverzeichnis

Code-Reviews dienen der Qualitätssicherung in Softwareprojekten. Traditionelle Review-Methoden bedürfen jedoch eines nicht unbeträchtlichen Aufwands an Zeit und Ressourcen für die Planung und Durchführung der einzelnen Prüfphasen. Das an der Technischen Universität Wien entwickelte ReviewClipse-Werkzeug verwendet Change Sets des Versionierungssystems zur Planung und Durchführung von Reviews und hält dadurch die Aufwendungen gering.

Code-Reviews gehören zu den analytischen Maßnahmen im Qualitätsmanagement und helfen, Fehler in Produkten frühzeitig zu finden. Eine Review bezeichnet allgemein die Überprüfung eines Ergebnisses durch einen oder mehrere unabhängige Personen. Reviews lassen sich nicht nur für die Quellcode-Überprüfung verwenden, sondern auch für Arbeitsprodukte wie Anforderungsdokumente, Qualitätssicherungsprozesse und Prototypen einsetzen. Ihr Vorteil ist, dass sie früh, noch vor der Fertigstellung des Produkts, durchzuführen sind. Dadurch verringert sich die Fehlerlatenzzeit, die Zeit zwischen Fehlerentstehung und -entdeckung. Findet man Bugs erst in einer späten Phase des Softwarentwicklungsprozesses, entstehen höhere Kosten für ihre Behebung, da einzelne Arbeitsschritte erneut durchzuführen sind (Einplanung, Bugfixing, Test, Produktauslieferung). Außerdem können durch nicht behobene Fehler in einem frühen Meilenstein Folgefehler in den folgenden Phasen entstehen (siehe Abbildung 1). Mit Reviews findet man Bugs in der jeweiligen Phase, und Reviewer tragen daher dazu bei, Fehleransammlungen von vornherein zu verhindern.

Defizite beim Einsatz von Code-Reviews

Es existieren viele Berichte [1] von Softwareunternehmen, die die Kosteneinsparung bei gleichzeitiger Qualitätssteigerung durch Code-Reviews zeigen. Letztere tragen dazu bei, das implizite Wissen des Entwicklers über den Quellcode auf mehrere Personen zu verteilen. Der Prüfer lernt den Programmcode kennen und kann die Fähigkeiten des Entwicklers besser einschätzen. Nicht zuletzt haben die Reviews für den Prüfer einen positiven Lerneffekt, er kann seine eigenen Fähigkeiten durch das Lesen von fremdem Quellcode verbessern.

Trotz der klaren Vorteile zeigen Umfragen [2][3], dass Code-Prüfungen oft nicht in der beabsichtigten Weise durchgeführt werden. Der Hauptgrund ist die fehlende Planung von Zeit und Ressourcen für das Durchführen der Reviews. Sieht man nicht in der Planungsphase des Projekts ausreichend Zeit für das Einhalten der Reviews vor, kommt es zu Engpässen beim Durchführen der Prüfungen. Das hat zur Folge, sie nur mehr sporadisch durchzuführen und wichtige Phasen des Review-Prozesses wegzulassen. Eine geringere Fehlerfindungsrate und somit eine verminderte Effizienz des Prozesses sind die Folge.

Auch neuere Trends der Softwareentwicklung lassen sich nicht immer mit dem traditionellen Ansatz der Code-Reviews vereinbaren. Objektorientierte Sprachen delokalisieren durch Vererbung und dynamisches Binden den Code – Anweisungen rufen andere Klassen oder Programmbibliotheken auf. Damit wird es für den Prüfer schwierig, die semantische Korrektheit zu überprüfen, ohne den Fremdcode der Anweisung zu kennen. Ein weiteres Problem ist, dass Softwareteams oft verteilt arbeiten: Die Entwickler und Prüfer befinden sich an unterschiedlichen Standorten, oftmals in unterschiedlichen Zeitzonen. Review-Meetings durchzuführen mag daher schwierig sein.

Change Sets zur Festlegung des Review-Umfangs

Der vorgestellte Ansatz zum Durchführen von Code-Reviews integriert das Versionierungssystem Subversion in den Review-Prozess. Solche Systeme nehmen in der kollaborativen Softwareentwicklung eine zentrale Rolle ein, da eine manuelle Versionierung von Quellcode durch den Umfang nicht mehr möglich wäre. Übermittelt der Entwickler Quellcode-Änderungen an das System, erzeugt er damit eine neue Revision. Sie bezeichnet den Zeitpunkt, zu dem sich die Dateien in einem bestimmten Zustand befunden haben. Die Änderungen, die zu ihr führten, nennt man Change Set. Darunter versteht man die Modifikationen der Revision n zur Revision n+1. Während die Bezeichnungen Revision und Change Set variieren, ist das Konzept in allen neueren Versionierungssystemen, etwa Mercurial und Git, anzutreffen.

Die Änderungen innerhalb eines Change Set sind voneinander stark abhängig: Der Entwickler implementiert eine Funktion oder behebt einen Fehler und übermittelt daraufhin die Änderungen an das Versionierungssystem. Die Änderungen sind womöglich über den Quellcode verstreut, dienen aber dazu, einen einzelnen Task zu implementieren. Für den Prüfer ergibt sich dadurch ein neues Mittel, den Quellcode zu inspizieren: Statt eine Klasse zu einem bestimmten Zeitpunkt zu überprüfen, lassen sich nun die Änderungen validieren, die zu diesem Zustand geführt haben. Die Änderungen im Quellcode sind durch den Prüfer einfacher zu verstehen, da sie helfen, eine einzelne Aufgabe zu erledigen, und daher besser nachzuvollziehen sind. Außerdem sind durch die Code-Änderungen im Change Set die Abhängigkeiten im Quellcode besser ersichtlich. Verfolgt nun ein Prüfer kontinuierlich über einen längeren Zeitraum die Änderungen eines Entwicklers, lernt er den Quellcode des Autors kennen – sogenannter kollektiver Code-Besitz entsteht. Damit wissen die Entwickler über den Quellcode der Kollegen Bescheid und können Änderungen an ihm einfacher durchführen.