Die SDX entwickelt derzeit mit einem Scrum-Team an einer intern genutzten Software. Als ALM-Tool wird dabei der Team Foundation Server 2012 (TFS 2012) eingesetzt, da er viele projektunterstützende Hilfsmittel bietet und sich direkt in die IDE integriert. Eine der vom Team genutzten Neuerungen im TFS 2012 sind die IDE integrierten Codereviews, deren Adaption im Scrum-Team ich in diesem Blogbeitrag darlegen möchte.
TFS 2012 Codereviews bieten die Möglichkeit auf Changeset- oder Shelveset-Basis vorgenommene Änderungen zu prüfen und gesamt, zeilen- oder blockweise zu kommentieren. Ein Codereview kann für ein Change- oder Shelveset angefragt werden, oder direkt aus der aktuellen Arbeit („My Work“) erzeugt werden. Ziel ist es, Problemen und Fehlern frühzeitig entgegenzuwirken und die Codequalität zu erhöhen. Da Codereviews allgemein dem agilen Vorgehen (wie Scrum) nicht fremd sind, wurde im Team beschlossen, die TFS 2012 Codereviews in die „Definition of Done“ aufzunehmen. Das bedeutet, dass ein Product Backlog Item (PBI) erst als Done (Abgeschlossen) deklariert werden darf, wenn für alle mit diesem assoziierten Änderungen ein Codereview mit positivem Ergebnis durchgeführt wurde. Bei der Adaption dieses Vorgehens ist das Team jedoch auf verschiedene Hürden gestoßen.
Codeabdeckung von Reviews
Aus der derzeitigen Implementierung der IDE-gestützten Codereviews ergibt sich ein Problem mit der Forderung nach kontinuierlicher Integration: Code soll während der Entwicklung stets in den Gesamtquelltext integriert werden und lauffähig sein. Durch die im Verlauf der Arbeit vorgenommenen Änderungen können daher für ein Workitem mehrere Changesets entstehen. Da ein TFS Codereview derzeit aber lediglich auf ein einziges Shelveset oder Changeset bezogen werden kann, müssen ggf. mehrere Reviews angefordert werden, um ein komplettes Workitem abzudecken.
Durch erneute Überarbeitungen im Rahmen desselben Workitems können Changesets teilweise oder vollständig hinfällig sein. Folglich ist das zuvor angedeutete Vorgehen in diesem Fall nur unter hohem Aufwand anwendbar, da nicht alle Changesets vollständig betrachtet werden müssten. Meiner Meinung nach besteht das Problem also darin, dass im TFS derzeit leider keine Möglichkeit vorliegt, Changesets miteinander zu kombinieren. Eine Kombination von Changesets wäre jedoch erforderlich, damit deren zusammengefasste Änderungen mit einem Review geprüft werden können. Dabei wäre allerdings zu berücksichtigen, dass auch Überarbeitungen im Rahmen anderer Workitems, die Changesets des zu betrachtenden Workitems teilweise oder vollständig hinfällig machen können. Ein Review das ausschließlich ein Workitem umfasst, wäre somit nicht möglich. Voraussetzung dafür ist, dass die Workitems unabhängig voneinander sind. Alternativ muss der Kontext des Reviews erweitert werden, wodurch sich wiederum dessen Aufwand erhöht.
Vor dem geschilderten Hintergrund können TFS Codereviews leider nur sehr punktuell verwendet werden. Und so muss, um einen größeren Kontext (über mehrere Changesets) mit einem Review zu prüfen, nach wie vor eine Durchführung ohne die TFS Codereviews als technisches Hilfsmittel stattfinden. Im Scrum-Team der SDX wird dennoch versucht die umfassende Prüfung eines Workitems nach dem zuvor genannten Verfahren zu ermöglichen. Dazu werden Workitems möglichst unabhängig voneinander gehalten, damit es nicht zu Konflikten kommt. Zudem werden Aufgaben möglichst feinkörnig aufgeteilt, um Workitems klein zu halten, damit für diese nicht zu viele Changesets entstehen.
Laufzeit eines Reviews
Auch aus der Laufzeit eines Reviews ergibt sich ein Konflikt mit der Praktik der kontinuierlichen Integration. Sobald ein Review angefragt wird, vergeht Zeit bis zu dessen Abschluss. Das daraus entstehende Problem möchte ich anhand eines Beispiels veranschaulichen: Wird etwa ein Review auf Basis eines Shelvesets angefragt, kann es bereits im Zeitraum vor seiner Bearbeitung hinfällig werden. Dies ist dann der Fall, wenn vor der Bearbeitung des Reviews Änderungen vorgenommen wurden, durch die das Shelveset inkompatibel geworden ist. Aber auch während oder nach der Bearbeitung eines Reviews können im Rahmen anderer Aufgaben vorgenommene Änderungen das Ergebnis des Reviews ungültig machen. Dies wird insbesondere im Fall eines Shelvesets deutlich, wenn dessen Integration nach einem Review aufgrund von Inkompatibilität nicht mehr möglich ist. Unabhängig davon ist bei Änderungen die Gültigkeit des Reviews zu hinterfragen, weil Änderungen den Kontext des im Review betrachteten Codes verändern können.
Um solche überflüssigen Reviews zu vermeiden, muss sich das Team untereinander abstimmen und klären, ob und wo während des Reviews weiterhin am Code gearbeitet werden darf. Macht es Sinn, weiterhin am gleichen Workitem zu arbeiten, bevor das Review abgeschlossen ist? Wie wird damit umgegangen, wenn im Rahmen eines anderen Workitems (u.U. von einem anderen Entwickler) an derselben Codestelle gearbeitet wird? Zwar wird mit einem Changeset immer nur ein spezifischer Codestand betrachtet, und auch Shelvesets können ggf. automatisch wieder integriert werden, doch sind die Auswirkungen von Änderungen auf das Ergebnis eines Reviews nach wie vor nicht absehbar. Deshalb empfehle ich, Änderungen während eines Reviews auszuschließen.
Im Scrum-Team der SDX wurde diesem Problem wiederum dadurch entgegen gewirkt, dass Workitems möglichst unabhängig voneinander sind. Ferner wurde ein gemeinsames Verständnis dafür geschaffen, dass Änderungen während eines Reviews zu vermeiden sind. Außerdem werden bevorzugt Reviews auf Changesets angefragt, sofern das Risiko eine direkte Integration zulässt, damit Inkompatibilität eines Shelvesets vermieden wird. Einen anderen wichtigen Punkt zur Vermeidung ungültiger Reviews stellt aber auch deren zeitnahe Bearbeitung dar. Folglich gelten Reviews als hochpriorisiert und sollten möglichst am selben Tag bearbeitet werden. Der TFS 2012 bietet dafür unterstützend E-Mail-Notifikationen für den/die Reviewer, dass eine neue Review-Anfrage vorliegt. Diese kommen im Scrum-Team der SDX zum Einsatz, und tragen auch dazu bei, dass es nicht zu unnötigen Verzögerungen kommt.
Fazit
TFS Codereviews bedürfen in Kombination mit kontinuierlicher Integration organisatorischer Maßnahmen, um effizient zu sein. Dazu wäre insbesondere die Funktion „Codereview für ein Workitem“ wünschenswert. Diese könnte ferner auch auf ein PBI oder den Gesamtquelltext übertragen werden. Alles in allem werden die Reviews vom Team aber als sehr praktisches Hilfsmittel wahrgenommen und nach wie vor eingesetzt.
Abseits von der Team-Organisation und dem technischen Hilfsmittel wurde dabei festgestellt, dass häufige Reviews einen nicht zu unterschätzenden zusätzlichen Aufwand darstellen. Darum wurde im Team entschieden, nicht alle Änderungen zu prüfen, sondern nur kritische oder nichttriviale Änderungen nach eigenem Ermessen explizit prüfen zu lassen. Dies ermöglicht zudem die gemeinsame Durchführung eines Reviews, bei der der Entwickler und der Prüfer des Codes den Code gemeinsam betrachten und sich gegenseitig direktes Feedback geben können. Die TFS Codereviews können dabei unter anderem zum temporären Festhalten besprochenen Änderungsbedarfs verwendet werden.