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

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

评论

16 楼 yuan 2009-04-22  

treblesoftware 写道

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

重构是在以不改变代码外在行为为前提的情况下，改善代码的内部结构。

好吧，我特意翻了一下重构这本书，Fowler说：
page i
重构一词非常清楚地说明了它自身的意义和价值：在不破坏可察功能的前提下，借由搬移、提炼、打散、凝聚…，改善事物的体质。
page xvi
所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

简单的想：既然这两句定义这么强调“不改变代码外在行为”，那我觉得无论在什么情况下，重构都是可以进行的吧。

15 楼 baseworld 2009-04-22  

不重构只有死

14 楼 lichuan 2009-04-22  

扎实编码，偷懒不好

13 楼 whaosoft 2009-04-22  

不好意思 其实我感觉你说的不对呢~@

12 楼 抛出异常的爱 2009-04-22  

chgle 写道

抛出异常的爱 写道

chgle 写道

框架定死在了SPRING+STRUTS2+HBIERBATE范围下，并严格按这个模式进行开发，还谈什么重构，剩下的仅仅是按业务修改的问题了，如果你满足于这样的现状，那么重构对于你来说确实是不合适

业务很简单么
业务不变化么
业务就不是代码组成的么

重构能重构的
把不能重构放在一边

重构=修改代码？说了是严格按SPRING+STRUTS2+HBIERBATE这个模式进行开发，但是往往复杂的系统会有自己额外的一些辅助框架和组件，或者是在SSH框架下进行扩展，这时在具体业务改变的时候重构的意义就体现出来了

重构是为了下回看到代码时不要捏着鼻子看.

另严格的瀑布式开发根本没有重构的必要性.

11 楼 Saito 2009-04-22  

Julien 写道

没干过活的人死也不相信需求会变

     之前没干过活.. 结果接了个私活 ..没把我搞死..

              算了. 以后还是洁身自好吧..不趟这趟浑水了..

10 楼 Saito 2009-04-22  

  从楼主的帖子中看出. 并没有提到 单元测试. 重构能够得以进行. 就是要有类似于这种测试框架的支持. 要不然. 重构是危险的. 没有保障的.

  当然. 更进一步的来说. 我们应该用TDD 来进行开发.并随时重构自己的程序. SSH为什么会那么能受大众喜欢. 有一个原因就是 他们易于测试. 这就易于重构我们的业务逻辑. 让我们的逻辑更加清晰. 更容易复用. 即使转手自己的工作. 别人也能只读我们的单元测试框架内的测试代码. 就能知道我们在做什么.  说白了. 我觉得我们是在挖井. 现在挖的过程是痛苦的. 等到一天业务发生改变. 就是你吃水的时候了.  

  有时候这样想. TDD + 重构有时候确实很难在公司. 企业内实行. 我觉得有一个原因就是我们程序员都有点急功近利. 说白了就是浮躁.( 当然包括我.) 觉得重构代码是件浪费时间的事. ( 这也包括我.) .就跟我们编码很少去想到 防御式编程是一样的. bug多多.唯完成功能是论. (这说的就是我.) .kent beck .martin fowler这种大师都在他的工具箱里有 重构 有 Junit . 我觉得我们更该有.. 再说了. 重构是需要经验的.不是看refactory就能学会的.  现在不去做. 什么时候去做? 趁现在还在学校. 把 TDD +refactory 装进自己的工具箱吧..   当然 我是准备这么做了..

9 楼 Julien 2009-04-22  

没干过活的人死也不相信需求会变

8 楼 scvptz 2009-04-22  

treblesoftware 写道

     因为我在编码时被打断会显的非常不爽，更别说在编码中进行TDD了。

看来楼主根本没有理解TDD的思想啊

7 楼 chgle 2009-04-22  

抛出异常的爱 写道

chgle 写道

框架定死在了SPRING+STRUTS2+HBIERBATE范围下，并严格按这个模式进行开发，还谈什么重构，剩下的仅仅是按业务修改的问题了，如果你满足于这样的现状，那么重构对于你来说确实是不合适

