高质量代码签入准则【鸡蛋】

下面的列表提供了几项签入高质量代码的准则。

必需的操作

---

• 坚持高质量的签入。

  在代码签入期间不要接受低质量代码；低质量代码会导致产品周期的以后阶段出现问题。我们应认识到，小组通常无法修复过于复杂、过于隐蔽或在产品生命周期中发现过迟的问题。

• 使用检查表。

  跟踪经常容易犯的错误种类，并将它们作为以后代码的检查表。可以用小组或部门容易犯的常见错误作为检查表的起始内容，然后针对您的使用个性化该列表。

• 进行代码检查。

  代码检查为您提供了解释和更好了解您自己的代码的机会，并为他人提供了重新查看您的代码的机会。

• 编写单元测试。

  确保质量的最佳方法是编写验证数据和算法并确认以前的错误不再重现的测试。有四种单元测试：

  • 肯定性单元测试代码是否按预期方式执行并验证结果是否正确。

  • 否定性单元测试故意以错误方式使用代码，验证可靠性和错误处理是否正确。

  • 压力测试使代码进入极限状态，希望借此暴露细微的资源、时间或重入错误。

  • 错误植入测试可暴露错误处理的不妥之处。

  有关更多信息，请参见如何：创作单元测试。

• 使用代码分析工具。

  尽早捕获 bug 的最简单的方法是在编译器中提高警告级别并使用代码分析工具。关键是绝不忽略警告并且修复代码。

  有关更多信息，请参见 检测和更正 C/C++ 代码缺陷 和 检测和更正托管代码缺陷。

• 不要在源代码中使用不恰当的语言。

  源代码中不能有任何不恰当的语言和引用。全球许多客户对某些措辞或名称极为敏感，特别是对地位尚未确定的政治实体的引用。在您的源代码中搜索在政治上敏感的引用和语言，然后报告所有错误。

• 创建工作项。

  不要忘记未完成的工作；请务必为 TODO、REVIEW、BUG 和 UNDONE 注释创建工作项。有关更多信息，请参见如何：添加新工作项。

应避免的行为

• 没有规范的功能。

  不要编写没有规范的代码。首选，编写一个规范并检查它。如果没有规范，测试小组便无法知道什么行为是正确的，什么行为是错误的。如果代码没有规范，您可能会与小组成员产生误会，错误理解客户的需要，并最终交付低质量的产品。有关更多信息，请参见 Team Foundation 团队项目。

• 在第一个里程碑节点任务过半的情况下，但仍未将产品安装到位。

  测试小组必须通过某种方法在他们的计算机上安装产品，即使产品可能还不过是一个原型。有关更多信息，请参见 Team Foundation Build 概述。

建议

• 使用一致的编码风格。

  如果整个小组的代码使用相同的风格，您的产品将获得更好的可读性、一致性、可维护性和总体质量。准则本身的具体内容并不非常重要。重要的是建立某些准则，让您的小组切实地遵循这些准则。遵循某种风格的主要好处是使编码模式一致且易于识别。因此，请选取一种风格并使用该风格。

• 在编写代码之前编写单元测试。

  测试先行的开发是一种来自敏捷开发和极限编程的关键技术。您通过首先编写单元测试来完成几个质量目标：

  • 确保编写了单元测试。

  • 确保可以轻松测试您的代码，这通常可以增强代码的内聚力，并使模块之间的耦合更加松散。

  • 您通常可以通过首先确定应如何测试设计来发现设计是否正确。

  有关更多信息，请参见如何：创作单元测试。

• 使您的代码可以移植到其他平台。

  针对可移植性进行设计和编码可以使您的代码更加可靠，即使您从未计划过要将您的代码移植到其他平台。使您的代码可移植后，您可以：

  • 做出更合理的假设。

  • 更加了解数据类型和设计意图。

  • 确保您的代码具有在今后支持新平台的更强能力。

• 将现有代码重构为更小的函数。

  重构可以使旧代码获得新生。尝试修复大型的旧系统会非常困难，因为它们之间的交互十分复杂，您甚至会不愿意更改一条注释。

  若要使重构成功，必须首先结合强大的单元测试，以确保重构不会引发新的错误。接下来，将较大的函数拆分为较小函数的集合，但不更改任何功能。准则包括：

  • 每个更小的函数应仅执行一种类型的任务，例如用户界面、数据库访问、与单个接口的 COM 交互，等等。

  • 完全重构子系统中的所有函数后，可以更改单个小函数，而不影响整个系统。每次只能添加、移除或增强一个函数的功能。

  有关更多信息，请参见重构类和类型。

• 检查现有代码。

  bug 经常集中在特定的模块中。如果您的新代码是干净的，但您的旧代码的某些模块中存在 bug，则只需检查那些模块。如果新代码和旧代码交错程度很高，则重构通常有助于解决问题。有关更多信息，请参见 检测和更正 C/C++ 代码缺陷 和 检测和更正托管代码缺陷。

• 在调试器中逐句通过所有代码路径。

  验证代码的最佳方法之一是在调试器中逐句通过代码。在每一行，确认您预期发生的行为确实发生了。在调试器中逐句通过所有代码路径类似于一行一行进行的单元测试。此过程是冗长乏味的，但可以有效地验证预期的行为。

不建议采取的行为

• 将要求文档作为规范。

  不要尝试根据要求文档来解释规范。您的解释可能与项目经理或测试人员的解释不同。如果您的解释不同，则您的实现对于其他人预期的目标来说将是不合格的。