What
Code Review is an activity in which people other than the author of a code examine it for:
- Identify Defects
- Discover for Improvement opportunities
Objective of code review in a team leads creating and maintaining a consistent, structured, and standardized codebase. Nothing more, nothing less
Why
The benefits or the goals of code review are the following:
- Finding bugs as early as possible, so they are economical to fix.
- Coding standards conformity, Code review helps to maintain consistent coding style across the project/company.
- Knowledge sharing, during review team members, gain a better understanding of the source code.
- Consistent design, review helps to maintain a level of consistency in software design.
- Software security, applications that require a high level of security can be targeted for security reviews.
- Team Building. Review discussions save team members from isolation and help them to know each other and bring them closer.
Who
| Role |
Responsibility |
| Author |
- Write code for code review
- Takes Responsibility for initiating/following up for code review
- Inform reviewer that product is ready for review
- Apply changes recommended by the reviewer
- Track the invested time for review and changes
|
| Project Manager |
- Planning and managing code review process
- Identify reviewer
- Schedule code review activity
- Ensure review occurred as planned
- Arrange/provide training if required
|
| Reviewer |
- Prepare a review checklist
- Perform code review
- Document all identified issue
- Share findings with Author
|
When
- Pre-commit/Check-In review is a form of code review where code is reviewed before going into the codebase. Code is shared with the Reviewer and the reviewer reviews it and shares their comments directly with the developer. Once all comments are implemented the code is committed to the repository.
- Post-commit/Check-In review is where the code is reviewed after going into the codebase. The code is committed to the repository and the reviewer takes the code into the repository and shares his/her comment on this with the developer. Fixes are made and again committed in the codebase.
The advantage of pre-commit review over post-commit review is that mistakes are caught early and pose less cost. As a consequence development takes more time.
- Based on the pre-prepared review checklist
- Code Walkthrough
- Conducted manually
- Risk of human error
Automated
- Fast as compare to manual with a predefined set of rules or best practices.
- Based on reports generated by the tool action items are identified.
- Popular tools FXCop and NDepend
Techniques Comparison
| Criteria |
Manual |
Automated |
| Review Time |
Comparatively High |
Comparatively Low |
| Initial Setup Time |
Minimal |
Require setup time for initial configuration |
| Technology Dependence |
Independent |
Dependent |
| Price Involved |
Only human resource cost |
Incorporates tool cost |
Focus Areas
- Review fewer than 200–400 lines of code at a time
- Aim for an inspection rate of fewer than 300–500 LOC per hour
- Never review code for more than 90 minutes at a stretch
- Establish quantifiable goals for code review, and capture metrics so you can improve your processes
- Use checklists, because they substantially improve results for both authors and reviewers
- Verify that the defects are actually fixed
- Establish quantifiable goals for code review and capture metrics so you can improve your processes
Conclusion
I'd like to end my thoughts on the code review process with the following:
- For the reviewer: Focus on the code, not the developer!
- For the developer: Don’t take it as a critic of your coding skills, but as an exercise to improve the code in the codebase.