Code review is very essential in developing quality software. I have blogged about my code review experience before. Code review helps us to find defects in code. It helps us in sharing knowledge and establishing a common convention in the code base. Still problems in code review comes due to use of primitive tools, poor processes and immature behavior of reviewer or author. Recently there are research done to improve the code review process. The research findings will help us in having effective code review.
The following are the summaries from a set of research done on code review process.
Convergent Contemporary Software Peer Review Practices by Rigby and Bird, 2013
It specifies 5 best practices common to all CR processes.
- Peer review process follows a lightweight, flexible process.
- Reviews happen early (before a change is submitted), quickly, and frequently.
- Change sizes are small.
- Two reviewers find an optimal number of defects, but it also depends on the complexity of code.
- Review has changed from a defect finding activity to a group problem solving activity.
- Avoid measuring defect counts and blame game. Focus on improving overall quality of code. Prefer healthy discussions and fixing code over reporting defects or evaluating a developer’s effectiveness.
- The later makes the developers defensive and it is very tough to evaluate code quality based on number of defects as some defects are silly style issues while others are code bugs.
Modern Code Review: A Case Study at Google by Bachelli et al
The paper tries to evaluate code review process at Google based on the paper of Rigby and Bird.
- The main motive is not collective development, but
- Finding defect
- Making code maintainable and readable
- Educating new team members
- Tracking history of change
- Gatekeeping and maintaining coding convention and standard
- Expectations about a specific code review depends on the work relationship between the author and reviewers e.g. new comer vs team lead vs peers.
- The process is lightweight and flexible, but readability and ownership are explicit and auto-detected.
- The recommendation of reviewers takes reviewer workload and leaves into account.
- Code analysis tool is also integrated.
- Generally, one reviewer is considered enough.
Characteristic of Useful Code Reviews: An Empirical Study at Microsoft by Bird et al
The paper evaluates code review process at Microsoft.
- They have classified usefulness of review comments based on interviewing review authors.
- Useful:
- Identification of functional defects.
- Identification of missing validations or corner cases.
- New comers find suggestions to follow right APIs, designs and team coding conventions useful.
- Somewhat useful:
- Nit-picking issues e.g. indentation, comments, styles, identifier naming, typos.
- Alternative implementations to increase readability etc even though the current code is correct.
- Not useful:
- Asking question to understand the code
- Praising code
- Suggesting changes unrelated to current code change or suggesting future improvements
- Useful:
- They have provided the following recommendations
- Experience with code base is an important factor to get useful comments. But do include inexperienced and new developers for knowledge dissemination purpose.
- Effective review requires small changesets.
- Be especially careful with non-code files e.g. config or build file changes as reviewers often ignore those.
- Try to identify areas where code reviews are less effective. Also monitor to see if same pattern of comments are coming regularly.