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
Wie viel Zeit wird inveestiert
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
