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

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

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

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

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

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

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

重构是是一种技能！

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

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

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

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

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

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

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

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