在多项式化简的这个例子中，承载简化过程的是已经被数学证明过的多项式等价变换的公式. 同理承载重构的则是被证明过的一个个代表代码等价变换操作的重构手法.
　　另外，由于完成一项重构需要使用一系列的重构手法，这些手法的使用顺序也是至关重要的!
　　我们学习重构，是要来学习每种场景下所使用的小步安全的重构手法及其使用顺序，并不断加以练习! 能够灵活而流畅地使用一系列重构手法完成一项重构，是衡量重构能力的一个非常重要的指标.
　　而本文后面的一个重点是对常用的重构手法以及运用顺序进行提炼，降低大家的学习难度.
　　后，既然重构中使用的是安全小步的代码等价变换手法，为什么我们还需要测试? 首先是因为我们是人，我们总会犯错! 另外由于编程语言的复杂性导致所谓的等价变换是受上下文约束的，例如在C++中为一个存在继承关系的类的成员方法重命名，有可能导致新的方法名和它某一父类中有默认实现的虚方法重名，而即使编译器也不能发现该错误.
　　高效地重构
　　虽然我们了解了如何/何时开始，目标，以及重构的手法，但是如果我们有了下面这些因素的辅助，会让我们更加安全和高效.
　　· 覆盖良好高效的自动化测试
　　· 合适的IDE，好提供基本的自动化重构菜单
　　· 良好的工程设置
　　· 高效的构建环境
　　· 良好的编码习惯
　　对于上面这些，不同语言面临的现状不同，针对C++语言我们后面会专门总结.
　　哪些不是重构?
　　针对上面的讨论，我们站在严格的重构定义上来看看下面这些反模式:
　　· “我把bug重构掉了!”
　　· “Debug一下刚才的重构那里出错了”
　　· “昨晚重构出来的Bug到现在还没有查出来”
　　· “先把代码重构好，再看测试为啥不过”
　　· “我把软件架构由集中式重构成分布式了”
　　想想上面的场景哪里存在问题?
　　在实际的开发过程中，我们还经常面临另外一种场景，那是对某一已经开发完成的软件模块进行整体重构. 在这样的过程中，虽然也存在频繁地使用重构手法对原有模块代码进行修改，但是更多的是进行大量的架构和设计方案上的修改.为了与我们要讨论的重构进行区分，对于这样的过程，我们称其为reengineering(软件重建).
　　软件重建一般是站在之前开发、测试的基础上，伴随着对软件要解决的问题和解决方式本身有了更深入的理解，通过修改软件把这些学习成果反映到软件的结构中去，使得软件可以更好、更精炼的解决业务问题。站在DDD（领域驱动设计）的角度，软件重建一般是对领域模型的进一步精练，使得软件更加贴合业务的本质！虽然成功的软件重建往往能对组织带来较大的收益，但是由于软件重建的开销普遍较大，而软件开发又是一项商业活动，所以需要对软件重建谨慎评估其成本收益比以及过程风险后才能决定是否启动。而本文中的重构技术，则只是一项日常编码中频繁使用的安全、高效的代码修改技术，被普遍认为是现代软件开发技术中必备的一项基本技能，是演进式软件设计或者软件重建目标达成的一项必要手段！
　　关于本文
　　我们总结一下，重构有三个要点，见下图:

　　1、你要有一个敏感的鼻子，能够嗅出代码中的坏味道; 一般只要发现不符合简单设计四原则的Code，是我们需要重构的目标对象. 而Martin总结的22条代码坏味道给我们一个很好的实践起点.
　　2、你要知道重构的目标，是让代码逐渐靠近简单设计四原则.
　　3、需要掌握小的安全的重构手法，以及在不同场景下合理的使用顺序，以便安全高效地承载重构目标的达成.
　　由于重构手法和实施顺序是学习重构的关键，所以本文后面会重点讲述这个主题. 另外，在实践中如何高效和安全的进行重构，和具体使用的编程语言及其开发、构建、测试环境关系也很密切.本文后会针对C++语言总结这方面相关问题.