Peer Code Review, Automated Code Review
This paper is part of a series of interviews in which Adam KolawaParasoft CEO and Automated Defect Prevention: Best Practices in Software Management (Wiley-IEEE, 2007) co-authordiscusses why, when, and how to apply essential software verification methods. The series also addresses code analysis, unit testing, memory error detection, message/protocol testing, functional testing, and load testing.
In this interview, Kolawa discusses why, when, and how to implement peer code reviews (code inspections). Read on to learn how process automation plus a focus on requirements can help your team uncover more complex defects without impeding project progress.
Different people mean different things by code review. Whats your definition of code review?
First off, I think that the only practical peer code review processfor centrally-located teams as well as geographically-distributed onesis one that thats managed automatically. For example, using Parasofts 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 reviewers 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, thats 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 its supposed to be doing. If you dont do this, the code review typically degenerates into developers scanning the code for problems that automated code analysis could find. Thats a shame because code analysis tools could do this scanning faster, better, and more accuratelyand 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?
Its the best way to identify improperly-implemented requirementsone 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 its supposed to. Automated analysis simply cannot uncover these algorithmic functional issuesthis high-level analysis requires a human brain.
And whats 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 thats 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 preparationtrying 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.
Whats 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 dont 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. Thats why its 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 teams productivity?
Surprisingly, it actually improves productivity...
To read more, download the complete Code Review Best Practices paper as a PDF.