Agile Code Reviews

Vom 4-Augen-Prinzip zum Qualitätskatalysator

Transcript

1. AGILE CODE REVIEWS Vom 4-Augen-Prinzip zum Qualitätskatalysator Christian Fischer – itemis AG Frankfurter Entwickertag 2017
2. Hutee bcak ich, Megorn baru ich, Ürebgmreon hol ich der Knögiin ihr Knid; ach, wie gut, dsas naienmd wieß, WER BIN ICH?
3. PAREIDOLIE Simpsons (altgriechisch παρα para ‚daneben‘, ‚vorbei‘ und εἴδωλον eídolon ‚Form‘, ‚Erscheinung‘, ‚(Trug-)Bild‘, ‚Schattenbild‘, theologisch auch ‚Götzenbild‘) bezeichnet das Phänomen, in Dingen und Mustern vermeintliche Gesichter und vertraute Wesen oder Gegenstände zu erkennen. -- Wikipedia
4. Code is all about Details. --Robert C. Martin
5. Semantik Syntax WERKZEUGKETTE Code Review Code Analyzer Compiler IDE Frequenz Context
6. EFFEKTIVITÄT Quelle: Best Kept Secrets of Peer Code Review 463 0 321 194 463 180 113 32 0 50 100 150 200 250 300 350 400 450 500 Bugs nach der Entwicklung Bugs nach Code Review Bugs nach QA/Test Bugs nach Kundenabnahme Vor Code Review Nach Code Review
7. FEHLERBEBUNGSKOSTEN 1 5 10 50,5 0 10 20 30 40 50 60 Anforderung Design Code Test Relative Behebungskosten Quelle: [STECKLEIN 2004]
8. TECHNISCHE GRENZFÄLLE public class Counter { protected long count = 0; public void add(long value){ this.count = this.count + value; } }
9. INNERE QUALITÄT
10. DATENSCHUTZ … catch (Exception e) { logger.error(“Incomplete transaction for ” + customer.creditcardNo); … }
11. WARTBARKEIT /* * If the new process paused because it was * swapped out, set the stack level to the last call * to savu(u_ssav). This means that the return * which is executed immediately after the call to aretu * actually returns from the last routine which did * the savu. * * You are not expected to understand this. */ if(rp->p_flag&SSWAP) { rp->p_flag =& ~SSWAP; aretu(u.u_ssav); } Quelle: Unix 6th Edition
12. Konsistenz
13. DER ABLAUF
14. TIMING Pull Request + nur validierter Code wird veröffentlicht - eingeschränkte Sichtbarkeit Pre-Commit + nur validierter Code wird veröffentlicht - schlechte Sichtbarkeit - schlechte Verteilbarkeit Post-Commit + hohe Sichtbarkeit - nicht validierter Code kann veröffentlicht werden
15. Überprüfung durch Reviewer Lessons learned Korrekturen durch den Autor Gruppen Review Vorstellung & Planung Material sichten & Einladung FORMAL Planung Einführung Inspektion Über- arbeitung Verifikation Abschluss
16. Korrektur durch Autor Walk Through Check In Entwicklung beendet ÜBER DIE SCHULTER GUCKEN Planung Einführung Inspektion Über- arbeitung Verifikation Abschluss
17. Email Schleife Email Versenden Check In EMAIL BENACHRICHTIGUNG Planung Einführung Inspektion Über- arbeitung Verifikation Abschluss
18. Freigabe Korrekturen durch den Autor Kommentare Review Request Merge WERKZEUG GESTÜTZT Planung Einführung Inspektion Über- arbeitung Verifikation Abschluss
19. PAIR/MOB PROGRAMMING?
20. PROZESSVERGLEICH Lean Agil Durchlaufzeit Ausführungszeit Inspektion & Adaption Transparenz Formal Über die Schulter gucken Email Benachrichtigung Werkzeug gestützt
21. CHECKLISTE WERKZEUGAUSWAHL ü Scopedefinition (Ranges & Files) ü Anzeige von Metainformationen ü Wer mit welchen Commitkommentar ü Kommentare ü Metriken sammeln und auswerten ü Review Enforcement ü Unterstützung von Pre- und Post-Commits
22. BEST PRACTICES
23. § Kontextvermittlung erleichtert Einstieg § Strukturierung findet Fehler Review Präambel ØZiel ØAnsatz ØRessourcen Bild: Delapouite under CC BY 3.0
24. § Kosten/Nutzen Betrachtung § Fehlererkennungsrate nimmt ab § Social Loafing 1-2 Entwickler Øgemeinsame Code Ownership Ødirekte Kommunikation ØVerteilung? Bild: Lorc under CC BY 3.0
25. § Nur begrenze Finderquote § Inspektionsrate § Konzentration 60-90 Minuten ØTimeboxed ØFokussiert Øeingeplant Bild: Skoll under CC BY 3.0
26. § Dauer § Inspektionsrate § Konzentration ca. 200 LOC Økleine Stories ØAlternative „Über die Schulter schauen“ Bild: Lorc under CC BY 3.0
27. § Commitverunreinigung § Ablenkung Code Konventionen ØFormattierungsregeln ØPattern Bild: Lorc under CC BY 3.0
28. § Transparenz § Reproduzierbarkeit Checkliste ØAllgemein verfügbar ØEindeutig Bild: Delapouite under CC BY 3.0
29. § Inspect & Adapt § Aktualisierung Metriken ØPull Dauer ØAusführungsdauer ØFehlerquote Bild: Lorc under CC BY 3.0
30. REVIEW SMELLS Bilder 1-2: Lorc under CC BY 3.0 Bild 3: Skoll under CC BY 3.0
31. FAZIT ØCode Reviews reduzieren Fehlerbehebungskosten, verbessern die innere Softwarequalität und fördern Know Transfer. ØDie agilen Prinzipien von Transparenz, Überprüfung und Anpassung gelten auch für den Code Review. ØBest Practices & Smells helfen bei der kontinuierlichen Verbesserung.
32. WEITERE INFORMATIONEN @agiledojo http://blogs.itemis.com
33. DANKSAGUNG • Lorc : http://lorcblog.blogspot.com/ • Skoll: http://game-icons.net/ • Delapouite: http://delapouite.com/ • [STECKLEIN 2004]: https://ntrs.nasa.gov/search.jsp?R=20100036670 • Best Kept Secrets of Peer Code Review: http://bit.ly/2m6NQF4