Vincit Teatime 2013

1. Improving Code Quality In Medical Software
Through Code Reviews
Janne R¨onkk¨o (janne.ronkko@vincit.fi)
Vincit Oy
April 9, 2013

2. Contents
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary

3. Outline
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary

4. Goals In Code Reviews
Preventing bugs from ending up in product
Keeping main branch working
Quality assurance
Design verification
Knowledge sharing
There is always at least two developers who know the change
A way to see how others have solved problems

5. Are Code Reviews Useful?
The earlier you find issue the cheaper it is to fix the issue
Can improve your discipline
Forces the developer to reason his/her solution
There is no single developer knowing certain implementation

6. Are Code Reviews Useful?
”I believe that peer code reviews are the single biggest thing you
can do to improve your code”
Jeff Atwood of Coding Horror at
http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
”Individual inspections typically catch about 60 percent of defects,
which is higher than other techniques except prototyping and
high-volume beta testing.”
Steve McConnell, Code Complete 2nd Edition, page 485

7. Types Of Code Review
Formal code review
Peer review
Pair programming

8. The Traditional Code Review
A lot of code is reviewed in single session
Many participants
Preparations beforehand
Formal

9. The Traditional Code Review
Problems
Iteration takes time
A lot of code
Leads discussion easily to minor issues

10. Peer Reviews
Usually immediately after task has been implemented
In most cases all the changes are reviewed as single entity
Part of the normal work flow

11. Pair Programming
Continuous review during development

12. Outline
1 About Code Reviews
2 Code Reviewing In One Project
About The Project
Workflow
Reviewing - The Way We Do It
Tools
3 Summary

13. About The Project

14. Overview
All changes have to be reviewed by our client before approval
Code is delivered to our client’s VCS
Changes are delivered biweekly

15. About The Developed Software
C++
Almost 2 million lines of code
Tens of subsystems
The development of current version started around 2000
Tens of developers, mainly located in Finland
Builds for Windows and Linux

16. The Vincit Team
Initially two developers
The team grew up to about 15 developers during the project
Most of the Vincit developers had no prior knowledge about
the software

17. Challenges For Developers
Large code base
Hard to remember / find utility classes
Finding implementation of certain feature is not trivial
The way how things are done has evolved
Coding style has evolved
Strict rules about which C++ features are allowed

18. Workflow

19. The Initial Workflow
No peer review at Vincit
Long delay between implementation and comments
Multiple changes were reviewed as single change
Single comment list for all reviewed changes
Reviewing was split on a subsystem basis

20. The Initial Workflow
Results From Reviews
Mainly comments about coding style
A lot of questions why something was changed
A lot of requests to fix issues not related to the real change in
files

21. Changes In Project
Vincit team had grown from two (2) developers to five (5)
Changes done within one delivery cycle had grown
Time getting comments from review had grown

22. Changes In Project
Vincit team had grown from two (2) developers to five (5)
Changes done within one delivery cycle had grown
Time getting comments from review had grown
Something had to be done to improve the situation

23. The Revised Workflow
In peer review
the developer explained the change to another developer
the change was discussed
usually it was just agreed that after some changes the task
would be ready

24. The Revised Workflow
Results From Reviews
Many issues were corrected before handing the code to the
client
Many enhancement ideas were discovered
Because the developer explained the code to reviewer not all
the issues that should have been fixed were fixed

25. The Revised Workflow
Results From Reviews
Many issues were corrected before handing the code to the
client
Many enhancement ideas were discovered
Because the developer explained the code to reviewer not all
the issues that should have been fixed were fixed
But the main problems in review remained:
The long delay between implementation and final comments
A lot of questions was asked
Comments from client were in a single list

26. The Current Workflow
Immediate (or almost immediate) comments on change
Client reviews also one change instead of all changes in single
delivery
The workflow has worked well even for team of 15 vincitizens

27. The Current Workflow
Results From Review
Practically no remaining coding style issues in client review
Developers have become more disciplined
Client can review the change faster and easier than before
Client can concentrate on functionality

