重构，是一名程序员必备的职业技能。然而，大多数人对于重构的认知仍然停留在项目中期为了提升代码质量而做的并非不可不做的操作。对于重构的重要性和含义并没有充分的认知。
本文，笔者将结合自身经验和阅读《重构，改善既有代码的设计》一书（下面简称《重构》）的心得，以系列文章的方式讲述重构的内功心法以及武功招式。
重构，就是对软件代码进行调整。这里调整的前提是不改变软件的功能，目的在于使代码更易让他人看懂，从而进行有意义的修改。
对于程序员来说，大多数情况下很难做到对一个项目从 0 到 1 地开发，往往都是中途加入，在已有的代码基础上进行现有代码的修改或增加新的特性。由于项目往往经过多人的合作开发，每个人的编程风格各异，从而导致代码质量直线下降，不同模块给人一种割裂感。因此，当我们接手一个前人写过的项目代码时，往往喜欢戏称之为“屎山”。
屎山带来最直接的影响就是：
因此，为了方便修改和理解，我们需要对修改的部分的相关代码在不改变其功能的基础上进行一定的调整，这个过程就是重构。
很多人习惯性地认为重构应该发生在特性实现后，但事实上这样只是方便了后人对你的代码进行修改，而对于你本次开发的难度性没有任何减小。
那是否是在特性实现前？事实上，我们大多数时候无法保证自己第一遍写出来的代码能够完全符合高质量代码的标准而不需要重构。因此，特性实现前的重构只是方便了自己本次的开发，但对于本次开发引入的新的屎却无法解决。
最佳实践：
我很喜欢《重构》一书中两顶帽子的比喻，它将开发软件时需要分配时间的两种行为：添加新功能和重构比喻为两顶帽子。添加新功能时不对代码做任何结构的调整，而重构时也不添加任何新的功能。在软件开发的过程中我们需要不断地变换两顶帽子。当我们为添加新功能时每写入一段新的代码，如果发现此时需要重构，便可以立即暂停对新功能的开发而进行重构。重构后又可立即转回继续开发新功能。
重构过程中最怕的一个点就是当我们变更了代码结构后，为代码加入了新的bug，或是原本的程序在重构后运行结果不符合预期。因此，为了保证重构的正确性，测试必不可少。
在重构开始前，我们需要保证有一套完整的针对需要重构的代码部分的自动化测试。当然，这个测试可以是自动化测试脚本，也可以是单测。在重构的过程中，需要保证哪怕进行了一些微小的变动都进行一次测试，确认运行结果与重构前一致。