业务很简单么
业务不变化么
业务就不是代码组成的么

重构能重构的
把不能重构放在一边

重构=修改代码？说了是严格按SPRING+STRUTS2+HBIERBATE这个模式进行开发，但是往往复杂的系统会有自己额外的一些辅助框架和组件，或者是在SSH框架下进行扩展，这时在具体业务改变的时候重构的意义就体现出来了

6 楼 抛出异常的爱 2009-04-22  

chgle 写道

框架定死在了SPRING+STRUTS2+HBIERBATE范围下，并严格按这个模式进行开发，还谈什么重构，剩下的仅仅是按业务修改的问题了，如果你满足于这样的现状，那么重构对于你来说确实是不合适

业务很简单么
业务不变化么
业务就不是代码组成的么

重构能重构的
把不能重构放在一边

5 楼 chgle 2009-04-22  

框架定死在了SPRING+STRUTS2+HBIERBATE范围下，并严格按这个模式进行开发，还谈什么重构，剩下的仅仅是按业务修改的问题了，如果你满足于这样的现状，那么重构对于你来说确实是不合适

4 楼 jili 2009-04-22  

1、没有银弹
2、重构同上

3 楼 luckaway 2009-04-22  

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

重构是是一种技能！

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

2 楼 treblesoftware 2009-04-22  

zorwi 写道

即使开始时需求考虑多么周全,也无法避免出现需求的改变.即使开始时设计的多么周到,也会有无法适应需求的情况。

当需求出现变化的时候,此时就要更改代码,更改代码的时候,如果出现bad smell,此时就需要重构.重构的目的,并不是为了实现某个需求,而是为了适应某种需求的变化.在敏捷开发中,都是遵循用"最简单的方法完成工作".所以,重构成了敏捷开发中必不可少的一部分.

至于TDD,我的愚见就是应该Test first 测试先行.在编码前就先写好测试代码，部分人会认为功能都没出来，怎么写测试？打个比方，砌墙时，你看师傅是先把墙砌好，在用线量量看平不平，还是先用条线拉直，然后砌墙是就以这条线为标准来砌呢？答案显然。而且先写测试，你会先用到该功能，可以说是一种体会，会对你之后写的功能有了更好的灵感。还有，重构后的代码，还可以用TDD测试，其实TDD，也是为日后的维护减少工作量。

感觉您没有完全理解我的意思。 不过还是非常感谢您的回帖。
关于《重构》，我指说这本书是否适合我们现在的这种开发模式（什么开发模式，请看我的帖子顶楼）。
其实我到认为，重构更适合从什么都没有到什么都有。就像您说的，不断变化中，寻找机遇。不过问题就是，我们现在都在框架的范围之内，借助框架的一些思想去实现代码，感觉重构里的许多东西并不十分适合当前的模式。

1 楼 zorwi 2009-04-22  

即使开始时需求考虑多么周全,也无法避免出现需求的改变.即使开始时设计的多么周到,也会有无法适应需求的情况。

当需求出现变化的时候,此时就要更改代码,更改代码的时候,如果出现bad smell,此时就需要重构.重构的目的,并不是为了实现某个需求,而是为了适应某种需求的变化.在敏捷开发中,都是遵循用"最简单的方法完成工作".所以,重构成了敏捷开发中必不可少的一部分.

至于TDD,我的愚见就是应该Test first 测试先行.在编码前就先写好测试代码，部分人会认为功能都没出来，怎么写测试？打个比方，砌墙时，你看师傅是先把墙砌好，在用线量量看平不平，还是先用条线拉直，然后砌墙是就以这条线为标准来砌呢？答案显然。而且先写测试，你会先用到该功能，可以说是一种体会，会对你之后写的功能有了更好的灵感。还有，重构后的代码，还可以用TDD测试，其实TDD，也是为日后的维护减少工作量。