Slide 1

Slide 1 text

Code Reviews: Techniken und Tipps Rabea Gransberger @rgransberger

Slide 2

Slide 2 text

Über mich Rabea Gransberger • Diplom Informatik 2008 • Entwicklerin, Projekt- und Abteilungsleitung bei MEKO-S GmbH, Bremen – Projekt-Basis eclipse Technologie (RCP, RAP) – Code Reviews toolunterstützt in allen Projekten • Vorträge auf Konferenzen • Organisationsteam JUG Bremen 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 3

Slide 3 text

Agenda • Warum macht man Code Reviews? • Wie laufen Reviews ab? • Welche Tools gibt es? • Tipps für Entwickler und Reviewer • Welche Hürden gibt es? Fragen gerne während des Vortrags oder am Ende 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 4

Slide 4 text

EINLEITUNG

Slide 5

Slide 5 text

Warum Code Reviews? • Fehler finden • Kundenzufriedenheit • Paretoprinzip (80/20 Regel) • Qualität des Code • Fortbildung des ganzen Teams • Weniger Stress • Geringere Projektkosten 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 6

Slide 6 text

Wirtschaftlicher Nutzen [10] Bugs Cost After Development 463 After QA/Test 321 200$ / fix After Customer 194 1000$ / fix Cost of fixing bugs 174k $ + Cost of 194 latent bugs 194k $ Total 368k $ 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 7

Slide 7 text

Wirtschaftlicher Nutzen Bugs Cost After Development 463 After Code Review 180 25$ / fix After QA/Test 113 200$ / fix After Customer 32 1000$ / fix Cost of fixing bugs 120k $ + Cost of 32 latent bugs 32k $ Total 152k $ 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 8

Slide 8 text

Wir machen schon TDD… • Lesbarkeit / Verständlichkeit des Code? • Fehler finden sich nicht nur im Code: – Anforderungen – Design – Dokumentation – Testfälle • Effektivität im Finden von Bugs: – Alleingang: 50% – QA/Test: 70% – Review: 65% - 85% – Review + Test: 96% - 99% [3] 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 9

Slide 9 text

PROZESS & TECHNIKEN

Slide 10

Slide 10 text

Prozess Arten • Inspektion: formelle Review Sitzung mit Team • Audit: Durchführung durch externen Anbieter • Pair Programming: 2 Autoren an 1 Rechner • Walkthrough: Autor zeigt Reviewer den Code • Informell: u.a. – Patches per Mail – Toolunterstützter Review 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 11

Slide 11 text

Task basierter Review Beispiel-Ablauf: Roles: Author / Reviewer 1-* 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger) Task Implement Review Request Review -1 Reopen +1 Done Review Comments

Slide 12

Slide 12 text

Voraussetzungen • Unterstützung durch Management und Team • Kritikfähigkeit: Es geht um den Code / Qualität der Software • Standards definieren: Syntax, Namenskonventionen, erlaubte Frameworks • Klare Aufgabenstellung / Verständnisprobleme vermeiden • Entwickler prüfen eigenen Code vor Commit • Ziele definieren 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 13

Slide 13 text

EIN BEISPIEL

Slide 14

Slide 14 text

