java 代码质量管理

怎样辨别一个项目代码写得好还是坏？优秀的代码和腐化的代码区别在哪里？怎么让自己写的代码既漂亮又有生命力？接下来将对代码质量的问题进行一些粗略的介绍。也请有过代码质量相关经验的朋友提出宝贵的意见。

代码质量所涉及的5个方面，编码标准、代码重复、代码覆盖率、依赖项分析、复杂度分析。这5方面很大程序上决定了一份代码的质量高低。我们分别来看一下这5方面：

编码标准：这个想必都很清楚，每个公司几乎都有一份编码规范，类命名、包命名、代码风格之类的东西都属于其中。

代码重复：顾名思义就是重复的代码，如果你的代码中有大量的重复代码，你就要考虑是否将重复的代码提取出来，封装成一个公共的方法或者组件。

代码覆盖率：测试代码能运行到的代码比率，你的代码经过了单元测试了吗？是不是每个方法都进行了测试，代码覆盖率是多少？这关系到你的代码的功能性和稳定性。

依赖项分析：你的代码依赖关系怎么样？耦合关系怎么样？是否有循环依赖？是否符合高内聚低耦合的原则？通过依赖项分析可以辨别一二。

复杂度分析：以前有人写的程序嵌套了10层 if else你信吗？圈复杂度之高，让人难以阅读。通过复杂度分析可以揪出这些代码，要相信越优秀的代码，越容易读懂。

上面解释了代码质量相关的5个方面，在实际开发环境中，已经有很多工具为我们解决以上5个方面的问题，下列5个eclipse插件分别对这5个问题有很好的支持：

编码标准：CheckStyle 插件URL：http://eclipse-cs.sourceforge.net/update/

代码重复：PMD的CPD 插件URL：http://pmd.sourceforge.net/eclipse/

代码覆盖率：Eclemma 插件URL：http://update.eclemma.org

依赖项分析：JDepend 插件URL：http://andrei.gmxhome.de/eclipse/

复杂度分析：Eclipse Metric 插件URL：http://metrics.sourceforge.net/update

注：某些插件需要科学上网才能更新

编码标准（CheckStyle的使用）

在eclipse上安装好了CheckStyle插件后，我们来建一个类用它跑一下。这个类很简单，一个常见的用户实体，包含了id，用户名、密码、邮件等属性，并包含get set方法，一个标准的POJO。运行CheckStyle检查一下：

一个我们平时再普通不过的一个类，被checkstyle弄出这么多问题，情何以堪，我们来看看究竟是什么情况？

看一下这些警告信息：

line 1、，说缺少package-info.java文件。

line 2、，说第一句注释要以“.”结尾。

line 30、，缺少java doc注释。

line 35、，getId不是继承的方法，必须指定abstract,final或空。另外也缺少java doc注释。

这个类基本就这四类毛病，缺少package-info.java文件，这个文件是做什么的呢？他是用来描述包注释的类，有一定的特殊性，要想详细了解请百度。如果对你的项目没有太大的影响，可以忽略它。配置CheckStyle的方法我们等会再说。第一句注释要以“.”结尾，这看你的习惯，你确定需要这个，你就保留，不需要就忽略。缺少java doc，对于java类的属性来说，注释是必要的，所以这个要保留。不是继承的方法，需要加上final关键字，如果你有这个习惯，就保留，反之忽略。

我们这里只是建立了一个最简单的类用CheckStyle来检查，随着你的类代码越来越多，逻辑越来越复杂，CheckStyle能检查出来的毛病也越来越多。常见的CheckStyle错误有这些：

1.Type is missing a javadoc commentClass
缺少类型说明
2.“{” should be on the previous line
“{” 应该位于前一行
3.Methods is missing a javadoc comment
方法前面缺少javadoc注释
4.Expected @throws tag for “Exception”
在注释中希望有@throws的说明
5.“.” Is preceeded with whitespace “.”
前面不能有空格
6.“.” Is followed by whitespace“.”
后面不能有空格
7.“=” is not preceeded with whitespace
“=” 前面缺少空格
8.“=” is not followed with whitespace
“=” 后面缺少空格
9.“}” should be on the same line
“}” 应该与下条语句位于同一行
10.Unused @param tag for “unused”
没有参数“unused”，不需注释
11.Variable “CA” missing javadoc
变量“CA”缺少javadoc注释
12.Line longer than 80characters
行长度超过80
13.Line contains a tab character
行含有”tab” 字符
14.Redundant “Public” modifier
冗余的“public” modifier
15.Final modifier out of order with the JSL
suggestionFinal modifier的顺序错误
16.Avoid using the “.*” form of import
Import格式避免使用“.*”
17.Redundant import from the same package
从同一个包中Import内容
18.Unused import-java.util.list
Import进来的java.util.list没有被使用
19.Duplicate import to line 13
重复Import同一个内容
20.Import from illegal package
从非法包中 Import内容
21.“while” construct must use “{}”
“while” 语句缺少“{}”
22.Variable “sTest1” must be private and have accessor method
变量“sTest1”应该是private的，并且有调用它的方法
23.Variable “ABC” must match pattern “^[a-z][a-zA-Z0-9]*$”
变量“ABC”不符合命名规则“^[a-z][a-zA-Z0-9]*$”
24.“(” is followed by whitespace
“(” 后面不能有空格
25.“)” is proceeded by whitespace
“)” 前面不能有空格

