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 Using the Team Project Portal.

  • 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 How to: Add New Work Items.

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.

  • 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 compiler checking, unit tests, and documenting the design at the outset.

See Also

Other Resources

Writing Quality Code