Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Improving Code Quality In Medical Software
Through Code Reviews
Janne R¨onkk¨o (janne.ronkko@vincit.fi)
Vincit Oy
April 9, ...
Contents
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary
Outline
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary
Goals In Code Reviews
Preventing bugs from ending up in product
Keeping main branch working
Quality assurance
Design verifi...
Are Code Reviews Useful?
The earlier you find issue the cheaper it is to fix the issue
Can improve your discipline
Forces th...
Are Code Reviews Useful?
”I believe that peer code reviews are the single biggest thing you
can do to improve your code”
J...
Types Of Code Review
Formal code review
Peer review
Pair programming
The Traditional Code Review
A lot of code is reviewed in single session
Many participants
Preparations beforehand
Formal
The Traditional Code Review
Problems
Iteration takes time
A lot of code
Leads discussion easily to minor issues
Peer Reviews
Usually immediately after task has been implemented
In most cases all the changes are reviewed as single enti...
Pair Programming
Continuous review during development
Outline
1 About Code Reviews
2 Code Reviewing In One Project
About The Project
Workflow
Reviewing - The Way We Do It
Tools
...
About The Project
Overview
All changes have to be reviewed by our client before approval
Code is delivered to our client’s VCS
Changes are d...
About The Developed Software
C++
Almost 2 million lines of code
Tens of subsystems
The development of current version star...
The Vincit Team
Initially two developers
The team grew up to about 15 developers during the project
Most of the Vincit dev...
Challenges For Developers
Large code base
Hard to remember / find utility classes
Finding implementation of certain feature...
Workflow
The Initial Workflow
No peer review at Vincit
Long delay between implementation and comments
Multiple changes were reviewed...
The Initial Workflow
Results From Reviews
Mainly comments about coding style
A lot of questions why something was changed
A...
Changes In Project
Vincit team had grown from two (2) developers to five (5)
Changes done within one delivery cycle had gro...
Changes In Project
Vincit team had grown from two (2) developers to five (5)
Changes done within one delivery cycle had gro...
The Revised Workflow
In peer review
the developer explained the change to another developer
the change was discussed
usuall...
The Revised Workflow
Results From Reviews
Many issues were corrected before handing the code to the
client
Many enhancement...
The Revised Workflow
Results From Reviews
Many issues were corrected before handing the code to the
client
Many enhancement...
The Current Workflow
Immediate (or almost immediate) comments on change
Client reviews also one change instead of all chang...
The Current Workflow
Results From Review
Practically no remaining coding style issues in client review
Developers have beco...
The Current Workflow
Results From Review
Practically no remaining coding style issues in client review
Developers have beco...
Reviewing - The Way We Do It
Overview
Each commit is reviewed separately1
Commit is always reviewed after fixing found issues
Reviewed commit is require...
Time Spent Reviewing
clearly less than 10% of development time
reviews can be easily done, for example, while compiling
Review Workflow
Reviewed Items
Our Checklist
Functionality
Reviewed Items
Our Checklist
Functionality
Coding style
Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)
Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)
Readability
Reviewed Items
Our Checklist
Functionality
Coding style
Implementation (code structure / architecture)
Readability
Commits...
Commits and commit messages
Why It Is Important To Review These?
Good commits with good commit messages
are easier to revi...
Commits and commit messages
Why It Is Important To Review These?
Commits and commit messages
Why It Is Important To Review These?
There is surprisingly many tools that leverage good commi...
Reviewing Commit Messages
say what was changed
explain why the change has been done2
have description of the old incorrect...
Reviewing Commit
self-containing
a good chapter in the story of the software’s history
would be reasonable piece to revert
Fixing Found Issues
The commit containing issues is replaced with fixed commit
because if the issue is found at code review...
Continuous Integration
Continuous Integration
Usually C.I. is run for changes already put in main branch to
find if bad change has been merged
aut...
Continuous Integration
Usually C.I. is run for changes already put in main branch to
find if bad change has been merged
aut...
Continuous Integration Reviews Our Commits!
Our C.I. tool reviews all the commits immediately after the
commits are availa...
What Else Could Be Done At Review Time
Build and publish test version for all platforms
Have test engineer, client or end ...
Tools
About Tools
All the tools we use in the review process
are open source
are quite easy to setup4
require very little mainte...
Version Control System
Git (http://git-scm.com/)
Distributed VCS
Very efficient at branching
Fast and efficient
Git allows eas...
Version Control System
Git (http://git-scm.com/)
Distributed VCS
Very efficient at branching
Fast and efficient
Git allows eas...
Code Review Tool
Gerrit (https://code.google.com/p/gerrit/)
Web based code review tool
Integrates with git5
Easy to add co...
Gerrit
Reviewing A Commit
Gerrit
Reviewing A Fixed Commit
Gerrit
My Comments
The best review tool I have used
Very efficient and helpfull; makes reviewing easy
Just a tool
Continuous Integration
Buildbot (http://buildbot.net/)
Python based CI system
Master controls which builds should be built...
Outline
1 About Code Reviews
2 Code Reviewing In One Project
3 Summary
Summary
1 About Code Reviews
2 Code Reviewing In One Project
About The Project
Workflow
Reviewing - The Way We Do It
Tools
...
Questions?
Improving Code Quality In Medical
Software Through Code Reviews
Janne R¨onkk¨o
janne.ronkko@vincit.fi
Upcoming SlideShare
Loading in …5
×

Improving Code Quality In Medical Software Through Code Reviews - Vincit Teatime 2013

1,201 views

Published on

Vincit Teatime 2013

Published in: Technology
  • Be the first to comment

Improving Code Quality In Medical Software Through Code Reviews - Vincit Teatime 2013

  1. 1. Improving Code Quality In Medical Software Through Code Reviews Janne R¨onkk¨o (janne.ronkko@vincit.fi) Vincit Oy April 9, 2013
  2. 2. Contents 1 About Code Reviews 2 Code Reviewing In One Project 3 Summary
  3. 3. Outline 1 About Code Reviews 2 Code Reviewing In One Project 3 Summary
  4. 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. 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. 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. 7. Types Of Code Review Formal code review Peer review Pair programming
  8. 8. The Traditional Code Review A lot of code is reviewed in single session Many participants Preparations beforehand Formal
  9. 9. The Traditional Code Review Problems Iteration takes time A lot of code Leads discussion easily to minor issues
  10. 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. 11. Pair Programming Continuous review during development
  12. 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. 13. About The Project
  14. 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. 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. 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. 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. 18. Workflow
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. Reviewing - The Way We Do It
  30. 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. 31. Time Spent Reviewing clearly less than 10% of development time reviews can be easily done, for example, while compiling
  32. 32. Review Workflow
  33. 33. Reviewed Items Our Checklist Functionality
  34. 34. Reviewed Items Our Checklist Functionality Coding style
  35. 35. Reviewed Items Our Checklist Functionality Coding style Implementation (code structure / architecture)
  36. 36. Reviewed Items Our Checklist Functionality Coding style Implementation (code structure / architecture) Readability
  37. 37. Reviewed Items Our Checklist Functionality Coding style Implementation (code structure / architecture) Readability Commits and commit messages
  38. 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. 39. Commits and commit messages Why It Is Important To Review These?
  40. 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. 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. 42. Reviewing Commit self-containing a good chapter in the story of the software’s history would be reasonable piece to revert
  43. 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. 44. Continuous Integration
  45. 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. 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. 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. 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. 49. Tools
  50. 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. 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. 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. 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. 54. Gerrit Reviewing A Commit
  55. 55. Gerrit Reviewing A Fixed Commit
  56. 56. Gerrit My Comments The best review tool I have used Very efficient and helpfull; makes reviewing easy Just a tool
  57. 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. 58. Outline 1 About Code Reviews 2 Code Reviewing In One Project 3 Summary
  59. 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. 60. Questions? Improving Code Quality In Medical Software Through Code Reviews Janne R¨onkk¨o janne.ronkko@vincit.fi

×