public class ReviewCodeExample { public static String ID = "review.example"; public BigDecimal getFactor() { return new BigDecimal(0.1); } public Collection getCarNames() { List cars = getCarsFromDatabase(); List carNames = new ArrayList<>(cars.size()); for (Car car : cars) { if (!carNames.contains(car)) carNames.add(car.getName()); } return carNames; } 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 15

Slide 15 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 16

Slide 16 text

Wer? • Empfehlung: Jeder Entwickler • Wieviel Reviewer pro Anfrage? – Min. zwei mit unterschiedlichen Schwerpunkten [1] – Empfehlung: Experte in seinem Bereich [1] 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 17

Slide 17 text

Wie? • Anforderungen aus Aufgabenstellung ermitteln • Überblick verschaffen: Was wurde geändert? • Sind die Punkte der Anforderung erfüllt? • Testfälle / Coverage ausführen • Funktioniert der Code / Oberflächen-Test • Code Zeile für Zeile durchgehen • Probleme identifizieren, Kommentare schreiben und priorisieren (Technical debt) • Am schwierigsten: Fehlende Teile identifizieren • Geschwindigkeit kein Effizienzmaß • Auch für Einzeiler min. 5 min Zeit 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 18

Slide 18 text

Wie: Eye Tracking 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 19

Slide 19 text

Wann? • Zeitnah nach Entwicklung • Pre-Commit oder Post-Commit • Nicht alles auf einmal vor Release • Maximal 90 Minuten per Review 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 20

Slide 20 text

Was? • Abweichungen von Standards/Anforderungen/Clean Code • Code muss lesbar sein. Refactoring, notfalls Kommentar • Abdeckung neue Konstanten if/switch • if ohne else • Exception Handling korrekt • Immutable Objekte präferieren • Rechtschreibung/Grammatik in Nachrichten/Fehlermeldung für Benutzer • Atomare Operationen in synchronized/transactions • Verwendung von Strings/Magic Numbers • Buch: Trisha Gee: What to Look for in a Code Review (2016) 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 21

Slide 21 text

Beispiel Checkliste 1. Documentation: All subroutines are commented in clear language. 2. Documentation: Describe what happens with corner-case input. 3. Documentation: Complex algorithms are explained and justified. 4. Documentation: Code that depends on non-obvious behavior in external libraries is documented with reference to external documentation. 5. Documentation: Units of measurement are documented for numeric values. 6. Documentation: Incomplete code is indicated with appropriate distinctive markers (e.g. “TODO” or “FIXME”). 7. Documentation: User-facing documentation is updated (online help, contextual help, tool-tips, version history). 8. Testing: Unit tests are added for new code paths or behaviors. 9. Testing: Unit tests cover errors and invalid parameter cases. 10. Testing: Unit tests demonstrate the algorithm is performing as documented. 11. Testing: Possible null pointers always checked before use. 12. Testing: Array indexes checked to avoid out-of-bound errors. 13. Testing: Don’t write new code that is already implemented in an existing, tested API. 14. Testing: New code fixes/implements the issue in question. 15. Error Handling: Invalid parameter values are handled properly early in the subroutine. 16. Error Handling: Error values of null pointers from subroutine invocations are checked. 17. Error Handling: Error handlers clean up state and resources no matter where an error occurs. 18. Error Handling: Memory is released, resources are closed, and reference counters are managed under both error and nonerror conditions. 19. Thread Safety: Global variables are protected by locks or locking subroutines. 20. Thread Safety: Objects accessed by multiple threads are accessed only through a lock. 21. Thread Safety: Locks must be acquired and released in the right order to prevent deadlocks, even in error-handling code. 22. Performance: Objects are duplicated only when necessary. 23. Performance: No busy-wait loops instead of proper thread synchronization methods. 24. Performance: Memory usage is acceptable even with large inputs. 25. Performance: Optimization that makes code harder to read should only be implemented if a profiler or other tool has indicated that the routine stands to gain from optimization. [10] 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 22

Slide 22 text

Alles? • Langsam anfangen: Jeder Review hilft! • Höhere Priorität für riskante Änderungen – Änderungen an bestehenden Berechnungen – Sicherheitskritischer Code, z.B. Authentifizierung – Code ohne Testfälle – Code von neuen Teammitgliedern – Änderungen an vielen Dateien • Alles kann Pflicht sein 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 23

Slide 23 text

KLEINE HELFERLEIN

Slide 24

Slide 24 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 25

Slide 25 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 26

Slide 26 text

FindBugs • Statische Code-Analyse • Erklärung mit Lösungsvorschlägen –Bug: Method ReviewCodeExample.getFactor() passes double value to BigDecimal Constructor –This method calls the BigDecimal constructor that takes a double, and passes a literal double constant value. Since the use of BigDecimal is to get better precision than double, by passing a double, you only get the precision of double number space. To take advantage of the BigDecimal space, pass the number as a string. 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 27

Slide 27 text

Automatisierter Review • Findet Fehler die leicht übersehen werden – Probleme in Formatierung und Benennung – Fehlerhafte API Benutzung • Vor dem manuellen Review – Durch Entwickler vor Commit – Vom Build-System/Continuous Integration • Wichtig: Behandlung von False-Positives – z.B. FindBugs @SuppressFBWarnings 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger) Kostenlos: • FindBugs: http://findbugs.sourceforge.net (Extensions) http://fb-contrib.sourceforge.net) • Checkstyle: http://checkstyle.sourceforge.net • PMD: http://pmd.sourceforge.net • JQAssistant: http://jqassistant.org • SonarQube: http://www.sonarqube.org Lizenzpflichtig: • Coverity: https://www.coverity.com

