从圈复杂度谈谈代码质量

　　在软件行业里，几乎所有的开发人员都在谈代码质量，而每个人对代码质量都有一套自己的看法。甚至术语代码味道(code smell) 也已进入大众词汇表，成为描述代码需要改进的一种方式。

　　代码味道是由我们开发人员根据自己的一些工作经验积累来判断的，有人觉得代码注释可以体现代码结构和质量，还有些人又认为代码注释是用来解释过于复杂代码的一种说明机制。显然，Javadocs™ 很有用，但是多少内嵌注释才足以维护代码?如果代码已经编写得足够好，它还需要自己解释吗?从这些我们可以看出代码味道是一种主观评估的机制，在很多情况下面，尽管一些看其来糟透了的代码可能是他人曾经编写最好的代码。在我们工作中，是否有很多这样的声音，”是的，初看起来有点乱，但是它的扩展性不错”。

　　因此，我们需要客观评估代码质量的方法，某种可以决定性地告诉我们正在查看的代码是否存在风险的东西。不管您是否相信，这种东西确实存在!用来客观评估代码质量的机制已经出现了一段时间了，只是大多数开发人员忽略了它们。这些机制被称为代码度量 (code metric)。

　　目前一些公司如华为、普元等都在代码质量方面有比较严格的要求，采用CMMI5的规范来评估代码质量。他们根据单元测试覆盖率作为代码质量的一种保证手段。单元测试覆盖的种类有下面几种：语句覆盖、分支覆盖、条件覆盖、路径覆盖。在单元测试中前三种覆盖率都非常容易达到，但会存在一定的缺陷。在这篇文章中，我就不详细解说前三种覆盖率的计算方法了，重点谈一下路径覆盖率的问题。

　　圈复杂度，它可以精确地测量路径复杂度。通过利用某一方法路由不同的路径，这一基于整数的度量可适当地描述方法复杂度。实际上，过去几年的各种研究已经确定：圈复杂度大于 10 的方法存在很大的出错风险。因为圈复杂度通过某一方法来表示路径，这是用来确定某一方法到达 100% 的覆盖率将需要多少测试用例的一个好方法。公式圈复杂度V(G)=P+1 ，P是代码中判定结点的数量，下面我们看一个简单的类。

　　package com.alisoft.kplan.atest;

　　public class PathTest {

　　public String testA(boolean p1){

　　String a = null;

　　if(p1){

　　a = “”+ p1+ “”;

　　}

　　return a.trim();

　　}

　　}

　　在我们平时开发过程中，通常这样写一个测试用例，语句覆盖率达到100%

　　package com.alisoft.kplan.atest;

　　import junit.framework.Assert;

　　import org.junit.Test;

　　public

　　class PathTestTest {

　　@Test

　　public void testTestA() {

　　PathTest pt = new PathTest();

　　Assert.assertEquals(pt.testA(true), “true”);

　　}

　　}

　　这个测试用例虽然语句覆盖率达到100%但是我们会发现，其中有一个潜在的空指针错误没有被发现。问题来了，那么我们在编写测试用例的时候，怎么来写一个优秀的测试用例呢，答案很简单，就是根据圈复杂度来计算你的类方法复杂度，圈复杂度值越大，就说明你的方法越复杂，存在的缺陷会越多。通过计算公式V(G)=P+1 testA方法的圈复杂度为2，那么我们只要编写两个测试用例就可以就可以完成testA()方法的基本路径覆盖。我们在看一下这个测试用例

　　public class PathTestTest {

　　@Test

　　public void testTestA() {

　　PathTest pt = new PathTest();

　　Assert.assertEquals(pt.testA(true), “true”);

　　}

　　@Test

　　public void testTestAfalse() {

　　PathTest pt = new PathTest();

　　Assert.assertEquals(pt.testA(true), “false”);

　　}

　　}

　　通过这个测试用例，我们就可以很容易的发现方法中的那个空指针错误。从这个例子来看，这个方法非常简单，因为它的圈复杂度只有2 ，像我们有些系统中某些方法的圈复杂度值高达150左右，那么你还能这么容易的发现你的程序缺陷吗?按理论值来算的话，你需要编写150个测试用例才能完成每个基本分支的测试。为什么要TDD模式开发?为什么要求大家都写单元测试?为什么评估软件质量要用覆盖率来评估?归根结底一句话：降低代码复杂度才能保证软件质量。

　　推荐大家使用圈复杂度计算的工具JavaNCSS，可以生成html报告。PMD等工具都可以评估代码复杂度。

　　在持续集成环境中，随时间变化评估方法的复杂度是很有必要的。如果某一方法的圈复杂度值在不断增长，那么您有两个响应选择：

　　1、确保相关测试用例的路径覆盖率是否覆盖到方法中所有的路径。

　　2、重构方法，降低长期维护风险。

原文转自：http://www.kuqin.com/software-engineer/20090321/41733.html