What to Look for in a Code Review

You have all the right software developers in the conference room, ready to pore over the project's code. But now& what do you do? We share tips from experienced programmers.

1 2 Page 2
Page 2 of 2

The code review should reflect the concern of the users or stakeholders, and these vary based on developer roles and experience. As longtime developer Chuck Brooks explains, a business owner (such as an independent software vendor) needs "the implementation of a storyboard or other block-level (and graphical) description of the requirement." The issues to be addressed are whether the implementation is documented; whether the implementation reuses code from the object library; what's new that didn't come from a library; how the software is tested, and whether the test(s) be automated for subsequent regression testing when updates and point releases occur.

In contrast, Brooks points out, a contract consultant working on new development should look for code clarity. "For maintenance-centric contract development, the primary concern is understanding the politics before going into the meeting," he adds. In that case, the main focus is the concerns of the champion, which include version control, testing, rollback procedures and documentation and training.

New developers should be cautioned to focus on the technology, Brooks says. "Coders aren't supposed to know about business practices, and business analysts get really paranoid."

Ensure you don't duplicate functions, says Deakins. For example, the code review process should ask, "Are we doing the same thing multiple times without using a shared function?" Pattern recognition can be challenging sometimes, he cautions, because certain things need to be repeated when you're looking at 10,000 lines of code. "At Deacom, we're constantly going back and trying to simplify the code," says Deakins. "When you're dealing with a complicated matter like an ERP application, it's hard to say 'Wow, it's done,' and then go back through the code again and look for the patterns and see how we can make this simpler." But it's an important performance issue, as well as ensuring manageable code, he says, because you'll live with this code for a very long time. "Therefore, the code review process shouldn't be a big deal. It should be the last step of simplification," he adds.

Many developers who responded to my queries about how to run effective code reviews put particular attention on the topics that are closest to their own hearts or their own domain expertise. For instance, Paddy Sreenivasan, the co-founder and vice president of engineering for Zmanda, an open-source backup and recovery software provider, tends to focus on security, error handling and user messages in the code. But all experienced developers have a wider view, too; Sreenivasan also checks to ensure any code changes are documented (i.e. code comments) and have unit tests.

This all assumes that the process works. But it doesn't, always. For details (and to groan in understanding) see How Not to Run a Code Review. And 26 Ways To Know Your Software Development Project Is Doomed, while you're at it.

Following-Up and Metrics

Don't forget to have a process for what happens after the code review, or the entire exercise is wasted.

Lear's Sweet suggests that at the end of the meeting, participants review and rank the items found as "change immediately," "change by (some date or project milestone)" and "recommendation (change at developer's discretion)." The leader should follow-up with the developer to make sure that the issues on the list are addressed," Sweet adds.

Microsoft's Welch suggests that you can calculate the effectiveness of your code reviews by tracking two pieces of information: The average bug fix rate for a team member (which he says usually is one or two per day), and the number of major issues the code review uncovered. "Assume you found five major issues in your last code review and your team's major bug fix rate is one per day," he says. "If there was no code review, it would have cost approximately five days to fix those bugs (the number of bugs times how long it takes to fix a major issue). If your code review had five participants, each prepared for one hour, and the review meeting lasted one hour, the total time is 10 hours. That's well less than five days, so your code review was worthwhile!"

These aren't the only things to keep in mind during a code review, of course. You'll find several other suggestions in the other articles in this Effective Code Review series:


Copyright © 2008 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams