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
Zeile 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
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
