重构，是否适合“当前”开发模式？

    当我在读MF的《重构》时产生了这样的疑问。它是否适合？
     这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。
      不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。

评论

56 楼 iaimstar 2009-06-23  

重构
你接手了一个项目，或者模块，看见一堆想杀人的代码，在可预计的时间范围内你将会多次被拖入这个坑
于是重构之，即便不是为了让别人不死，至少自己不能死

55 楼 treblesoftware 2009-06-22  

抛出异常的爱 写道

treblesoftware 写道

    当我在读MF的《重构》时产生了这样的疑问。它是否适合？
     这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。
      不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。

我又仔细的看了一次的主贴.......
你说的 一个功能一个模块.....
是公司规定
是不利于重构的规定之一.

当你的代码中有很强大的逻辑关系时
很多很严格的条件约束时
你会发现
你的代码很难修正
所以我常在不维反公司规定的条件下
把尽量重复 的代码 推到对应的 bean
(Entity)中,让这个bean 除了set get 再多些能力
如果是个更公用的方法就推到tools中去
还有大的entity 拆成多个bean 可以更好的减少代码.
还有很多很多方式
并不一定要把重构里所有的条件作到100%
要把你的代码作的更好....
至少要比重构之前好点吧.

读过写过上千行的一个方法后再回来讨论重构会更有意义的多.

谢谢您用心的解答。您的方法有点OO的感觉，跟我说的那种“一个功能一个模块”有些不同，不过您的方法的确是个好方法 谢谢。

54 楼 treblesoftware 2009-06-22  

palmer 写道

我想 重构不是目的， 而是方法。
重构是不可避免的。

重构的前提，是可测试性。
而 重构 这本书，是如何实现＂可测试性＂。
你不可能 很简单的把一个没有提前考虑可测试性 的项目，变成可以 方便的重构的。 所以本书 从最最 原始的例子开始， 告诉你 如何去实现一个可测试性的项目，有了这个前提， 才有了可重构的项目.


重构 给出的例子 是太简单的例子， 他是说明对于很初级的程序员，也能够很好的运用TDD。我想MF 的意思不是让大家都按照这个顺序来设计项目。   他是例子来说明一个思想。



因此最后总结一下:
重构不是目的， 而是方法。

重构不仅是一个方法， 更重要的是一个思想， 或者说思维方式。

您的总结很好，谢谢了。

53 楼 logicgate 2009-06-22  

抛出异常的爱 写道

读过写过上千行的一个方法后再回来讨论重构会更有意义的多.

同意。没有经过病痛的折磨，是不会理解保健的重要性的。

52 楼 抛出异常的爱 2009-06-22  

treblesoftware 写道

    当我在读MF的《重构》时产生了这样的疑问。它是否适合？
     这里为了减少争议，我说明一些大概的细节。一个系统在SPRING+STRUTS2+HBIERBATE下，在框架的范围内开发。严格的分层，各层之间使用IOC进行解偶，而且，每一个功能，写一个模块。而且，各各模块之间相对独立，没有父类，子类。最多只是引用一些公共包中的方法（比如：取得当前时间，等等）。在这样的情况下，我感觉使用重构的意义不大，如果为了重构而重构，明显会降低编码的速度和效率。因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。
      不知道大家怎么看这个问题。请大家在文章范围内讨论，勿夸出范围，谢谢。

我又仔细的看了一次的主贴.......
你说的 一个功能一个模块.....
是公司规定
是不利于重构的规定之一.

当你的代码中有很强大的逻辑关系时
很多很严格的条件约束时
你会发现
你的代码很难修正
所以我常在不维反公司规定的条件下
把尽量重复 的代码 推到对应的 bean
(Entity)中,让这个bean 除了set get 再多些能力
如果是个更公用的方法就推到tools中去
还有大的entity 拆成多个bean 可以更好的减少代码.
还有很多很多方式
并不一定要把重构里所有的条件作到100%
要把你的代码作的更好....
至少要比重构之前好点吧.

读过写过上千行的一个方法后再回来讨论重构会更有意义的多.

51 楼 palmer 2009-06-22  

我想 重构不是目的， 而是方法。
重构是不可避免的。

