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

更多的公司在变更时也不给你时间改bug
两害取其轻.....

个人签名: 作孽总需还.

对于公司来说，最终的产品是王道。至于重构对于公司来说，适当的时候适当采用。但是还是认为重构是一件很有意义的事情。

对于公司来说改bug不给足够的时间才素王道.
重构也只不过是为了以后改bug时少加点班

楼主想说的估计是不能对采用SSH框架进行重构，比如不能中途换掉hibernate，升级hibernate，甚至换掉java用ruby。系统技术架构一般是不改的！
要改的就是业务逻辑。表改了，dao，service，action，jsp就一路顺着重构吧...

一般是页面改了.....jsp,action,bean,service,dao,xml ,建表语句 一起改....客户想改表的还没见过.

有钱赚了还重构?
某些东西本来就没有重构的价值。项目完了，就死了。

LZ还没毕业，框架定的再好，也有人写出超垃圾代码。
关键是人，而不是框架。

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

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

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

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