重构，是否适合“当前”开发模式？
当我在读MF的《重构》时产生了这样的疑问。它是否适合？
这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。
不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。
每个功能模块都有DRUP操作,像你说的,这样下去不就有了code smell,如果修改一个地方就全得跟着改,你认为不需要重构吗.不是有了SSH,严格分层了就不需要重构了.
我又仔细的看了一次的主贴.......
你说的 一个功能一个模块.....
是公司规定
是不利于重构的规定之一.
当你的代码中有很强大的逻辑关系时
很多很严格的条件约束时
你会发现
你的代码很难修正
所以我常在不维反公司规定的条件下
把尽量重复 的代码 推到对应的 bean
(Entity)中,让这个bean 除了set get 再多些能力
如果是个更公用的方法就推到tools中去
还有大的entity 拆成多个bean 可以更好的减少代码.
还有很多很多方式
并不一定要把重构里所有的条件作到100%
要把你的代码作的更好....
至少要比重构之前好点吧.
读过写过上千行的一个方法后再回来讨论重构会更有意义的多.
我又仔细的看了一次的主贴.......
你说的 一个功能一个模块.....
是公司规定
是不利于重构的规定之一.
当你的代码中有很强大的逻辑关系时
很多很严格的条件约束时
你会发现
你的代码很难修正
所以我常在不维反公司规定的条件下
把尽量重复 的代码 推到对应的 bean
(Entity)中,让这个bean 除了set get 再多些能力
如果是个更公用的方法就推到tools中去
还有大的entity 拆成多个bean 可以更好的减少代码.
还有很多很多方式
并不一定要把重构里所有的条件作到100%
要把你的代码作的更好....
至少要比重构之前好点吧.
读过写过上千行的一个方法后再回来讨论重构会更有意义的多.
谢谢您用心的解答。您的方法有点OO的感觉，跟我说的那种“一个功能一个模块”有些不同，不过您的方法的确是个好方法
谢谢。
56 楼 iaimstar 2009-06-23 重构
你接手了一个项目，或者模块，看见一堆想杀人的代码，在可预计的时间范围内你将会多次被拖入这个坑
于是重构之，即便不是为了让别人不死，至少自己不能死
