Talk held 2013 at EclipseCon Boston and EclipseCon France

1. Code Review
as a Great Tool in the Agile Toolbox
Matthias Sohn,
Stefan Lay (SAP)
Matthias.sohn@sap.com, stefan.lay@sap.com
Twitter: @masohn @stefanlay

2. Agenda
How we became agile
What we learned from Open Source
Why we embraced Code Review
How we scale up agile with Open Source processes

3. Agile Feedback cycles
Source: http://en.wikipedia.org/wiki/Extreme_Programming

4. Agile Feedback cycles
Pair Programming
Ralph and Karsten hacking on E4

5. Agile Feedback cycles
Test Driven Development

6. Agile Feedback cycles
Continuous Integration
Q: Who is who?

7. Agile Feedback cycles
Code Review?
Sometimes formal Code Review (Fagan style inspection)
Pair Programming is considered to be more agile
• Higher bandwidth (Faster feedback)
• Leads to faster integration than Code Review
• “Individuals and interactions over processes and tools”

8. Agile Software Engineering
Engineering practices are key
SAP trained its developers
• > 4000 participants
• 1 week training
• 3 weeks coaching
Focus on
• Scrum
• Pair programming
• Test Driven Development
• Continuous Integration
• Acceptance Tests

9. Code Review in Open Source
Maintainer Hierarchy / Contributors
Public peer review on mailing list
Committer / Contributor model
Public peer review
• Patch in Bugzilla
• Gerrit
• Github

10. Code Review vs. Pair Programming

11. Code Review vs. Pair Programming
Code Review
• leads to small, self-contained increments
• ensures that ideas can be understood from code
• leads to review discussions visible to everybody
• leaves room to develop alternative solutions
Ideal complement to Pair Programming
which is great to
• explore unknown terrain
• onboard new developer
• combine complementary skills

12. Code Review is asynchronous
Can be done when there is time
The whole team can review (also external reviewers)
Review takes time, but also leaves time
This leads to parallel workflow
Git perfectly supports this
Some aspects can be automated
• Rule checking
• Build and test
• Deployment to staging environment
All checks happen before submit

13. Code Review Best Practices - Author
Small changes are much easier to review
A change should logically do one thing (not many)
Split big changes into series of digestible changes
- These changes depend on each other
- Last change should switch the new feature on

14. Code Review Best Practices - Author
No change shall break build or tests
Commit message should explain Why
- The What should be obvious from the code change
Classify maturity of change: POC, WIP, RFC

15. Code Review Best Practices - Reviewer
Comment everything you observe
Classify comments: style nit, optional, can be fixed
later, unrelated change

16. Code Review Best Practices - Reviewer
Constructive feedback: Propose alternatives
Don’t submit if there are unanswered comments

17. Code Review Best Practices - Team
Self organized team:
All team members feel responsible to review
Explicit invitations for
- specific topics
- reviewers from other teams
Invited review has high priority
Leave enough time for others to review

18. Code Review and Scrum
Successful code review required for a task to be finished
Many Done Criteria already checked during code review
Make review visible on Scrum Board
Reserve time for review
Everybody should review

19. Code Review and Scrum
Scrum Board
Story Bug Fix Review Story A Story B Story C …
Open
In
Progress
In
Review
Done

20. Code Review with Git and Gerrit
Gerrit is a Code Review system based on JGit
http://code.google.com/p/gerrit/
Also serves as a Git server
Adding access control and workflow
Used by
• Android https://android-review.googlesource.com/
• Eclipse https://git.eclipse.org/r/
• Google, QualComm, SAP, WikiMedia…

21. Code Review with Git and Gerrit

22. Code Review with Git and Gerrit
Gerrit usage at SAP started 2010
Projects: > 2.000
Users: > 4.000
Changes: > 300.000
Run by a small team of developers (us)
Training is important (> 400 developers)
Recently Git and Gerrit were approved as standard infrastructure

23. Scaling Agile with Open Source Processes
Agile processes work great for small teams
Collaboration between teams of a large project?
• Contribute to components owned by other teams
• Review relevant changes of other teams

24. Contributions between teams
Find project information easily
Standardized infrastructure
Contributor Guide

25. Finding project info

26. Finding project info

27. Standardized infrastructure
git clone <URL>
mvn clean install
Eclipse CBI: http://wiki.eclipse.org/CBI

28. Project specific
Standardized
Contributor Guide
Where to get the sources
How to setup the project
How to build
Review process
Communication channels
Correction Process
Coding conventions
How to test
Review rules
…

29. Conclusion
Code Review brings additional value to agile teams
Git and Gerrit help a lot
Improves collaboration within and between teams
Standardization helps to scale

30. Questions & Answers

31. Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In a complex and changing environment feedback is key!