1.糟糕的复杂度分布
文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们，
且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试
最近一直纠结这个要不要分享出来，毕竟只是一个工具的使用，而且自己使用起来效果不是很好，不是工具不好，是水土不服。个人感觉这个工具还是不错的。
Sonar 是一个用于代码质量管理的开源平台，用于管理源代码的质量，可以从七个维度检测代码质量
通过插件形式，可以支持包括 java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy 等等二十几种编程语言的代码质量管理与检测
Developers' Seven Deadly Sins
1.糟糕的复杂度分布
文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们，
且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试
2.重复
显然程序中包含大量复制粘贴的代码是质量低下的
sonar 可以展示源码中重复严重的地方
3.缺乏单元测试
sonar 可以很方便地统计并展示单元测试覆盖率
4.没有代码标准
sonar 可以通过 PMD,CheckStyle,Findbugs 等等代码规则检测工具规范代码编写
5.没有足够的或者过多的注释
没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降
而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷
6.潜在的 bug
sonar 可以通过 PMD,CheckStyle,Findbugs 等等代码规则检测工具检测出潜在的 bug
7.糟糕的设计（原文 Spaghetti Design，意大利面式设计）
通过 sonar 可以找出循环，展示包与包、类与类之间的相互依赖关系
可以检测自定义的架构规则
通过 sonar 可以管理第三方的 jar 包
可以利用 LCOM4 检测单个任务规则的应用情况
检测耦合
通过 sonar 可以有效检测以上在程序开发过程中的七大问题。
SonarQube 安装
配置 sonar、jenkins 进行持续审查
如果配置数据库的话，可以看到代码质量的趋势图。如果有单元测试，也可以看到单元测试代码覆盖率。
OK, 开始：
在浏览器中访问: http://localhost:9000/ ，运行界面如下：
不要紧张，技术债务数据看起来比较吓人，但是里面很多问题都是规范性问题，语法问题，很多问题是可以接受的。
蓝色的数据差不多都是可以点击的，你可以看到具体的细节，定位到文件，代码的行。
这里没有单元测试的代码覆盖率，因为没有做。
点击阻断。（确切的说应该是 block，你可以看到如下图：）
点开某个文件,具体信息：
这个平台可以统计单元测试的代码覆盖率，还可以装一些其他的代码检查的插件。也可以跟 jenkins 结合。
还可以自定义一些规则。
从图中可以看出，代码的质量很糟糕，重复的代码太多。而且代码及其不规范。
因为没法 push 开发去改进提高质量，领导也不重视，最后放弃了，这个尝试只是徒劳了。
因为制定 rule 要和开发的老大一条条敲定，根本就没机会跟开发的老大一起做这个事情，自己定义的又不被认可，最后这事不了了之了。
大家可以基于以下的例子来制定：
基于华为 Java 编程规范的 Eclipse checkStyle.xml
利用 Sonar 定制定义 JS 扫描规则
checkstyle rule 模板
小伙伴们，你们的代码如何测试的呢？ 开展得怎样？
