设计和代码的检查准则

更新:2007 年 11 月

下列准则提供了几项检查设计和代码的技术。

必需的操作

  • 花一些时间进行检查。

    检查的目的是仔细了解和分析设计及代码。最多要花上您编写代码或最初计划设计所花费时间的一半时间来进行检查。

  • 让审阅者来推动检查工作。

    必须通过审阅者以及他们的评论来推动检查工作。如果允许开发人员负责检查他们自己的工作,则其他审阅者可能会错过问题。

  • 在召开检查会议之前,先阅读代码或设计文档。

    除非会议是为了检查某些非常微小的更改,否则应该事先为检查会议做好准备。如果审阅者事先不阅读代码或设计以做好检查会议的准备,则会议会浪费每个与会人员的时间。

  • 使用团队项目门户为小组检查工作提供帮助。

    在任何人都可以轻松找到并检查的项目门户上发布您的设计文档。向您的审阅者发送一个指向已发布文档的指针,并让他们使用 Internet Explorer 的讨论功能添加他们的评论。如果希望以同样方式检查您的代码,请将您的代码粘贴到 Word 文档中,并将该文档发布到 SharePoint 站点。有关更多信息,请参见使用团队项目门户

  • 使用检查表。

    进行检查工作时,很容易过于专注检查工作的某些方面,例如,完全关注于安全性、错误处理,或样式。完成某一方面的任务后,您可能会临时转至其他任务。通过检查表,可以提醒您在检查工作中必须顾及的许多不同方面的任务。

  • 跟踪在代码检查期间发现的所有问题。

    将问题记录为工作项、代码中的注释或设计文档中的问题。否则,可能会错过问题,您在代码检查工作中投入的时间将一无所获。有关更多信息,请参见如何:添加新工作项

应避免的操作

  • 在不通知审阅者的情况下更改代码或设计。

    在已发送您的设计或代码进行检查后,您可能发现其中有缺陷,但在召开检查会议之前,您务必不要将修复问题的想法付诸行动。如果在会议之前更改代码或设计,检查工作将产生混乱,而您的审阅者很有可能会为此生气。您应当将自己当作审阅者来处理错误;对这些错误作上标记,然后将它们与所有其他检查评论一起进行跟踪。

建议的操作

  • 检查工作应包括各个部门的代表。

    虽然让包括开发部门在内的各个部门都来检查您的设计和代码并非始终切实可行,但来自不同部门的代表有助于发现难以察觉的问题。每个部门一个人(或许两个人)就已足够。让更多的人参与会使检查工作变得冗长,并且难以管理。

  • 检查所有代码和设计。

    为了保证产品质量,应针对您的所有工作进行代码和设计检查。检查工作应包括编译器检查、单元测试以及记录外嵌设计。

请参见

其他资源

编写高质量的代码