1. Management buy-in
2. Process defined with roles needed for the review process: Moderator, Author, Recorder, Instructors
3. Duration, preparation, tasks clearly defined as part of the process
4. Do Remember, review is of the work-product not of the author
5. Author's Manager may not participate in the review
6. Good practices/Standards need to be established
7. Size of the work product to be reviewed in a review meeting, size of the review team and duration of the review need to be defined
1. Author needs to be a passive participant
2. Author should not be defending his/her work
3. Instructors need to look at defects and not at solutions
4. Do not miss the larger picture
1) Clearly define the objectives of the review and what questions need to be answered. Example:
1.1) Will the code be reviewed to ensure that it meets the requirement and design specs?
1.2) Will the code be reviewed to ensure compliance with standards? Standards such as: Code maintainabilitiy, GUI-standards, Development Standards (structure, cyclomatic complexity, naming conventions), Organizational Standards, and Security, etc.
2) Restating in a different way what qasleuth also stated: Limit the amount of code reviewed in a session.
3) Ensure you are reviewing the correct code! By that I mean the following: If all the code cannot be reviewed (the usual case), ensure you are reviewing system-critical, business-critical, or application-critical code.
4) Are there accompanying unit tests? Are there test drivers and/or stubs? Is the approach to testing correct along with the test cases? Who will do the unit tests - the developer or a peer?
It was a good time for this post to appear. We, in our company have been strengthening our review process. Management have started to bear strongly on all the teams to use this process. We (QA is the frontrunner) have been putting together jargon and defining the process. Most of the stuff was already in place, but nobody was using them. All we have to do is dig-up the long buried process.
Some of the stuff which we have been pitching:
1. We are trying to catch defects in the requirements stage by strengthening the review process (hope to get some metrics in about 6 months time)
2. stage containment (there would be some seepage, but with the stage defects we are hoping to catch the carryover defects)