Slide 28

Slide 28 text

TOOLBASIERTER REVIEW

Slide 29

Slide 29 text

Beispiel: GitHub Pull Request • Webbasierter Code Review • Commit/Branch/Task-basierter Review unterstützt • Fork von Projekt / Branch erstellen / Datei in Master editieren • Pull Request erstellen • Repository Owner werden benachrichtigt • Zeilenbasierte Kommentare können hinzugefügt werden • Pull request kann zurückgewiesen oder akzeptiert werden 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 30

Slide 30 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 31

Slide 31 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 32

Slide 32 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 33

Slide 33 text

Pull Request Review 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger) • Mail: Notification Pull Request / Review • Web: Pending Pull Request / Review

Slide 34

Slide 34 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 35

Slide 35 text

Weitere Tools • Reviews in pull requests Github (reviewable.io) • JetBrains Upsource * • Atlassian Crucible • Gerrit / eGerrit * • Review Board • Phabricator Differential • SmartBear Collaborator / CodeReviewer* • ReviewClipse* (* mit IDE Integration) • Siehe auch: 20 Best Code Review Tools for Developers 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 36

Slide 36 text

Tools Checkliste • Automatische Übernahme/Hooks für SCM • Aktualisierung bestehender Reviews • Pre-/Post-Commit Review Unterstützung • Patch/Live-Code • Wo werden Kommentare gespeichert? Code oder DB/XML? • Übersichtsseite anstehende Reviews • Tracking welche Codestellen man angeschaut hat • Kommentare mit Priorität und Thread-Aufbau • Extra Webseite und/oder IDE Integration • Benachrichtigungen per Mail • Review pro Task oder ganze Code Basis • Statistiken um Effektivität Review prüfen zu können 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 37

Slide 37 text

Beispiel: Tools der IDE • IDE bietet gute Unterstützung für Reviews • SCM Integration • Issue Tracker Integration • Task Tags • Beispiel: Review bei MEKOS mit Eclipse/Rational Team Concert 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 38

Slide 38 text

Rational Team Concert 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 39

Slide 39 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 40

Slide 40 text

Rational Team Concert • Reviewer kann Liste anstehender Reviews abfragen • Auswahl Work-Item per Doppelklick • Öffnen der angehängten Change-Sets 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 41

Slide 41 text

RTC: Change Summary 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 42

Slide 42 text

RTC: Diff Ansicht 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 43

Slide 43 text

Review mit Eclipse 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 44

Slide 44 text

Review mit Eclipse • Kommentare im Code • Task-Tags TODO/FIXME + Work-Item ID todo Strg+Space => //TODO #4738 • Code/Kommentare werden an das Work-Item mit Commit-Message „Review“ delivered • Review wird Rejected => Work Item Reopen 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 45

Slide 45 text

Tasks filtern • Autor erhält Benachrichtigung per Mail/ in IDE • Problemstellen in der Eclipse View Tasks 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 46

Slide 46 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 47

Slide 47 text

Nacharbeiten Autor • Überarbeitung anhand der Kommentare • Entfernen der Task Tags • Commit mit „Nacharbeiten Review“ • Work-Item auf Verification • Reviewer zu neuem Review einladen Reviewer • Alle Task Tags entfernt • Code erneut reviewern: • Änderungen zwischen „Review“ und „Nacharbeiten“ commits 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 48

Slide 48 text

STATISTIKEN

Slide 49

Slide 49 text

Statistiken Statistiken um den Nutzen quantifizieren zu können: • Gefundene Probleme nach Klassifizierung • Geöffnete vs. geschlossene Probleme • % Code in Review aus eingechecktem Code Zeiterfassung: • Zeit für Implementierung / Nacharbeiten / Review • Anzahl gefundene Bugs [18] 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 50

Slide 50 text

Statistik: Gefundene Probleme • Wartungsprobleme 71,7% – Benennung 16,7 % – API Nutzung /Formatierung 13,0 % – Strukturierung 16,2 % – Lösungsansatz 20,6 % • Funktionale Probleme 21,4% • Falsch Positivfunde 7,5% x Industrieller Review, Domäne: Engineering, 9 Reviews, 1-4 Reviewer, 388 Probleme gefunden [12] 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 51

Slide 51 text

TIPPS & ERFAHRUNGEN

