FreeOZ论坛

标题: 重构技术 Refactoring- Use PMD to start [打印本页]

作者: hoopoos 时间: 6-6-2008 19:02
标题: 重构技术 Refactoring- Use PMD to start
发一个以前在itpub发的旧帖子，公司里做重构的研究时候自己写的。

=====================================================================================================
最近在重构产品代码，下载了PMD，挺好用的，推荐给大家

重构的主要目的是，
1，消灭duplicated code，因为这是bug隐患之一，support team常常修掉了某处的bug，但是因为在另外的地方还有同样的复制代码。即使找到了复制代码，也增加了维护的cost。
2，premote loose coupling, program to interface。这些措施增强了系统的flexibility，降低来将来的维护cost。
3，refactor to patterns，应用恰当的模式并不一定是立竿见影的效果，但是还是增强了系统的可维护性。

PMD的作用就是分析出代码库的duplicated code，tight coupling，program to implementation等等不良的设计，帮助我们确定好重构的scope，否则，面对成千上万个包，重构将无从下手

http://pmd.sourceforge.net/

PMD scans Java source code and looks for potential problems like:

Possible bugs - empty try/catch/finally/switch statements
Dead code - unused local variables, parameters and private methods
Suboptimal code - wasteful String/StringBuffer usage
Overcomplicated expressions - unnecessary if statements, for loops that could be while loops
Duplicate code - copied/pasted code means copied/pasted bugs

当然，PMD做的很多事情，类似于Code CVS Commit前的validation，不良的代码风格等等。不过，最重要的还是
duplicate code和tight coupling，鉴于这是个opensource project，并且本身也采用了便于扩展的rule设计，你可以写自己的rule，比如不许定义变量为f**k ：），然后配置到可定制的ruleset xml里去。已经由PMD实现的ruleset是
http://pmd.sourceforge.net/rules/index.html

要实现高质量的代码，不能单纯依赖developer的自觉，一个iterative的refactoring是必要的。始终让低稳定性的模块依赖于高稳定性的模块，最终实现高效灵活的产品。Nice architecture=Good production.

作者: langchu 时间: 11-6-2008 15:43
标题: 回复 #1 hoopoos 的帖子

作者: felix100 时间: 21-6-2009 02:42
感觉PMD误报比较多，我比较烦它的报告。不过它检查copy/paste这个功能挺好。

大部分时候我用FindBug为主，简单好用，用PMD为辅助。

总体来说PMD比较powerful。

作者: yuba 时间: 21-6-2009 13:12
对于只写新代码，不改旧代码的理想开发方式

这个东西的用处没那么大

作者: procoder 时间: 21-6-2009 13:15
重构的关键是编写Unit Test。

作者: felix100 时间: 21-6-2009 15:53
其实大部分公司都不会做refactoring的，从管理层的角度看不到value。

作者: valpa 时间: 21-6-2009 16:13
重构是非常重要的，value很大

作者: felix100 时间: 21-6-2009 16:27

原帖由 valpa 于 21-6-2009 16:13 发表

 登录/注册后可看大图

重构是非常重要的，value很大

I can only say you come from technical perspective.

作者: stgeorge 时间: 21-6-2009 17:34
基本不做refactoring,
重构成本非常大。
首先要有unit testing 支持，unit testing 搭建环境，维护比较费时间。
然后写mock代码，
用CC进行check in build>
成本太高了。
必须要有牛人，才能支持。
而且对team member的要求也非常高。

作者: 清风不写字 时间: 21-6-2009 18:48
我们是XP开发方式，经常重构，unit test 都是最初开发就写好的，很少为了重构再写unit test。
代码提交前要在本地运行一遍大部分的单元测试
提交后测试服务器隔几个小时自动进行一遍check in build，并运行全部的测试。
大家习惯了就好了，没感觉重构有多麻烦。

作者: yuba 时间: 21-6-2009 19:05

原帖由 清风不写字 于 21-6-2009 18:48 发表

 登录/注册后可看大图

我们是XP开发方式，经常重构

"Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal non-functional properties of the software"

XP方式的开发，绝大多数情况下，对代码的改动并不属于refactoring的范畴

作者: 清风不写字 时间: 21-6-2009 20:41
标题: 回复 #11 yuba 的帖子
可能我刚才没说清楚。
我说的重构就是在为了提高代码质量和重用性的非功能性改动。
有时候是在要对某部分添加新功能顺便先对需要重构的老代码进行重构，有时候就是纯粹为了提高某些老模块的代码质量而重构。
可能因为我们公司做的是自己的产品，重构从长远来说也是划算的吧。

作者: yuba 时间: 21-6-2009 21:07
标题: 回复 #12 清风不写字的帖子
这样啊

可能是过于突出xp，造成了我的误解

作者: felix100 时间: 21-6-2009 21:53

原帖由 清风不写字 于 21-6-2009 20:41 发表

 登录/注册后可看大图

可能我刚才没说清楚。
我说的重构就是在为了提高代码质量和重用性的非功能性改动。
有时候是在要对某部分添加新功能顺便先对需要重构的老代码进行重构，有时候就是纯粹为了提高某些老模块的代码质量而重构。
可能因为我们公司做的是自己的产品，重构从长远来说也是划算的吧

产品的话，refactoring还是有一些value的。
项目的话，基本上没有老板会去做。项目维护到一定时间（五年到十年），就重做或被新的项目代替。

作者: valpa 时间: 22-6-2009 14:10

原帖由 felix100 于 21-6-2009 16:27 发表

 登录/注册后可看大图

I can only say you come from technical perspective.

no, from business view

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/)