Code-Review kann besser werden

• Viele Entwickler sind mit der Code-Review-Erfahrung auf GitHub unzufrieden und probieren neue Ansätze aus, um sie zu verbessern
• Das experimentelle Tool git-review wurde so entworfen, dass Code-Reviews nicht über eine Browser-Weboberfläche, sondern direkt lokal zusammen mit dem Code bearbeitet werden
• Reviews werden als einzelner Commit verwaltet; Review-Kommentare werden wie Kommentare im Code hinterlassen, und Reviewer und Autor überarbeiten diesen Commit gemeinsam
• Wenn der Code während des Reviews geändert oder rebased wird, entstehen jedoch Unannehmlichkeiten bei der Konfliktbehandlung und beim Einsatz von --force-with-lease, sodass der Ansatz keinen großen Erfolg hatte
• Am Ende kehrte man wieder zu webbasierten Reviews zurück, doch die Idee, den Review-Status direkt im Git-Repository zu speichern, bleibt attraktiv, und zusammen mit künftigen Git-Verbesserungen wie der Einführung einer Gerrit-artigen Change-Id könnte eine bessere Alternative entstehen

---

Problembewusstsein bei Code-Review-Systemen

• Derzeit sind viele Menschen mit dem Code-Review-Prozess auf GitHub unzufrieden
• Die Hauptprobleme sind fehlende Unterstützung für gestapelte Pull Requests und Interdiff-Reviews sowie außerdem:
  • Der Review-Status wird nicht im Repository gespeichert
  • Reviews über eine Remote-first-Weboberfläche sind zwingend erforderlich
• Mein Problem liegt im Mangel an Dezentralisierung beim Review und in der Ineffizienz der Benutzeroberfläche

Vergleich von Workflows für Code-Erstellung und Review

• Beim Schreiben von Code verwenden Menschen lokal einen Editor
  • Die Umgebung hat geringe Speicher- und NVMe-Latenzen und ist auf den individuellen Workflow des Nutzers optimiert
• Auch für Code-Reviews wird bevorzugt, den Source-Branch lokal zu pullen und dort zu arbeiten
  • Mit Tools wie Magit lässt sich nicht nur der Diff, sondern auch der gesamte Code-Kontext erkunden
  • Man kann eine leistungsfähige Entwicklungsumgebung nutzen, etwa zum Ausführen von Tests, zum Springen zur Code-Definition oder zum Ausprobieren von Refactorings
• Um dagegen Feedback in einem PR zu hinterlassen, muss man in den Browser und zu einer langsamen Weboberfläche wechseln; bei großen Diffs kommt es zudem zu deutlichen Eingabeverzögerungen

Ideale Code-Review-Oberfläche und Speicherstruktur

• Am natürlichsten ist es in der Praxis, Kommentare direkt inline im Code zu hinterlassen oder den Code direkt zu ändern

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Dadurch, dass Daten in einer entfernten DB statt im lokalen Git-Repository gespeichert werden, entstehen zusätzlich Probleme mit Latenz und Vendor Lock-in

Die Idee von git-review und die Erfahrungen in der Praxis

• Die Idee von git-review ist wie folgt:
  • Das Code-Review besteht aus einem einzelnen Commit an der Spitze des PR-Branches
  • Diesem Commit werden Code-Kommentare mit speziellen Markern hinzugefügt
  • Reviewer und Autor bearbeiten diesen Commit abwechselnd, wobei die Zusammenarbeit auf push --force-with-lease basiert
  • Wenn alle Kommentare als gelöst markiert (//? resolved) sind, bleibt beim Abschluss des Reviews durch einen Revert-Commit ein Verlauf erhalten
• Die Idee ist einfach und praktisch, in der Realität traten jedoch folgende Probleme auf:
  • Bei Code-Änderungen während des Reviews kommt es häufig zu Konflikten zwischen Kommentaren und nachgelagerten oder neuen Commits
  • Der Force-Push führt zu Reibung in der Zusammenarbeit und erhöht die Komplexität der Arbeit
  • Die Diskrepanz zwischen Code-Änderungshistorie und Review-Fortschritt sowie die Verwaltung von Merge-Konflikten werden schwierig

Neue Veränderungen und künftige Möglichkeiten

• Künftig könnte eine Gerrit-artige Change-Id in Git upstream eingeführt werden
  • Dadurch ließe sich der Änderungsverlauf pro Commit leichter nachverfolgen, und die Unterstützung für Interdiff-Reviews dürfte zunehmen
  • Allerdings sind teilweise Konflikte mit dem Ansatz von git-review zu erwarten
  • Mit einer neuen Change-Id-Struktur könnten auch ungewöhnliche Ansätze möglich werden, etwa Review-Kommentare direkt zum Commit selbst hinzuzufügen

Fazit und empfehlenswerte Systeme als Referenz

• Letztlich ist man derzeit wieder bei weboberflächenbasierten Code-Reviews gelandet
• Der Bedarf an einer besseren Lösung besteht weiterhin
• Vorstellung verwandter Systeme und Tools, die einen Blick wert sind
  • Fossil: Ein SCM-System, das alle Informationen im Repository selbst speichert
  • NoteDb: Integriert den Verlauf des gespeicherten Review-Status von Gerrit in Git
  • git-bug: Speichert Issue-Informationen in Git
  • git-appraise: Bewahrt Review-Informationen in Git selbst auf
  • prr: Implementiert eine Review-Oberfläche im Editor in Verbindung mit der GitHub API
  • How Jane Street Does Code Review: Vorstellung eines Beispiels aus der Praxis, wie es besser gehen kann
  • git-pr: Ein Projekt, das den gesamten PR-Workflow durch native Git-Funktionen ersetzt

Abschluss

• Eine perfekte Lösung gibt es noch nicht, und die Suche nach einer besseren Developer Experience geht weiter
• Die Erwartungen an die zukünftige Entwicklung sind hoch