Code-Reviews erfordern Lesen

• Code-Reviews sind kein formaler Prozess vor dem Deployment, sondern ein Vorgang, der die Verantwortung für Ausfälle, Sicherheitsprobleme und Datenlöschungen von einer einzelnen Person auf Teamverantwortung verlagert
• Bessere Evals, Tests, Feature-Flags, Guardrails und Observability können Antworten sein, um die Unsicherheit beim Deployment ungelesenen Codes zu verringern, werden hier aber dafür kritisiert, am Ziel der Verantwortungsverteilung von Reviews vorbeizugehen
• Die Forderung, ohne Lesen zu genehmigen, sei so, als würde man Menschen dazu bringen, gedankenlos einen Button zu drücken; daraus entsteht die satirische Idee der Button Roulette, bei der ein zufälliger PR mit komplett grünem CI gemergt wird
• Code-Reviews sorgen dafür, dass Teammitglieder verschiedene Teile einer großen Codebase sehen, senken so den Bus-Faktor und dienen neuen Teammitgliedern als Lerninstrument für Code und Code-Kultur
• Wer verlangt, ungelesenen Code in Produktion zu deployen, müsse eine schriftliche Haftungsfreistellung für Bugs, Sicherheitsprobleme, Downtime usw. geben; genau daran scheitere es meist, so das Fazit

---

Der Zweck von Reviews ist Verantwortungsverteilung, nicht Genehmigung

• Ausgangspunkt ist die Frage aus Charity Majors’ Artikel “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy”: „Was wäre nötig, damit man sich wohlfühlt, ungelesenen Code in die Produktion zu deployen?“
• Antworten wie bessere Evals, Tests, Feature-Flags, Guardrails, Observability, Entkopplung von Abhängigkeiten, Verkleinerung des Blast Radius oder der Einstieg mit kleinen Änderungen außerhalb kritischer Pfade werden als Antworten behandelt, die am Kern von Reviews vorbeigehen
• Der Zweck von Reviews besteht darin, die Last für Ausfälle, Sicherheitsprobleme und versehentliche Datenlöschungen nicht bei einer einzelnen Person zu belassen, sondern sie als Teamverantwortung auf Autor und Reviewer zu verteilen
• Wenn man „ohne Lesen genehmigen“ verlange, gebe es kaum noch einen Grund, Menschen überhaupt noch manuell Buttons drücken zu lassen; daraus entsteht die Satire button roulette, bei der einer der zugewiesenen PRs mit komplett grünem CI zufällig gemergt wird

Was beim ungelesenen Review verloren geht

• Code-Reviews zwingen Teammitglieder dazu, andere Teile der Codebase zu sehen, und gleichen so die Grenze aus, dass in zu großen Systemen niemand dauerhaft alle Teile kennen kann
• Der Review-Prozess senkt den Bus-Faktor und hilft mehreren Mitgliedern des Teams, sich stärker mit Codebase und Code-Kultur vertraut zu machen
• Wenn alle nur noch ungelesen genehmigen, geht dieser Lerneffekt verloren; zudem steigt der Bus-Faktor auf 1 und es entsteht zusätzlich das Problem der Auslagerung an Dritte
• Akzeptieren ließe sich die Forderung, ungelesenen Code in die Produktion zu deployen, nur dann, wenn die Person, die diese Anweisung gibt, eine schriftliche Haftungsfreistellung für Bugs, Sicherheitsprobleme, Downtime usw. bereitstellt

[GN⁺]

Lobste.rs-Meinungen

• Ich habe eine starke Abneigung gegen die Behauptung, der Zweck von Reviews sei die Verteilung von Verantwortung
  Wenn in main gemergter Code die Produktion kaputtmacht, dann ist das die Verantwortung des Autors, nicht meine oder die des gesamten Teams
  Es ist Arbeit mit der eigenen Unterschrift als Fachkraft, und wenn ein Brückenentwurf mit dem Stempel eines Bauingenieurs mit P.E.-Lizenz Menschen tötet, dann ist auch das dessen eigene Arbeit und Verantwortung
  Die Verantwortung des Teams liegt als Entwickler und Verwalter der Codebasis darin, zu verhindern, dass irgendjemandes Code die Produktion kaputtmachen kann

  • Ich halte die Denkweise, dass in main gemergter Code, der die Produktion kaputtmacht, reine Einzelverantwortung sei, nicht für eine gesunde Kultur
    Ein Merge nach main bedeutet, dass jemand ihn reviewt, die Änderungen geprüft, das Design diskutiert, mehrfach überarbeitet und dann genehmigt hat
    Niemand baut den Eiffelturm allein, und wenn man im Arbeitsumfeld Einzelpersonen die Schuld zuschiebt, erzeugt das nur Groll und eine toxische Kultur
    Wenn es ein wiederkehrendes Verhaltensmuster ist, dann ist das ein Thema für HR
  • Wenn Reviewer überhaupt keine Verantwortung tragen, ist das dasselbe wie gar kein Review
    Wenn die Verantwortung 0 ist, sind Reviewer nutzlos, und es gibt keinen Grund, überhaupt Reviews zu machen
    Die Verteilung von Verantwortung ist eher ein Ergebnis; der eigentliche Zweck ist, Fehler zu finden, die man allein leicht übersieht, zu zweit oder mit mehr Personen aber schwerer verpasst
    Allerdings werden Reviews in der Softwareentwicklung übermäßig eingesetzt, und ich glaube nicht, dass Reviews ein Ersatz für Engineering sein können