重构的前提，是可测试性。
而 重构 这本书，是如何实现＂可测试性＂。
你不可能 很简单的把一个没有提前考虑可测试性 的项目，变成可以 方便的重构的。 所以本书 从最最 原始的例子开始， 告诉你 如何去实现一个可测试性的项目，有了这个前提， 才有了可重构的项目.


重构 给出的例子 是太简单的例子， 他是说明对于很初级的程序员，也能够很好的运用TDD。我想MF 的意思不是让大家都按照这个顺序来设计项目。   他是例子来说明一个思想。



因此最后总结一下:
重构不是目的， 而是方法。

重构不仅是一个方法， 更重要的是一个思想， 或者说思维方式。

50 楼 xuzhfa123 2009-06-20  

treblesoftware 写道

luckaway 写道

被编码是时打断，重构也算是一种编码！！！

重构是是一种技能！

并不是因为重构而重构，重构的目的是为了让软件变的可扩展、可维护！

在框架内，一个功能写一个模块实现，而且分层很严格。突然觉得就算需求变动了，改起来也挺方便。所以才产生了这样的疑问。谢谢您的回帖。

每个功能模块都有DRUP操作,像你说的,这样下去不就有了code smell,如果修改一个地方就全得跟着改,你认为不需要重构吗.不是有了SSH,严格分层了就不需要重构了.

49 楼 treblesoftware 2009-06-19  

murainwood 写道

treblesoftware 写道

murainwood 写道treblesoftware 写道
murainwood 写道风清云淡 写道
无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛


他没能理解我的意思，你也一样。请仔细读一读我前面写的文章。

扯吧，以为SSH就天下无敌，不要重构了。


我写的很清楚，以SSH2为例子。JAVA里面框架很多，每种情况都不一样，我没谈别的，只谈SSH2，你不要故意转移话题。在SSH2下面，还有不同的编码风格，以及不同的设计风格，这个本来就很容捅，我这里在拿TS开发指导思想来说。我说的重构只是一种大概的思想，《重构》这本书上有许多重构的方法，我的意思是：这些方法并不一定都适用于现在的所有东西，所以我才说，重构是否完全适合现在的开发模式。MF当时写这书的时候，还没有SSH吧？或者SSH没有现在这么流行吧？任何系统当然需要重构。

不说什么了，确实是典型的不知者无畏。

随便你怎么想吧。我也不说了。本身就没什么好说的。累代码，本来就没出路可寻。

48 楼 murainwood 2009-06-19  

treblesoftware 写道

murainwood 写道treblesoftware 写道
murainwood 写道风清云淡 写道
无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛


他没能理解我的意思，你也一样。请仔细读一读我前面写的文章。

扯吧，以为SSH就天下无敌，不要重构了。


我写的很清楚，以SSH2为例子。JAVA里面框架很多，每种情况都不一样，我没谈别的，只谈SSH2，你不要故意转移话题。在SSH2下面，还有不同的编码风格，以及不同的设计风格，这个本来就很容捅，我这里在拿TS开发指导思想来说。我说的重构只是一种大概的思想，《重构》这本书上有许多重构的方法，我的意思是：这些方法并不一定都适用于现在的所有东西，所以我才说，重构是否完全适合现在的开发模式。MF当时写这书的时候，还没有SSH吧？或者SSH没有现在这么流行吧？任何系统当然需要重构。

不说什么了，确实是典型的不知者无畏。

47 楼 treblesoftware 2009-06-19  

murainwood 写道

treblesoftware 写道

murainwood 写道风清云淡 写道
无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛


他没能理解我的意思，你也一样。请仔细读一读我前面写的文章。

扯吧，以为SSH就天下无敌，不要重构了。

我写的很清楚，以SSH2为例子。JAVA里面框架很多，每种情况都不一样，我没谈别的，只谈SSH2，你不要故意转移话题。在SSH2下面，还有不同的编码风格，以及不同的设计风格，这个本来就很容捅，我这里在拿TS开发指导思想来说。我说的重构只是一种大概的思想，《重构》这本书上有许多重构的方法，我的意思是：这些方法并不一定都适用于现在的所有东西，所以我才说，重构是否完全适合现在的开发模式。MF当时写这书的时候，还没有SSH吧？或者SSH没有现在这么流行吧？任何系统当然需要重构。

