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 we could 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.