Foliensatz zum Vortrag auf der JAX 2016 in Mainz.

1. JAX Mainz
20.04.2016
Andreas Günzel
Code Review to the Rescue

2. Andreas Günzel
Team Manager Java Enterprise Solutions
EXXETA AG
Code Review to the Rescue
Meine Person
@leichtundkross
Andreas.Guenzel@EXXETA.com
www.EXXETA.com
20.04.2016 2

3. Aus dem Keller zum Team
Wann ist done done?
Code Reviews mit Gerrit & co. (Live Demo)
Code Review to the Rescue
Agenda
20.04.2016 3

4. Softwareentwicklung heißt
Teamarbeit
MS DOS 1.0 bestand aus etwa
4.000 Zeilen Assembler Code (1981)
Google hat über
2.000.000.000 Lines of Code (2015)
Softwareentwicklung wird immer komplexer.
Eine Person alleine kann dies nur noch
schwer beherrschen
20.04.2016 4Code Review to the Rescue

5. Software Development Teams sind…
… zwischen 3 und 9
Personen stark (SCRUM)
… heterogen besetzt
• Erfahrene Entwickler
• Junior Entwickler
• QS
• Domain Experts
Quelle: qsm.com
20.04.2016 5Code Review to the Rescue

6. Das ideale Team?
PO
Architekt
ConsultantsBusiness Analyst
20.04.2016 6Code Review to the Rescue

7. Leider ist die Welt nicht ganz so perfekt…
Versionsverwaltung?
Brauchten wir früher auch nicht!
Was ist eine
Nullpointerexception?
Ich habe mir den Code mal angesehen.
Das funktioniert.
20.04.2016 7Code Review to the Rescue

8. Warum Teams nicht (immer) skalieren
Die Ausrichtung als Team birgt Risiken
• Differenzen in Bezug auf Einstellung, Werte und Erwartungen an den Job
• Unterschiedlicher Wissensstand und Fähigkeiten
• Unterschiedliche Auffassung von Verantwortlichkeit
Die Konsequenzen trägt der Projekterfolg
• Qualität der Arbeitsergebnisse ist gering
• Performance des Teams sinkt
• Frustration im Team
Indikatoren
• Bauchgefühl
• Große Anzahl an Bugs
• CI Build bricht oft, Integrationsumgebung ist instabil
20.04.2016 8Code Review to the Rescue

9. Wann ist done done?
Teams arbeiten besser zusammen, wenn alle Mitglieder eine ähnliche Auffassung
von Guidelines, Qualität und Verantwortung haben
Die Definition of Done gibt nur
einen Rahmen vor
Es ist schwierig sicherzustellen,
dass Richtlinien und Absprachen
eingehalten werden
Pair Programming
„Lokale QS“
Code Review
20.04.2016 9Code Review to the Rescue

10. Code Review als neuer
Bearbeitungszustand
Erweiterung des Boards um Review Spalte
Andere Entwickler werden zur ersten Qualitätsstufe
20.04.2016 10Code Review to the Rescue

11. Pull Requests
Neue Features & Bugfixes werden nicht ohne Freigabe in die gemeinsame
Codebasis übernommen
Eigener Branch als Basis für Optimierungen, Fixes und weitere
Anpassungen
Diskussionsgrundlage
Review (selbst oder andere Teammitglieder)
20.04.2016 11Code Review to the Rescue

12. Setup
Source Repository mit Unterstützung von
• Pull Requests
• Code Reviews
Automatischer Build für jeden Pull Request
• Sourcen kompilieren
• Unit-Tests ausführen
Automatischer Code-Review
• Statische Code Analyse: Checkstyle, FindBugs, PMD
• Architekturmetriken: Structure101, Sonargraph
20.04.2016 12Code Review to the Rescue

13. Gerrit Code Review
20.04.2016 13Code Review to the Rescue

14. Live Demo
20.04.2016 14Code Review to the Rescue

15. Review Systemlandschaft
Reviewer
Code Review
-2 / +2
Verified
-1 / +1
Gerrit
20.04.2016 15Code Review to the Rescue

16. Einsatz mit Bedacht
Code Reviews
• Bringen mehr Qualität
• Binden Ressourcen
• Sind keine Garantie
Agile Manifest
• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Tools benötigen Betreuung
Tools müssen bedient werden können
20.04.2016 16Code Review to the Rescue

17. Gerrit Code Review
SonarQube
Sonargraph
20.04.2016 Code Review to the Rescue 17
Hausaufgaben
@leichtundkross
Andreas.Guenzel@EXXETA.com
www.EXXETA.com