46 楼 murainwood 2009-06-19  

treblesoftware 写道

murainwood 写道风清云淡 写道
无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛


他没能理解我的意思，你也一样。请仔细读一读我前面写的文章。

扯吧，以为SSH就天下无敌，不要重构了。

45 楼 treblesoftware 2009-06-19  

风清云淡 写道

无语了，就LZ对重构的认识把我雷到了。
哎，又见一个无知者无畏

请好好的读一读我之前写的文章，你没有能理解我的意思。

44 楼 treblesoftware 2009-06-19  

murainwood 写道

风清云淡 写道

无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛

他没能理解我的意思，你也一样。请仔细读一读我前面写的文章。

43 楼 murainwood 2009-06-19  

风清云淡 写道

无语了，就LZ对重构的认识把我雷到了。哎，又见一个无知者无畏

呵呵，一个不知道啥大学的大三小朋友，能懂个啥？
要理解一下嘛

42 楼 风清云淡 2009-06-19  

无语了，就LZ对重构的认识把我雷到了。
哎，又见一个无知者无畏

41 楼 ywbanm 2009-05-05  

重构不应该是一个单独来做的事情，
重构应该存在于你写下每一行代码时。

整洁不在于打扫而在于保持。

40 楼 matt.u 2009-04-28  

logicgate 写道

重构是一种乐趣，就像把一个杂乱无章的房间收拾得井井有条一样，看着都是一种享受。如果你不能把写程序当成一种艺术来看，你就体会不到这种乐趣。

同感！我也是把编程当成一种艺术，每当设计完一些模块时，都会感觉一种很有成就的感觉。呵呵，有点自以为是。
当然不是所有项目都能让我们把他当艺术那么追求完美地来实现。

我一直认为如果一个项目不适时的进行重构，那这个项目是会慢慢失去其生命力的。一个到处都是bad smell的项目，还有谁愿意去维护，还有谁愿意去精益求精的把他做好呢？（当然如果是交了货就收钱，而且不用修改不用维护的话。我也可以做到功能第一、实现第二。）

重构不会因为你使用了任何框架就不需要了，难道你的业务实现就只得几行；你的业务需求就不会有变化；你的代码质量或者逻辑就完美无缺？

39 楼 pipilu 2009-04-26  

kiol 写道

这个问题好奇怪啊,难道楼主一开始就能把代码写完美?
还是认为只有架构的改变才是重构?

我也觉得很奇怪，而且并不是只有业务有变化了才有重构。哪怕需求从来就没变过，代码从无到有的过程也穿插着很多的重构。除非谁的开发过程是：先深思熟虑，然后一气呵成。

38 楼 treblesoftware 2009-04-24  

weid0907 写道

总有人提出架构的新思想。
开发的时候，由一个不通用的类发展为可复用了，开始只是设计了一个具体类，而后来需要设计为接口；一段代码在初期直接写在对象内，后来随着业务的扩展，发现这个功能可以被多个模块共用，于是新建一个对象单独封装了这个类；一组类结构不合理，依据设计模式原理进行修改，便于维护。。。这些都需要重构来完成，而与你所用的框架无关。甚至说，在精通框架的基础下，进行自编写框架功能，使得代码减少对框架的依赖，那么你的产品又会更便于迁移，这也需要重构。

重构现象是客观存在的，除非你刻意不去做，否则你必然会用到重构。

对！您的回复到是说到点子上了。谢谢！

37 楼 weid0907 2009-04-24  

总有人提出架构的新思想。
开发的时候，由一个不通用的类发展为可复用了，开始只是设计了一个具体类，而后来需要设计为接口；一段代码在初期直接写在对象内，后来随着业务的扩展，发现这个功能可以被多个模块共用，于是新建一个对象单独封装了这个类；一组类结构不合理，依据设计模式原理进行修改，便于维护。。。这些都需要重构来完成，而与你所用的框架无关。甚至说，在精通框架的基础下，进行自编写框架功能，使得代码减少对框架的依赖，那么你的产品又会更便于迁移，这也需要重构。

重构现象是客观存在的，除非你刻意不去做，否则你必然会用到重构。