利用Eclipse插件提高代码质量

很少codereview，没有代码质量工具给予支持，同事之间的默认规则就是代码在此刻（对，是此刻）能够正确跑起来就算OK，如果你发现你正在经历上述情况，那么你应该好好考虑怎么提高代码的质量。

实际上在有些项目很少有人去关注这个，领导们也不会看你代码的风格，代码是否重复，依赖关系等等（这让我想起了《程序员之死》中提到的“某个架构很落后,技术很普通的产品却大卖”）。虽说领导强调把项目交给你，就要自己承担起责任。但是，试问如果碰到一大堆代码风格迥异，代码重复问题，你还会动手把它们整个重构一遍吗？可能别人会说，“这只是代码质量的问题，不是功能的问题，没什么，它不是能正确跑起来吗？其他都是小事”。事实上，是我也不会那么做，何况你还不能保证每行代码你都熟悉作者的意图，难免下手犹豫不决。所以，我想说的是，代码质量的提高，最好不要交给后来人，当一个项目刚刚完成，就务必要分配人员进行代码质量的管理。当然，更好的情况就是在编写代码时就注意，永远把问题解决在萌芽时期，就像TDD里说的一样，写一点测一点，那么我们也时刻要注意，写一点，就要进行一遍代码质量的管理。

       在网上看了一些文章之后，我所认为代码分析领域有“五大”：

1.       代码风格，就是编码风格标准，个人认为应该遵循sun提出的标准，避免个人风格的肆意发挥。

2.       代码重复，复制粘帖代码俗称“堆代码”，在重构领域，这也称为坏的味道。

3.       静态分析代码潜在BUG，使用一些工具来找出一些比较常见的错误类型如臭名昭著的null指针、忽略返回值、初始化之前读取字段、找出 hash equals 不匹配 、未使用的代码等等。

4.       代码覆盖率，在进行测试的时候，有一个参数我们必须要知道，那就是代码覆盖率，可能你的测试动作并没有覆盖所有的代码，这时候我们必须保持警惕。

5.       复杂度监控和依赖项分析，复杂度监控用来监控项目代码的数量，类的数量，包的数量等等各种参数，这有助于我们分析项目是否走进了复杂的死胡同。越是复杂的事情越要保持简单，简单既是美。依赖项分析能够帮助我们分析包之间的引用，如果依赖过多，应该保持警惕，记得设计模式几大原则之一的迪米特法则也也讲到了这一点，个人认为应该以其作为依赖项分析的目标。

 

下面看看对应的工具，这里说明一点，各种工具之间可能有交集，我只选取我感兴趣的部分：

代码风格	CheckStyle	http://eclipse-cs.sourceforge.net/update/	它的饼图看着不错
代码重复	PMD	http://pmd.sourceforge.net/eclipse/	PMD也有CheckStyle的功能
静态分析代码潜在BUG	FindBugs	http://findbugs.cs.umd.edu/eclipse	比较钟爱的一个插件，其总结的BUG模式也比较有趣
代码覆盖率	emma	http://update.eclemma.org/	Coverlipse也不错，能与junit很好的结合
复杂度监控和依赖项分析	metrics	http://metrics.sourceforge.net/update	Metrics都有这两种功能，但是 JDepend在包分析上更专业

 

上面说了使用工具进行代码质量的管理，代码管理也包括人工审查，不过这个要依靠个人的经验，凭借一双慧眼才行。另外，关于codereview，我在http://www.iteye.com/topic/767906上看到一篇最佳实践，这个比较严厉了，相信很多公司都不会这么干，不过可以学习借鉴：

1. 我们把 codereview 这个环节安排在开发单元测试完成后，提交给QA以前做这个工作。 
2. 必须硬性严格通过codereview，会让每个开发者打开自己的code，在多媒体会议室接受review， 参与者还有他的leader和相关架构人员， 
3. review result会提交给dev，然后dev再修改，再review，直到满意通过。 
4. 记住，一定要"硬性执行"codereview， 许多程序员天生的坏习惯，坚持三次review以后，dev就会有责任感，抛弃自己的陋习，完全遵守代码规范了【以后codereview的工作也就越来越快，因为大家都遵守这个规范了】。 
5. dev 根据review result 更新自己的代码后，必须完成单元测试，然后在接受codereview, codereview成功通过后，然后dev再申请 reviewer通知QA组开始测试。 
6. QA只接受codereviewer的测试申请【也就是说， QA接受不到 codereviewer的测试申请，是不会对相关项目做测试的，这就是硅谷硬性规范】 
7. 按照这个程序，有时候你会接近 零 bug。 
8. 你甚至可以把codereview 的复查功能添加到每天编译日程中，不满足规范的，就会导致daily build不成功，就找相关的dev，让其硬性完成code的规定。 

这个过程刚开始执行的时候，程序员会有抵制态度，但是一定要硬性执行，让高层参与，只要好硬性执行三次以后，以后会产生一个黄金项目。