28. The Current Workflow
Results From Review
Practically no remaining coding style issues in client review
Developers have become more disciplined
Client can review the change faster and easier than before
Client can concentrate on functionality
We have started talking that a change is ready to be bashed
(”valmis lyt¨att¨av¨aksi” in Finnish)

29. Reviewing - The Way We Do It

30. Overview
Each commit is reviewed separately1
Commit is always reviewed after fixing found issues
Reviewed commit is required to be self-containing
Review is done first internally; client gets review request after
internal review has passed
1
A task may contain more than one commit

31. Time Spent Reviewing
clearly less than 10% of development time
reviews can be easily done, for example, while compiling

32. Review Workflow

33. Reviewed Items
Our Checklist
Functionality

34. Reviewed Items
Our Checklist
Functionality
Coding style

35. Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)

36. Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)
Readability

37. Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)
Readability
Commits and commit messages

38. Commits and commit messages
Why It Is Important To Review These?
Good commits with good commit messages
are easier to review
are helpful in the future
forces you to think what is reasonable change

39. Commits and commit messages
Why It Is Important To Review These?

40. Commits and commit messages
Why It Is Important To Review These?
There is surprisingly many tools that leverage good commits. For
example:
VCS log
VCS blame (who changed a line and in which commit)
find change introducing a bug

41. Reviewing Commit Messages
say what was changed
explain why the change has been done2
have description of the old incorrect behaviour in case of
bugfix3
2
just like good comments
3
or reference to the bug which contains the information

42. Reviewing Commit
self-containing
a good chapter in the story of the software’s history
would be reasonable piece to revert

43. Fixing Found Issues
The commit containing issues is replaced with fixed commit
because if the issue is found at code review
the story of the software’s history contains less issues / bugs
the commits remain self-containing and atomic
No commit should be broken

44. Continuous Integration

45. Continuous Integration
Usually C.I. is run for changes already put in main branch to
find if bad change has been merged
automatically build test versions

46. Continuous Integration
Usually C.I. is run for changes already put in main branch to
find if bad change has been merged
automatically build test versions
Downsides are that
C.I. is only reacting to issues not preventing them
C.I. could provide valuable information for reviews

47. Continuous Integration Reviews Our Commits!
Our C.I. tool reviews all the commits immediately after the
commits are available for review by
running unittests
running smoke test
running static code analyzer
building the most important builds

48. What Else Could Be Done At Review Time
Build and publish test version for all platforms
Have test engineer, client or end user to verify that the
change is valid

49. Tools

50. About Tools
All the tools we use in the review process
are open source
are quite easy to setup4
require very little maintenance
have been scaling without issues
4
first usable installation done less than one day

51. Version Control System
Git (http://git-scm.com/)
Distributed VCS
Very efficient at branching
Fast and efficient
Git allows easy way to ”rewrite history” (rebasing).

52. Version Control System
Git (http://git-scm.com/)
Distributed VCS
Very efficient at branching
Fast and efficient
Git allows easy way to ”rewrite history” (rebasing).
Currently only Mercurial supports rebasing in addition to Git.
Darcs has rebase support in early phase.

53. Code Review Tool
Gerrit (https://code.google.com/p/gerrit/)
Web based code review tool
Integrates with git5
Easy to add comments for changes
A Quick Introduction To Gerrit:
http://gerrit-documentation.googlecode.com/svn/
Documentation/2.6/intro-quick.html
5
Gerrit implements git repository

54. Gerrit
Reviewing A Commit

55. Gerrit
Reviewing A Fixed Commit

56. Gerrit
My Comments
The best review tool I have used
Very efficient and helpfull; makes reviewing easy
Just a tool

57. Continuous Integration
Buildbot (http://buildbot.net/)
Python based CI system
Master controls which builds should be built and when
Slaves do the actual builds
Built-in support for gerrit
Can be configured to review changes in gerrit

58. Outline
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary

59. Summary
1 About Code Reviews
2 Code Reviewing In One Project
About The Project
Workflow
Reviewing - The Way We Do It
Tools
3 Summary

60. Questions?
Improving Code Quality In Medical
Software Through Code Reviews
Janne R¨onkk¨o
janne.ronkko@vincit.fi