• Ich halte es nicht für präzise, „freigeben, ohne den Code zu lesen“ mit „gedankenlos freigeben“ gleichzusetzen
  Was wäre zum Beispiel, wenn an einem Programm ein Korrektheitsbeweis hängt, man im PR Definitionen und Theoreme lesen kann, CI mit deterministischen Werkzeugen prüft, dass Programm und Beweis zusammenpassen, auch nichtfunktionale Anforderungen wie Kontrastverhältnis, Performance-Benchmarks und Tail-Latenz testet und sich UI-Änderungen über einen Prototyp leicht ausprobieren lassen?
  Selbst in so einer Welt ist fraglich, ob man weiterhin so besessen davon sein müsste, den Code Zeile für Zeile zu lesen wie heute
  Schon heute überprüft beim Schreiben von SQL kaum jemand jedes Mal im Detail, ob der Query-Plan exakt dem Gewünschten entspricht
  Der Originalbeitrag liest sich für mich eher wie: „Lasst uns eine ideale Welt definieren, in der man das Gefühl haben kann, auch ohne den Code buchstäblich zu lesen deployen zu dürfen“, und dann: „Wie können wir uns sanft von der Gegenwart in diese Welt bewegen?“
  Man kann darüber streiten, wie weit die Branche oder ein bestimmtes Unternehmen bzw. eine bestimmte Codebasis von diesem Punkt entfernt ist, aber wenn man sich diese ideale Welt ernsthaft vorstellt, fallen den meisten vermutlich einige Kriterien dafür ein
  Ich verstehe, dass man es wegen der aktuellen Branchenstimmung als „gedankenlos“ auffasst, aber ich glaube nicht, dass Charitys Text genau das meint

  • Der Kern des Originalbeitrags ist nicht, Probleme im PR zu finden, sondern mit der Codebasis vertraut zu werden und Verantwortungsbewusstsein zu schaffen
    Das ist nur möglich, wenn man den Code liest, egal wie gut die Tests sind
    Wenn Alice Code einbringt, Bob ihn reviewt und Alice dann in Urlaub geht, sollte Bob diesen Teil gut genug kennen und sich ausreichend verantwortlich fühlen, um ihn zu ändern oder neue Features hinzuzufügen
    Wenn Bob nur den Korrektheitsbeweis abstempelt, ist er später nicht darauf vorbereitet, mit dieser Codebasis zu arbeiten
    Wenn die Beteiligung am Commit-Prozess weder Wissen noch ein Gefühl von Besitzverantwortung vergrößert hat, dann war es im Grunde keine echte Beteiligung
  • Diese Beschreibung wirkt ähnlich wie ein typischer Compiler
    Der Compiler ist allerdings deterministisch, während ein LLM ein nichtdeterministisches Werkzeug ist, das potenziell fragwürdige Tests erzeugt
    Wir haben bereits Programme, die von Menschen geschriebene Anweisungen oder Code in maschinenlesbaren Code oder eine Zwischenrepräsentation umwandeln, und weil sie garantieren, in welcher Beziehung das erzeugte Ergebnis zur Eingabe steht, kann man den Ausgaben vertrauen, ohne sie eigens prüfen zu müssen
    Für Optimierungen liest man Compiler-Ausgaben manchmal mit Werkzeugen wie Godbolt, aber darüber hinaus ist das im Allgemeinen nicht nötig
    Wenn man das auf einer anderen, nichtdeterministischen Abstraktionsebene versucht, mag es plausibel wirken, aber es ahmt nur die Korrektheitsgarantien nach, die Compiler liefern, und wird am Ende scheitern
    Ich halte die LLM-Debatte grundlegender für ein Symptom des Problems, dass bestehende deterministische Programmiersprachen nicht ausdrucksstark genug und ihre Werkzeuge nicht effektiv genug sind
    Es kann sich anfühlen, als würden LLMs dieses Problem lösen, aber sie sind in Wirklichkeit keine Lösung, sondern legen nur noch eine weitere indirekte Schicht und zusätzliche Performance-Kosten auf ein ohnehin zu eingeschränktes Fundament
    Eher wie ein teurer, fehleranfälliger Pseudo-Compiler, der auf einem Interpreter läuft, der wiederum auf kompilierter Maschinensprache läuft
    Deshalb halte ich das für eine technische Sackgasse
    Für Unternehmen mag es ein Weg zu kurzfristigen Gewinnen sein, aber ich glaube nicht, dass es Software oder die Beziehung von Menschen zum Nutzen und Erstellen von Software verbessern wird
    Software ist mehr als nur Technik, um ein Produkt auszuliefern

• Es hilft, nach Anwendungsfall zu unterscheiden
  Wenn es nur darum geht, neues JavaScript für die UI einer internen Anwendung hochzuladen, dann muss man meiner Meinung nach nicht unbedingt auch noch das CSS im Detail durchsehen