正如上面所演示的，圈复杂度是代码复杂度的一个好的指示器；此外，它还是用于开发人员测试的一个极好的衡量器。一个好的经验法则是创建数量与将被测试代码的圈复杂度值相等的测试用例。在图 2 中所见的 updatePCensus() 方法中，将需要 114 个测试用例来达到完全覆盖。
分而治之
在面对指示高圈复杂度值的报告时，第一个行动是检验所有相应测试的存在。如果存在一些测试，测试的数量是多少？除了极少数代码库以外，几乎所有代码库实际上都有 114 个测试用例用于 updatePCensus() 方法（实际上，为一个方法编写如此多的测试用例可能会花费很长时间）。但即使是很小的一点进步，它也是减少方法中存在缺陷风险的一个伟大开始。
如果没有任何相关的测试用例，显然需要测试该方法。您首先想到的可能是：到重构的时间了，但这样做将打破第一个重构规则，即将编写一个测试用例。先编写测试用例会降低重构中的风险。减少圈复杂度的最有效方式是隔离代码部分，将它们放入新的方法中。这会降低复杂度，使方法更容易管理（因此更容易测试）。当然，随后应该测试那些更小的方法。
在持续集成环境中，随时间变化 评估方法的复杂度是有可能的。如果是第一次运行报告，那么您可以监视方法的复杂度值或任何相关的成长度（growth）。如果在 CC 中看到一个成长度，那么您可以采取适当的动作。
如果某一方法的 CC 值在不断增长，那么您有两个响应选择：
- 确保相关测试的健康情况仍然表现为减少风险。
- 评估重构方法减少任何长期维护问题的可能性。
还要注意的是，JavaNCSS 不是惟一用于 Java 平台促进复杂度报告的工具。PMD 是另一个分析 Java 源文件的开源项目，它有一系列的规则，其中之一就是报告圈复杂度。CheckStyle 是另一个具有类似的圈复杂度规则的开放源码项目。PMD 和 CheckStyle 都有 Ant 任务和 Maven 插件（请参阅 参考资料，从那里获得关于至此为止讨论的所有工具的更多信息。）
使用复杂度度量
因为圈复杂度是如此好的一个代码复杂度指示器，所以测试驱动的开发 (test-driven development) 和低 CC 值之间存在着紧密相关的联系。在编写测试时（注意，我没有暗示是第一次），开发人员通常倾向于编写不太复杂的代码，因为复杂的代码难以测试。如果您发现自己难以编写某一代码，那么这是一种警示，表示正在测试的代码可能很复杂。在这些情况下，TDD 的简短的 “代码、测试、代码、测试” 循环将导致重构，而这将继续驱使非复杂代码的开发。
所以，在使用遗留代码库的情况下，测量圈复杂度特别有价值。此外，它有助于分布式开发团队监视 CC 值，甚至对具有各种技术级别的大型团队也是如此。确定代码库中类方法的 CC 并连续监视这些值将使您的团队在复杂问题出现时 抢先处理它们。
上一篇： 跨越边界: 活动记录和 Java 编程中特定于域的语言
下一篇： 面向方面的编程：它的好处是什么？
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
