Methods, Not Methodology (I): Validated Code Review
See Also: AntiPattern: Batch Code Review
Code review, specially daily code review, is considered a good practice. I’ve participated lots of code review meetings, and something concerns me. It’s the low efficiency. Usually it takes longer time than scheduled, while gains less benefits than expected.
Lacking of guideline to facilitate reviewers’ thinking is one of the reasons for low efficiency. All comments come randomly. The harvest really depends on reviewers’ mental state, tired or energized. What kind of guideline could we use? a checklist for something? It could make things better, but today I’m going to apply the “validated learning” idea to code review.
The goals for code review are:
- Gain knowledge for both business and technique.
- Improve the design.
- Try to find some bugs
So, to be able to achieve the goal, or to make sure we can achieve the goal, we could always use the following questions to validate the review. During the review meeting, for every code change, we can ask:
- What’s the domain knowledge behind of the change?
- What’s the technical knowledge behind of the change?
- Is there any bad smell?
- Is there any potential bug?
And yes, everybody should embed the code smell list in mind.
Use these four questions as a guideline to improve the efficiency of code review meetings. It works for me. Hope it’s helpful for you.