Guidelines for Conducting Design and Code Reviews
The following guidelines provide several techniques for design and code reviews.
Required
Take your time to conduct the review.
The purpose of review is to carefully understand and analyze design and code. Spend up to half the time on a review that you did writing the code or planning the design originally.
Let the reviewers drive the review.
The reviewers and their comments must drive a review. If developers are allowed to lead reviews of their own work, other reviewers might miss problems.
Read the code or design document before the review meeting.
Unless you are meeting to review some very minor changes, prepare in advance for review meetings. Review meetings for which the reviewers do not prepare beforehand by reading the code or design waste time for everyone involved.
Use Team Project Portal for group reviews.
Publish your design docs on a project portal where everyone can easily find and review them. Send a pointer to the published document to your reviewers and ask them to add their comments using the Internet Explorer discussion feature. If you want to have your code similarly reviewed, paste your code into a Word document and publish it on a SharePoint site also. For more information, see Planning and Tracking Projects.
Use a checklist.
It is easy to get carried away with certain aspects of a review, for example, focusing exclusively on security, error handling, or style. You might be tempted to move on to other tasks after completing a single aspect. Checklists remind you of the many different aspects that you must cover in your review.
Track all issues found during code reviews.
Document issues as work items, as comments in the code, or as issues in the design documents. Otherwise, the problems can get lost and you will have gained nothing for the time that you invested in a code review. For more information, see Create a Work Item.
Avoid
Change the code or design without informing reviewers.
You might find defects in your design or code after you have sent it out for review, but you must resist the temptation to fix the problems before the review meeting. If you change the code or design before the meeting, the review will be confusing and your reviewers will likely take offense. Instead, treat the mistakes that you find as if you were the reviewer; notate them and track them together with all the other review comments.
Recommended
Include representatives from all disciplines.
Although it is not always feasible to have a variety of disciplines, other than development, review your designs and code, representatives from various disciplines can help discover hard-to-spot issues. One person, or perhaps two people, per discipline is enough. Involving more people than that makes reviews lengthy and difficult to manage.
Review all code and designs.
To achieve quality in your product, have code and design reviews for all your work. Reviews should include code analysis, unit tests, and documenting the design at the outset.
Consider creating shelvesets to manage your code reviews.
You can create a shelveset that contains only the changes that you want the reviewers to examine. When you create a shelveset, you share your changes with the reviewers without checking those changes in to version control. For more information, see Working with Shelvesets.