很少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的规定。?
这个过程刚开始执行的时候,程序员会有抵制态度,但是一定要硬性执行,让高层参与,只要好硬性执行三次以后,以后会产生一个黄金项目。?
你需要说服你的老板觉得这样做是有收益,而不仅仅是成本的支出。否则一切皆是浮云……
你需要说服你的老板觉得这样做是有收益,而不仅仅是成本的支出。否则一切皆是浮云……
嗯,你说的相当有理,写文章的时候这方面确实没怎么考虑。
看来一切都建立在利益上面。
真正把程序员当一回事的只有Google这种大牛了。
codereview 可以拿hudson自动化?可不可以详细说说?
hudson是不是只支持svn,像IBM的ClearCase它支持吗?
codereview 可以拿hudson自动化?可不可以详细说说?
你所列出的checkstyle,findbug等插件,hudson都可以支持并结合ant,maven自动运行。
hudson是不是只支持svn,像IBM的ClearCase它支持吗?
这年头有谁还用clearcase啊?时代在前进,现在都流行git了。svn都快被淘汰了。
hudson是不是只支持svn,像IBM的ClearCase它支持吗?
这年头有谁还用clearcase啊?时代在前进,现在都流行git了。svn都快被淘汰了。
别这么说嘛,现在还有好多公司都用CC呢。
codereview 可以拿hudson自动化?可不可以详细说说?
你所列出的checkstyle,findbug等插件,hudson都可以支持并结合ant,maven自动运行。
这种codereview比得上人工的code review?
codereview 可以拿hudson自动化?可不可以详细说说?
你所列出的checkstyle,findbug等插件,hudson都可以支持并结合ant,maven自动运行。
这种codereview比得上人工的code review?
质量比人工高,效率比人工高,时间比人工花的少。如果是老板,会怎么想?
不懂,你用一句话概括
个人觉得,如果你用findbugs找出的问题你都理解并改正了,那么就可以组织一场codereview,把一些大牛请过来给新人指导指导,我觉得,关键还在于自身,多看一些凯源代码和一些书籍,来提高对代码的敏感度以及审美感,我自己目前也努力在作者方面的一些工作。