Code Review

What is code review?

It’s a process where one developer looks at other’s code looking for consistency in style, logical errors and unit-test coverage.

How it helps

It helps to ensure better code quality in general. The code, which follows good review process, would have lesser bugs. Other advantages are

• Helps mentor new engineers
• Knowledge sharing, now someone else also knows what is going in the repository
• Reviewed code is consistent in style and helps readability and maintainability
• Reviews ensure best coding practices are followed
• Ensuring code-coverage through unit tests helps to detect regression in product
• Code reviews might catch bugs like memory leak, buffer overflow even before it checks-in into the system
• Better code quality leads to fewer bugs hence customer satisfaction

What process should be followed?

There should be a formal code review process defined for the team. As an example, I will explain the process we have been following for one of our projects in Synerzip.

The process is like this

1. The developer once ready with his code pushes it to git repository, which is integrated with gerrit code review system. This creates a new review in the system.
2. The developer has to add a primary reviewer to review his/her code. The reviewer gets notification of this.
3. Primary reviewer starts reviewing the code. While reviewing he/she refers style guides from Google for C++ and Javascript. He/she may also refer a best practices list used by the team. Moreover, he/she applies his expertise about the programming language and product knowledge while doing the review.
4. The reviewer would post his/her comments on the code; at this point developer gets a notification about it.
5. The developer has to fix the comments or sometimes  put a valid reason to not accept or postpone the change suggested by reviewer.
6. After which, he/she raises new patch to git, which updates the earlier review in gerrit system, and the reviewer is notified.
7. Primary reviewer, once satisfied with the changes would approve the code and may add a secondary reviewer.
8. The secondary reviewer, after satisfied with the code would approve the code, at which point the developer would merge the code in repository

 Tools/resources used in code review

• Google styleguides for different programming languages
• Gerrit code review tool
• Best practices checklist created and used by team

 Things to consider in code review

1. The review process can be refined based on some parameters, e.g. if required a third reviewer can be added for a bigger / complex feature or only a single review is done for a trivial bug fix.
2. Developers and reviewers should get training on best coding practices and review practices.
3. Use lint tools for style guide checks.
4. Keep updating best practices list, based on newer versions of programming language or tools.
5. There may be conflicts between developer and reviewer; people should be trained for conflict management.
6. The reviewer should be decided through a mature process. Things like overall experience in programming and expertise in a feature of the product should be considered.
7. Verbal communication between developer and reviewer should be documented as review comments. This would be helpful for others to look at and becomes a useful reference. Documenting these is even more important when the team members are working from different geographies.
8. Metrics like the number of comments, patches, reviews and the time taken to review should be looked at and evaluated. This may help to check if reviews are happening in time and are effective. These metrics may also help to find the bottleneck if any in the review process.

  References

1. Gerrit https://www.gerritcodereview.com/
2. Code review best practices http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
3. Google C++ style guide https://google-styleguide.googlecode.com/svn/trunk/cppguide.html
4. Google javascript style guide https://google.github.io/styleguide/javascriptguide.xml