A study done by CISCO systems has shown that code reviews during development reduce the amount of bugs in a system by approximately 36 percent. A bug that is caught early during the Software Development Life Cycle (SDLC) takes less resources and less time to fix than one that is caught during a later stage. A bug fixed in code review can still be fixed by developers, but a bug that was not caught and was noticed during quality control or customer usage involves more resources and increases the cost of fixing the bug.
Bugs can happen for various reasons such as project requirements not having enough detail, developers not adhering to coding standards, or just regular human error. Bugs during the development stage are most easily caught by regular code reviews. All developers agree on the importance of code review, but the two questions that frequently arise are “what are the best practices to conduct code reviews?” and “how do we measure effective code reviews?” Below are a few recommendations to answer these questions.
Best Practices
- Reviews with a checklist yield better results- The checklist provides a structure around questions that the reviewers need to address. This checklist can include questions such as:
- Maintainability focus – Is the code modular? Can any code be replaced with already written code? Is there good logging? Are there enough comments for a new user to understand the code?
- Security – Is there good exception handling? Is output encoded?
- Review fewer than 200-400 lines of code at a time- Reviewing the code all at once has will not provide optimal results, and 200-400 lines of code is considered standard for a single code review session.
- An inspection rate of less than 300-500 lines of code per hour- The reviewer should not move too fast, but also not too slow. If a reviewer is reviewing at a faster rate than 300-500 lines of code per hour, the effectiveness of the code review reduces dramatically.
- The review session should not last longer than 60-90 minutes- It’s difficult to maintain focus for a period much longer than that so have code review sessions more often and for shorter amounts of time.
- Have on-going maintenance during the code writing process- If the author of the code has taken the time to proof and annotate the code on a regular basis, the code review will yield better results.
- Remember that what gets measured gets optimized- Identify goals for your code review sessions. For example, reduce the number of defects that are leaked to QA by x%.
- Enforce thorough follow up- Bugs need to be fixed quickly, so all comments/issues raised during a code review session should be addressed in a timely manner.
- Remember that team managers can foster healthy developer relationships- An experienced developer can make mistakes just as easily as a new developer can produce software with no mistakes. Keep an open mind and leaving ego’s at the door to help with an effective code review session.
- Use light weight code review tools- A code review tool can highlight the changes since the last time the code has been committed. And it helps the reviewers focus on what needs to be reviewed. Without a code review tool identifying what needs to be reviewed, the code can get messy and might end up not being reviewed at all.
- Keep in mind that a review session does not always need to produce any comments or modifications- It’s fine to pronounce the code is good as is and important to let the team know as well.
Code review metrics
- Time in review- Determining how much time each developer spends on code review is a measure of how involved each developer on the team is.
- Defect count- How many defects were recorded of the review session can count towards effectiveness of code review as well?
- Percent of code reviewed- Every developer on the team needs to review each other’s code. The percent of code reviewed per developer helps with accountability in the review process.
References:
11 Best Practices for Peer Code Review
Modern Code Review