可以看出CheckStyle检查出来的问题，大多是编码规则以及风格上的问题，这是编写高质量代码最基本的。值得注意的是，我们将一些优秀的开源代码用CheckStyle来检查也会检查出不少问题，这不能不说这些开源不优秀，而是每个公司组织有自己的编写规范度，这个度既可以减少程序员的工作量又可以让代码的可读性合格，但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准，而是通过配置，制定适合自己的编码规则。

自定义CheckStyle规则：

打开CheckStyle配置，新建一个配置，选择外部配置文件。在这之前最好导出一个eclipse自带的checkstyle配置文件（sun_checks.xml），然后重命名作为一个外部的配置导进去，这么做的目的是导入之后可以修改相应的配置，达到自定义配置的目的（因为eclipse自带的配置是加锁的，不能修改）。导入之后，点击右边的“Configure”进行编辑。

先去掉缺少package-info.java文件的提示

再将第一句注释要以“.”结尾这个规则去掉，双击“Style javadoc”，将窗口内“checkFirstSentence”勾选去掉。

对于实体类，属性有了注释，get set方法也不需要注释了，双击“Method javadoc”将allowMissingPropertyJavadoc勾选中。

“getId不是继承的方法，必须指定abstract,final或空”，如果你懒得在方法上加“final”，这条规则也可以去掉。

如果你不想每一个参数都加“final”，还需要把参数的final规则去掉：

另外还有一个错误“'id' hides a field.”，原因是方法的参数和类里面定义的域重名了，但使用eclipse生成的get set方法都会这样，所以可以忽略此项。

至此我们再使用checkstyle检查一篇，发现仅剩下属性缺少注释这个警告。

对每个属性加上java doc注释，所有问题都清除了。以此类推，解决checkstyle问题的方法就是：1、按规则解决代码问题；2、如果觉得这个问题对你的项目质量影响不大，则可以忽略它。

代码重复（PMD的CPD的使用）

对于多人开发的项目，难以避免出现重复代码的问题，尽管我们尽量对共用的代码进行了封装，但随着需求的增加、人员技术水平差异、沟通不足等原因，重复代码会越来越多。这不仅严重影响代码质量，也无形中增加了代码量。

注：精简的程序和高复用度的代码是我们一直追求的目标。

PMD的CPD工具就是为检查重复代码而生的。右键项目—>PMD—->Find Suspect Cut and Paste,执行重复代码检查：

检查出来的重复代码，可以双击查看。然后根据业务逻辑以及代码特征，决定要不要做封装、怎么封装。

代码覆盖率（Eclemma的使用）

一份质量合格的代码，不仅包含功能程序本身也包含了对应的测试代码，Eclemma插件可以用来统计测试代码覆盖整体代码中的比率，以此来评估代码的功能性和稳定性。

使用Junit编写好测试用例之后，右键Coverage As—>Junit Test，运行测试用例，Eclemma会统计出相关的代码覆盖率：

根据这个结果，你可以看出自己编写的测试用例覆盖到了那些代码，而没有覆盖到的代码，则有可能成为代码质量的盲区。

依赖项分析（JDepend的使用）

随着程序业务逻辑的增加，代码的依赖关系也变的越来越复杂，JDepend插件可以统计包和类的依赖关系，分析出程序的稳定性、抽象性和是否存在循环依赖的问题。右键包—>Run JDepend Analysis：

看一下这几项指标：

CC（Number of Classes)

被分析package的具体和抽象类（和接口）的数量，用于衡量package的可扩展性。如果一个类中实现了其他类，如实现了监听类，则监听类的数目也记录在此。

AC（Abstract classes）

抽象类和接口的数量。

Ca（Afferent Couplings)

依赖于被分析package的其他package的数量，用于衡量pacakge的职责。即有多少包调用了它。

Ce（Efferent Couplings)

被分析package的类所依赖的其他package的数量，用于衡量package的独立性。即它调用了多少其他包。

A（Abstractness)

被分析package中的抽象类和接口与所在package所有类数量的比例，取值范围为0－1。

I（Instability)

I＝Ce/（Ce＋Ca），用于衡量package的不稳定性，取值范围为0－1。I＝0表示最稳定，I＝1表示最不稳定。即如果这个类不调用任何其他包，则它是最稳定的。

D（Distance)

被分析package和理想曲线A＋I＝1的垂直距离，用于衡量package在稳定性和抽象性之间的平衡。理想的package要么完全是抽象类和稳定（x＝0，y＝1），要么完全是具体类和不稳定（x＝1，y＝0）。取值范围为0－1，D＝0表示完全符合理想标准，D＝1表示package最大程度地偏离了理想标准。即你的包要么全是接口，不调用任何其他包（完全是抽象类和稳定），要么是具体类，不被任何其他包调用。

Cycle

循环依赖的数量。

有个这个报告我们就可以有针对性的对代码进行设计和重构。

复杂度分析（Metrics的使用）

对于阅读代码的人来说，越简单的代码越好理解和维护，如果你的代码阅读起来很费劲或者你自己过段时间后再来看都看不懂，你就得想办法解决下代码的复杂度问题了。Metrics插件可以帮你做到这点。

首先在Java透视图下右键一个项目—->Properties，选择Metrics，勾选Enble Metrics。