Different people mean different things by code review. What’s your definition of code review?
First off, I think that the only practical peer code review process—for centrally-located teams as well as geographically-distributed ones—is one that that’s managed automatically. For example, using Parasoft’s Code Review module:
- Developers check in code to the source code repository as normal.
- A server-driven code review scanner automatically detects what code needs to be reviewed, generates code review packages that show the difference between the new code and the old code, and automatically notifies the designated reviewer(s) that a review is needed.
- Reviews are performed at each reviewer’s convenience from his familiar IDE (Eclipse, Visual Studio, RAD, Wind River Workbench, ARM RVDS, etc.).
- After examining each change, the reviewer either accepts it or requests additional revisions.
- If additional revisions are requested, the author is notified of the request, and the cycle continues.
In a nutshell, that’s how to make the code reviews practical.
To make them effective, they must be tied to requirements, with reviewers focused on determining if the code is actually doing what it’s supposed to be doing. If you don’t do this, the code review typically degenerates into developers scanning the code for problems that automated code analysis could find. That’s a shame because code analysis tools could do this scanning faster, better, and more accurately—and developers could be doing something much more valuable and interesting.
These two things are actually quite closely related: with a computer handling all of the tasks that are not creative, the brain can focus on thinking about the code in terms of the requirements.
Why is this focus on requirements during code review so important?
It’s the best way to identify improperly-implemented requirements—one of the three main categories of defects (along with missing requirements and poorly-designed interfaces that allow users to wander in unintended directions). With at least one other person inspecting the code and thinking about it in context of the requirements, you gain a very good assessment of whether the code is really doing what it’s supposed to. Automated analysis simply cannot uncover these algorithmic functional issues—this high-level analysis requires a human brain.
And what’s the value of code review workflow automation? What do you have against a good old-fashioned sit-down code review?
Well, with sit-down code reviews, the cost usually outweighs the benefit. The cost is significantly higher with sit-down code reviews. First, everyone has to figure out a time and place that’s convenient to meet. This is difficult for centrally-located teams, and nearly impossible for many geographically-distributed teams. Then the developers have to spend lots of time on preparation—trying to remember what code was changed and why, marking the changes, correlating the new version and the old version, and so on. Finally, you have all the time required for the review itself.
What’s worse, the benefit is typically lower with sit-down code reviews. They typically uncover fewer problems than automated code reviews do. Why? When everyone is sitting together in a room, they don’t give themselves enough time to really think through the code, identify all the possible problems, and come up with viable solutions. The brain does not work instantly; it needs time to think. That’s why it’s significantly more valuable to have a code review process that allows you to review code at your desktop, at your convenience, with enough time to vet potential problems and determine how to make the code more effective.
How does all this time thinking about the code during code review impact the team’s productivity?
Surprisingly, it actually improves productivity...
To read more, download Parasoft's complete "Code Review Best Practices" paper as a PDF.
You can also access this paper at the Parasoft Resource Centers for:
No comments:
Post a Comment