The Little Tutorials web site has a recent entry that takes a contrarian point of view for Code Reviews. The author concludes that they are mostly a waste of time. He contends that people are already busy enough, and that forced code reviews frequently degrade to something unproductive. The author does make some recommendations if you absolutely must conduct code reviews. You should run your code through the debugger first before presenting it for peer review. I share some of the sentiments from this article. But I also have some code review success stories that sway me a different way in the end.I work on a rather complex business application suite at work. We have, for the most part, subjected maintenance changes to the code to code reviews. This has indeed come at a high development cost. But the reviews we perform are not your normal type where a lot of developers get together in a room to go over the code. Ours are conducted independently by one other member of our dev team. The author puts together documentation that show all the code changes. The author also produces a unit test plan. These documents are reviewed. Comments are entered on a standard peer review sheet. The result is sent back to the author via email.
The surprising fact is that I have found our code review to be very useful. But the effect may not be as you would expect. Just the fact that we must prepare for a code review influences the quality of the work that is performed. If you know that you must document your code changes, you become more aware of your changes as a whole. And you must thoroughly understand what you are doing. Otherwise it will come up at review time since the reviewer must be able to also understand the changes based on the documentation you product. This works the same way with development testing. Simply the act of having to write down a unit test plan forces the developer to actually think about, plan, execute, and write down the steps steps and scenarios.
Our code reviews occasionally also produce the positive effect that you might expect a normal review to do. Some developer who did not understand the true requirement for the change gets enlightened. A developer gets encouraged to add more comments to promote maintainability of the code. A reviewed finds alternate paths that needs to be unit tested before the fix gets shipped.