Slide 52

Slide 52 text

Tipps für Entwickler • Kritik/Fehler = Lernen. Nicht persönlich nehmen! • Job erfordert laufende Fortbildung • Review ersetzt keine Zwischenfragen/Diskussionen • Refactoring in neues Changeset • Vor Commit Changesets prüfen • Checkliste für eigenen Review vor Commit • Reviewer an Review erinnern, wenn wichtig • Reviewer hat nicht immer Recht 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 53

Slide 53 text

Tipps für den Reviewer • Für Ruhe sorgen (kein klingelndes Telefon) • Zu viele Request: Nur mit Prio, Rest ggf. löschen • Nicht kurz schauen und OK sagen • Viele Changesets nicht vor sich herschieben • Schlecht Testbar als Walkthrough • Falsch, aber wie geht es besser? • Nicht auf Kleinigkeiten fokussieren • Wortwahl: Fragend statt tadelnd, nicht persönlich • Nicht den Code selber fixen (Bad fixes) • Guten Code/Persönliche Weiterentwicklung loben • Vom Code anderer lernen 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 54

Slide 54 text

Hürdenlauf • Reviews sind unnötig und Kosten nur Zeit • Prozess ist zu langweilig/aufwändig • Personen geraten in Konflikt / sind sich nicht einig • Personen blockieren Prozess / Unordentlich • Erfahrung != Qualität • Kritik wirft Personen aus der Bahn • Big Brother Effekt / Team fühlt sich überwacht • Review wird x-Mal rejected 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 55

Slide 55 text

09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 56

Slide 56 text

Code City Codetrails Code City Plugin 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 57

Slide 57 text

Entfernte Tools • Code Coverage / Testabdeckung • Fehlermeldungen automatisch an Support • Code City / Code as a crime scene • Continuous Integration Server • Continuous Testing • Testdaten-Generatoren • Mutation Testing 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 58

Slide 58 text

FAZIT

Slide 59

Slide 59 text

Zusammenfassung • Langsam beginnen / vorhandene Tools nutzen • Standards/Checklisten definieren • Tools für automatischen Review konfigurieren • Entspannte Atmosphäre schaffen • Support-Stress nimmt ab/Kundenzufriedenheit zu • Zusatzaufwand lohnt sich auch wirtschaftlich • Prozess ist nicht in Stein gemeißelt • Bei Vorstellungsgesprächen Review ansprechen • Jeder einzelne Code Review hilft! 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 60

Slide 60 text

Fragen? Präsentationsmaterialien: • https://speakerdeck.com/rgra Kontakt: • Rabea Gransberger (Xing, LinkedIn, usw.) • Twitter: @rgransberger Feedback Willkommen! 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)

Slide 61

Slide 61 text

Quellen 1. Understanding Open Source Software Peer Review: Review Processes, Parameters and Statistical Models, and Underlying Behaviours and Mechanisms, Rigby, Dissertation, 2011 2. Convergent Contemporary Software Peer Review Practices, Rigby, 2013 3. Software Quality in 2002: A survey of the state of the art, Capers Jones, 2002 4. IEEE Standard for Software Reviews and Audits, IEEE Std 1028™-2008 5. Modernizing The Peer Code Review Process, KLOCWORK, White Paper, 2010 6. Code Reviews should be the universal rule of serious Software Development, Chhabra, Blog, 2012 7. How to hold a more effective code review, Stellman & Green, Blog, 2008 8. Code Review in Four Steps, Hayes, Blog, 2014 9. 11 proven practices for more effective, efficient peer code review, Cohen, 2011 10. Best Kept Secrets of Peer Code Review, Cohen, Smart Bear Inc., 2006 11. Don’t waste time on Code Reviews, Bird, Blog, 2014 12. Code Review Defects, Mäntylä & Lassenius, 2007 13. The Ten Commandments of Egoless Programming, Atwood, Blog, 2006 14. Improve Quality and Morale: Tips for Managing the Social Effects of Code Review, Smartbear, 2011 15. Code Reviews in Practice: Characteristics and Influencing Factors, Baum, 2015, (publication pending) 16. What to Look for in a Code Review, Gee, 2016 17. 20 Best Code Review Tools for Developers, Blog, 2015 18. Effektiver Einsatz von Code Review, OIO, 2015 09.03.2016 RheinJUG / Code Reviews (Rabea Gransberger @rgransberger)