Meandyou Jun 17, 2010   8:53 PM GMT

It may depend on the reason for the code review. If you are looking for things like following standards such as naming contentions and/or coding techniques then I would think you would get "syntax" corrected before it was tested (or it will have to be retested after it is changed). If you are reviewing for documentation, then it may not matter. just my $.02 I

5,220 pointsBadges:

RobinGoldsmith Jun 19, 2010   7:45 PM GMT

Competent code reviews typically find in an hour what testing would have taken ten hours to find. Thus, it’s much more economical first to review the code to clear out a lot of errors and then follow up with testing to double check. Reviews are so much more effective and efficient because they find many errors in a single pass, whereas testing has a lot of stop-start back-and-forth wasted time due to finding only a few errors in each test execution-debugging cycle. Moreover, reviews often find errors that elude typical testing, especially potential security breaches. Caution, though, because many reviews fail to provide such benefits. The least payback comes from reviews that concentrate mainly on superficialities such as coding style and technique, which is a virtually inevitable consequence when all the reviewers have basically similar, coding-only orientations. It’s far more critical for reviewers also to understand how the program will be used and what it’s supposed to accomplish—and then confirm it will do so in ways that don’t invite problems. Authors of downstream programs are good to include as reviewers, as are analysts and users. I’ve found one or two non-coders can contribute productively and tend to keep the review focused on more important issues. Although it at first seems counter-intuitive, review effectiveness usually is diminished when the author leads the review. When leading the review, the author often talks through issues and thus can make them appear less than they later turn out to be when they actually occur in production and the author isn’t there to talk the users and maintenance people past the problem. Also, authors unconsciously lead reviews away from likely problems—things the author didn’t know about, misunderstood, or was uncomfortable with. Furthermore, when the author leads the review, it can suppress reviewers’ revelation of issues—either because they don’t want to seem too critical or because their criticism engenders emotionalism and defensiveness. Te purpose of the review should be to help the author do their best possible work. Ironically, the author who is present as a reviewer but not review leader often turns out to be the most insightful reviewer. Of course, neither code reviews nor testing is likely to catch the biggest source of errors—design errors, which in turn are mainly due to requirements errors. The biggest payoff comes from effective requirements reviews, then from design reviews, and third from code reviews. However, most organizations’ requirements and design reviews are much less effective than presumed. What organizations call ‘requirements’ usually in fact are high-level product/system designs, so the organization probably doesn’t even have REAL, business requirements let alone review them. Moreover, typical requirements and design reviews tend to use only one or two, far weaker-than-realized techniques, which look mainly at form issues such as clarity but do little to spot wrong and overlooked content issues. My book, Discovering REAL Business Requirements for Software Project Success, and related seminars explain how to overcome these weaknesses, including how to use more than 21 ways to review requirements and more than 15 ways to review designs. In addition to catching the common clarity problems, these much more powerful methods also catch issues that are wrong and overlooked.

745 pointsBadges:

carlosdl Jun 21, 2010   2:20 PM GMT

I agree with Kccrosser. I think code reviews should go first. In addition to what has been previously stated; if unit testing is performed first, and then the code review leads to code modifications, you would have to perform unit testing again to ensure that functionality has not been altered with the code modifications.

86,030 pointsBadges: