Softwerkskammer

 

Diskussion zu Code Reviews

Erwartung, Fragen, ...

Zunächst haben wir die Erwartung und Fragen die die Teilnehmenden hatten gesammelt:

  • Motivation für Code Reviews erhöhen
  • Was ist ein (ordentliches) Code Review?
  • Wie verhindere ich, dass Code Reviews nur SonarQube-Checks sind?
  • KI statt Code Review?
  • Erfahrungen anderer mit Code Reviews zu hören
  • Inhalt und Vorgehen für Code Review
  • Remote Code Reviews
  • Refactoring und Code Reviews
  • Zeitpunkt des Code Reviews und welche Alternativen gibt es
  • Tooling
  • Warum macht ihr Code Reviews?
  • Demoralisation durch Code Reviews vermeiden?
  • Code Reviews als Prozess bzw. was ist der Prozess?
  • Konflikte und Meinungsverschiedenheiten in Code Reviews
  • Wie viel Zeit verbringt ihr mit Code Reviews am Tag? Wie viel Zeit ist angemessen?
  • Trunk-based development und Code Reviews?
  • stacked pull requests
  • Sind Pull Requests dasselbe wie Code Reviews?
  • objektives Feedback vs. persönlichen Stil durchdrücken

Ziele und Ergebnisse eines Code Reviews

  • Qualität (Security, Wartbarkeit, ...) sichern und verbessern?
  • Wissensverteilung und -transfer im Team (um Wissensinseln zu vermeiden)
  • Einschleusen von Schadcode verhindern (insbesondere in Open-Source-Software)
  • Design/Entwurf prüfen (sollte das nicht besser vor dem Coden passieren?)

Wann Code Reviews machen?

  • vorhandenen, bereits in Produktion verwendeten Code verstehen (z. B. für Entscheidung ob neue Features wirtschaftlich hinzugefügt werden können, ob Code noch den aktuellen best practicies entspricht, ...)
  • neuen Code vor Übernahme in main line bzw. Produktion
  • Übernahme ganzer Code-Basis (z. B. von anderem Team/Nearshoring)
  • Wenn erster Entwurf steht (vor vollständiger Ausimplementierung) -> Design-Review

Prozess

  • pull request basiertem Workflow
    • asynchron -> kann E-Mail-Ping-Pong erzeugen
    • synchron (vor Ort zusammen an einem Rechner, per Video-Telefonie): Autor und Reviewer
  • "fortlaufendes" Code Review durch Pair oder Ensemble Programming
  • trunk-based development mit nachgelagertem Review
    • pro Commit: oft einfacher und schneller, da Änderungen besser zu überblicken
    • pro fertige Story: besser für Überblick/Zusammenhänge zu erkennen, wenn Änderungen nicht zu groß sind
  • stacked pull requests

Wie mit Refactorings umgehen?

neue Funktionen nicht mit Refactorings vermischen, sondern

  • stark trennen (s. Zwei-Hüte-Metapher, Tidy First?)
  • kein eigenes Ticket für nötiges Refactoring: Refactoring ist nötige Voraussetzung für Feature, also gehört es zum Ticket
  • nicht ohne Auftrag Refactoring durchführen ("Bibliothek X wollte ich schon immer mal ausprobieren")

Wie viel Zeit wird investiert

In der Gruppe gab es sehr unterschiedliche Angaben, wie viel Zeit pro Woche für Code Reviews aufgewendet werden

  • je größer die Änderungen ist oder je näher das Release ist, desto kürzer ist die investierte Zeit
  • genannte Zeit pro Woche:
    • 5%
    • 30% (als "Maintainer" des Codes, das ist wohl auch ein üblicher Wert für Open-Source-Maintainer)
    • schwankt von Woche zu Woche
  • bei Reviews einer kompletten Codebasis vor der Übernahme von einem anderen Team (Nearshoring)
    • bis zu 100%
    • Team hat irgendwann keine Lust mehr

Was macht ein gutes Code Review aus / Wie können Code Reviews mehr Spaß machen?

  • Gamification?
  • Austausch zwischen Autor und Reviewer
    • von einander lernen
    • neue Bibliotheken, Tools, Methoden lernen
    • wenn Autor Ratschläge und Hinweise von Reviewer einfordert
    • wenn Code Review interaktiv ist (z. B. Tour durch den Code)
  • Änderungen semantisch klein halten
    • gut geschnittene Commits (Refactoring und Neuentwicklung trennen)
    • in mehrere kleinere Änderungen aufteilen, die getrennte Reviews erhalten
  • gute Tools
  • ausreichend Infos und Kontext bereitstellen
    • mit einander reden
    • sinnvolle Beschreibung der Änderungen (was und warum)
    • Ticket verlinken
  • schrittweises Review
    • Beschreibung prüfen -> falls nein, direkt ablehnen oder weiter zum nächsten Kriterium
    • baut der Code -> falls nein, direkt ablehnen oder weiter zum nächsten Kriterium
    • ...
  • zum schrittweisen Review gibt es auch Widerspruch aus der Gruppe:
    • verbrennt Zeit (sowohl bei Autor als auch bei Reviewer)
    • wäre da Pair Programming nicht besser, damit man zusammen auf einen Nenner kommt?
  • Probleme in Code Reviews (zu viele Kommentare, verschiedenes Verständnis, ...): dann sollte man Konsequenzen ziehen, z. B.
    • Leute schulen, damit man auf einen Nenner kommt
    • eventuell Katas oder ähnliches durchführen
    • Entwurf vor Implementierung im Team besprechen und abstimmen
  • Klare und hilfreiche Kommentare (e.g. Conventional Comments)
  • How to Make Your Code Reviewer Fall in Love with You

Kritischer Blick auf Code Reviews

Alternativen zum Code Review

  • Pair und Ensemble Programming: dann hat man nur ein kurzes Code Review, da eh schon mindestens eine Person (oder alle) am Code mit dran waren (Review während Pairing bzw. Ensemble)
    • darauf achten, dass nicht immer dieselben Personen an denselben Stellen dran sind (Wissensinseln vermeiden)
    • darauf achten, dass keine Betriebsblindheit im Pair/Ensemble entsteht
  • Code Reviews nur punktuell einsetzen: gesunden Menschenverstand anwenden