利用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的规定。 

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

评论

15 楼 cantellow 2011-05-31  

hxl1013 写道

对于一个开发新人来说，如果进行代码质量复查，LZ觉得有没有一些简单的规则可遵循

个人觉得，如果你用findbugs找出的问题你都理解并改正了，那么就可以组织一场codereview，把一些大牛请过来给新人指导指导，我觉得，关键还在于自身，多看一些凯源代码和一些书籍，来提高对代码的敏感度以及审美感，我自己目前也努力在作者方面的一些工作。

14 楼 hxl1013 2011-05-31  

对于一个开发新人来说，如果进行代码质量复查，LZ觉得有没有一些简单的规则可遵循

13 楼 huangheyuan1229 2011-01-28  

又学到了很多Eclipse的插件

12 楼 cantellow 2010-11-04  

黑暗浪子 写道

随便问一句，兄弟，你懂敏捷吗？

不懂，你用一句话概括

11 楼 黑暗浪子 2010-11-04  

随便问一句，兄弟，你懂敏捷吗？

10 楼 黑暗浪子 2010-11-04  

liangguanhui 写道

黑暗浪子 写道

liangguanhui 写道

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

codereview 可以拿hudson自动化？可不可以详细说说？

你所列出的checkstyle，findbug等插件，hudson都可以支持并结合ant，maven自动运行。

这种codereview比得上人工的code review？

质量比人工高，效率比人工高，时间比人工花的少。如果是老板，会怎么想？

9 楼 liangguanhui 2010-11-03  

黑暗浪子 写道

liangguanhui 写道

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

codereview 可以拿hudson自动化？可不可以详细说说？

你所列出的checkstyle，findbug等插件，hudson都可以支持并结合ant，maven自动运行。

这种codereview比得上人工的code review？

8 楼 cantellow 2010-11-03  

黑暗浪子 写道

cantellow 写道

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

hudson是不是只支持svn，像IBM的ClearCase它支持吗？

这年头有谁还用clearcase啊？时代在前进，现在都流行git了。svn都快被淘汰了。

别这么说嘛，现在还有好多公司都用CC呢。

7 楼 黑暗浪子 2010-11-03  

cantellow 写道

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

hudson是不是只支持svn，像IBM的ClearCase它支持吗？

这年头有谁还用clearcase啊？时代在前进，现在都流行git了。svn都快被淘汰了。

6 楼 黑暗浪子 2010-11-03  

liangguanhui 写道

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

codereview 可以拿hudson自动化？可不可以详细说说？

你所列出的checkstyle，findbug等插件，hudson都可以支持并结合ant，maven自动运行。

5 楼 cantellow 2010-11-03  

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

hudson是不是只支持svn，像IBM的ClearCase它支持吗？

4 楼 liangguanhui 2010-11-03  

黑暗浪子 写道

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

codereview 可以拿hudson自动化？可不可以详细说说？

3 楼 黑暗浪子 2010-11-03  

浪费时间～codereview这种事情，最好能自动化，让hudson这样的东东来解决。光靠人力，开发进度会严重滞后的。

2 楼 cantellow 2010-11-02  

liangguanhui 写道

其实上面说的codereview，质量管理之类的，都必须建立在一个关键前提上：项目有这方面的“预算”，当然这里的预算除了人力，还应该有时间。

你需要说服你的老板觉得这样做是有收益，而不仅仅是成本的支出。否则一切皆是浮云……

嗯，你说的相当有理，写文章的时候这方面确实没怎么考虑。
看来一切都建立在利益上面。
真正把程序员当一回事的只有Google这种大牛了。

1 楼 liangguanhui 2010-11-02  

其实上面说的codereview，质量管理之类的，都必须建立在一个关键前提上：项目有这方面的“预算”，当然这里的预算除了人力，还应该有时间。

你需要说服你的老板觉得这样做是有收益，而不仅仅是成本的支出。否则一切皆是浮云……