Some best practices for software (code) reviews

There is a pretty good body of work, including industry experience, on the benefits of code reviews - impacts on quality, impacts on budget, etc. However, I have seen some of these efforts wander adrift without much purpose.  Here are some of my collected, observed and experience "best practices" on how to have effective code reviews.

Have a purpose in mind? Know what it is you are looking for and what you would do with it if you found it.  How will the finding impact the instructions to the developers, the design, or the contracts?  Can findings in the code review be turned into defect reports or change requests?

Establish measures of quality... in advance if possible. A good code review sets some basic standards before they start the review. It would be best if this comes from experience in the project but this can also come from general industry experience.  If your reviewer(s) don't have the experience to suggest, rough order of magnitude, what levels of defects are alarming (or tolerable) then you might need new reviewers.

Establish both positive and negative measures.  These criteria should be worded in the review plan as "...no more than..." and "...no less than...".  Also, it is important to measure indicators of quality as well as defect.

Use a mix of automated and manual reviews.   Tools do a great job of scanning huge volumes of code for violations of (or adherence to) easily parsed syntax rules.  As a modern practice there is really no excuse not to do this kind of review...if only to free labor for the manual reviews. However, you also get lots of value from manual reviews - do "mock" code reviews on samples from the code if you need to save time but at a minimum include some manual review.

Use a mix of static (source only) and compiled reviews.  Most source code analyzers only require the source code and not compiled code.  Handy when it is difficult or impossible to set up a run-time environment.  However, if using JUnit or the equivalent you need compiled code and it is valuable to use coverage tools to make sure the test cases cover all of the run-time code.  Bound checking usually requires compiled code though some source tools give insights into this.

No comments: