What Kind of Code Review Is This?

Before you go barreling into the conference room armed with a stack of printouts and the phone number for the local joint, make sure that you know exactly why you're getting the team together. Code reviews can have many purposes, and you will have a Very Bad Day if everyone has a different idea of what the purpose of this review is.

You may want to schedule different code reviews for each aspect of the project, such as one that looks at security issues and another that pays particular attention to .

"The first step should be to determine why you are reviewing the code," suggests Micheal Lalande, director of technology at QLogitek, a SaaS supply chain solution provider. "This should come from your design-time discussions, where the core non-functional requirements have been made. These can include, but are not limited to, , performance, and supportability." Re-iterating the purpose at the beginning of the meeting helps the team put its attention on items that deliver the biggest ROI, Lalande says. "For instance, if you are looking at performance, you won't care about the procedure that is called in exception cases, so accepting the results of an automated code review will suffice."

Picking on one thing at a time also ensures that developers dive headlong into a single aspect of the software and don't try to do too much at once. "Too often, a poorly run code review has everyone focus on the same superficial issues," says Theron Welch, software mentor at the Microsoft Asia Center for Hardware, who is helping to build a team in China. "A code review checklist can help encourage a smaller group to focus deeply on a specific area, another group to focus on a different area, and so on. This helps the code review achieve depth."