重构的几大重要特点

   1.定义：重构就是在不改变代码的业务逻辑基础上，而进行对代码中一些可读性差的代码进行修改，使得代码更加清晰、易懂、扩展性增强，这样可增强代码的可读性、可维护性。
   2.重构的节奏：测试、小修改、测试、小修改.
   3.重构的难题：数据库；修改接口；无法通过重构来完成!
   4.重构的目标：设计模式;
   5.重构的保证：测试。
   6.何时不该重构：在项目的末期不该去重构、在代码错误的情况下不该去重构。
   7.臭味条款：类过大、方法过长、大量的重复代码等等！臭味条款还有很多很多，就不一一写出来了。

何时不该重构：在项目的末期不该去重构《-- 哪里得来经验

楼主自己总结的？ 还是拿来主义

重构的代价一般是很大的,领导们一般都不愿花这么大的代价

重构任何情况都可以进行,只是风险大小而已.

倒是觉得代价很大是被无端想像出来的。

这位兄弟还是先买本《重构》自己看看吧。

个人认为在项目的快提交的时候，不应该大量的使用重构，当然也没说不准使用重构。大量的重构只会使得程序增加风险，而且一但出现bug将给你付出更大的代价。。。。。。
         兄弟有和见解，可以说说你的想法？学习了·······

个人总结!有什么不对，希望帮忙指出。

恩，可以这样理解！