17 February 20267 Min. Lesezeit
In einer verteilten Zusammenarbeit ist Code Review kein Qualitätstor, das nach der Steuerung kommt. Es ist die Steuerung. Dort werden Standards vermittelt, dort tauchen Missverständnisse auf, solange sie noch günstig sind, und dort erfahren Sie, ob die Person, die Sie eingestellt haben, die Arbeit tatsächlich leisten kann.
Deshalb lohnt es sich, das als gestalteten Prozess zu behandeln und nicht als etwas, das passiert, wenn die Leute dazu kommen. Der meiste Reibungsverlust, der als „das ausgelagerte Team ist langsam“ beschrieben wird, entpuppt sich bei genauerem Hinsehen als Warteschlange, die die eigenen Entwickler des Auftraggebers nicht abarbeiten.
Das Problem ist die Warteschlange, nicht die prüfende Person
Arbeit, die im Review liegt, ist Arbeit, die fertig ist und nichts liefert. Schlimmer noch: Die Autorin ist längst bei etwas anderem, muss also, wenn das Review irgendwann kommt, den gesamten Kontext neu laden. Eine Änderung, die binnen weniger Stunden geprüft wird, kostet die Autorin fünf Minuten. Dieselbe Änderung, vier Tage später geprüft, kostet eine Stunde, und die zweite Änderung, die darauf aufbaut, braucht jetzt ein Rebase.
Messen Sie die Wartezeit, nicht die Zahl der Kommentare. Wenn Sie zum Review eine Sache verfolgen, dann, wie lange ein Pull Request liegt, bevor ein Mensch hineinsieht. Diese Zahl ist das ehrliche Maß dafür, wie gut die Zusammenarbeit geführt wird, und fast immer ist es die Kundenseite, die sie verschlechtert.
Hier zahlt sich der gemeinsame Arbeitstag aus. Wenn Ihre prüfenden Personen und die Autorin den größten Teil des Tages gleichzeitig wach sind, ist ein Review am selben Tag eine normale Erwartung und kein Anspruch. Über einen Abstand von acht oder neun Stunden ist es strukturell unmöglich, und alles Obige summiert sich.
Kleine Pull Requests sind ein Führungsinstrument
Eine Änderung über vierhundert Zeilen bekommt ein Review, das „sieht gut aus“ sagt. Eine Änderung über vierzig Zeilen bekommt ein Review, das den Fehler findet. Das ist keine Frage der Sorgfalt, sondern dessen, was ein Mensch im Kopf behalten kann.
Bei jemandem, der neu ist, oder auf Distanz arbeitet, oder beides, leisten kleine Änderungen noch etwas anderes: Sie verkürzen die Rückkopplung auf die Richtung. Ist der Ansatz falsch, merken Sie es nach einem halben Tag statt nach einer Woche Arbeit, die nun verworfen werden muss, samt dem guten Willen dessen, der sie geschrieben hat.
Die praktische Anweisung lautet, eine Obergrenze zu vereinbaren und ihr Überschreiten als etwas zu behandeln, das einer Begründung bedarf. Generierter Code, mechanische Umbenennungen und Abhängigkeits-Updates sind die offensichtlichen Ausnahmen und gehören ohnehin in eigene Änderungen, genau damit sie keine echte Bearbeitung verstecken.
Was zu kommentieren ist und was Sie in Ruhe lassen sollten
Das schädlichste Review-Muster bei einer neuen externen Person ist das, in dem jeder Kommentar dasselbe Gewicht trägt. Zwanzig Anmerkungen treffen ein, drei davon sind Korrektheitsprobleme und siebzehn sind Vorlieben, und die Autorin kann nicht unterscheiden, was was ist. Sie behebt alle zwanzig, lernt nichts über Ihre Prioritäten und wird langsamer.
Benennen Sie den Unterschied ausdrücklich. Ein blockierender Kommentar sagt, was falsch ist und warum es zählt. Eine Vorliebe sagt, dass sie eine Vorliebe ist und ignoriert werden kann. Teams, die diese Konvention übernehmen, stellen fest, dass ihre Review-Gespräche binnen zwei Wochen kürzer werden.
- Blockierend: Es ist falsch, es ist unsicher, es bricht eine Schnittstelle, auf die sich jemand verlässt, oder es verletzt die Definition of Done.
- Diskussionswürdig: Der Ansatz funktioniert, aber es gibt einen Grund, einen anderen vorzuziehen, und dieser Grund wird erklärt statt behauptet.
- Vorliebe: Benennung, Reihenfolge, Struktur, die Ihnen zufällig gefällt. Sagen Sie das, und lassen Sie den Autor ablehnen.
- Gar kein Review: alles, worüber ein Formatter oder ein Linter entscheiden kann. Steht es in einem Review-Kommentar, fehlt Ihnen Werkzeug.
Review in beide Richtungen
Eine Konstellation, in der die Entwickler des Kunden die Arbeit des ausgelagerten Teams prüfen und nie umgekehrt, schafft eine Hierarchie, der niemand zugestimmt hat. Sie verschenkt außerdem die nützlichste Perspektive, die Ihnen zur Verfügung steht: jemanden, der andere Systeme gesehen hat und noch nicht gelernt hat, Ihres hinzunehmen.
Lassen Sie externe Beitragende auch interne Änderungen reviewen, zumindest in den Bereichen, in denen sie arbeiten. Es legt die Annahmen offen, die Ihr Team nicht mehr bemerkt, es macht den Standard beidseitig statt auferlegt, und es ist der schnellste Weg herauszufinden, wie gut jemand das System tatsächlich versteht, was ein viel besseres Signal ist als jedes Interview.
Automatisieren Sie alles, was kein Urteil erfordert
Formatierung, Reihenfolge der Imports, Lint-Regeln, Typprüfung, Testläufe, Abdeckungsschwellen, falls Sie sie nutzen: All das sollte in der CI fehlschlagen und nicht in einem Kommentar, den nachts um elf ein Mensch schreibt. Jeder dieser Punkte, den ein Mensch anspricht, ist eine kleine Steuer auf die Beziehung, und sie wird überproportional von der neuesten Person gezahlt.
Der Gewinn ist nicht nur Tempo. Sobald die mechanischen Beanstandungen weg sind, sind die verbleibenden Kommentare durchweg inhaltlich, und ein Review voller Inhalt liest sich als Beteiligung statt als Türsteherei.
Wenn das Review zu einem Engpass wird, den Sie selbst gebaut haben
Auf zwei Symptome sollten Sie achten. Das erste ist eine einzige prüfende Person, durch die alles läuft, meist diejenige, die das System am besten kennt und am wenigsten Zeit hat. Diese Anordnung fühlt sich sicher an und ist ein einzelner Ausfallpunkt, der schlimmer wird, je größer die Zusammenarbeit wird.
Das zweite ist die stille Freigabe. Reviews, die durchgehend binnen Minuten und ohne Kommentare eintreffen, sind kein Zeichen für exzellenten Code. Sie sind ein Zeichen dafür, dass jemand aufgehört hat zu lesen, meist weil die Warteschlange so lang wurde, dass ihr Abarbeiten zum Ziel wurde. An diesem Punkt hat Review aufgehört, Führung zu sein, und ist Papierkram geworden, und die Fehler, die es abfing, erreichen jetzt die Produktion.
Beides wird auf dieselbe Weise behoben: mehr als eine Person, die jeden Bereich reviewen kann, und eine Warteschlange, die kurz genug ist, um wirklich lesen zu können. Wenn Ihnen das Zweite nicht gelingt, haben Sie mehr Lieferung übernommen, als Sie steuern können, und das ist ein Skalierungs- und kein Review-Problem.