开始重构
如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序，使其比较容易添加该特性，然后再添加该特性。
重构前，先检查自己是否有一套可靠的测试集，这些测试必须有自我检视的能力。
事实上很多时候，测试集都是被我们忽略的
营地法则：保证你离开的时候代码库一定比原来的更加健壮。
什么是重构？根据重构这本书的定义，如果有人说他们的代码在重构过程中有一两天的时间是不可用的，基本上可以确定，他们在做的事情不是重构。
何时重构
事不过三法则（Rule of Three）：第一次做某件事情的时候只管去做，第二次做某件事情的时候会产生反感，但无论如何还是可以去做，第三次再做类似的事情，你就应该重构。
在《代码精进之路》这本书中，也提到了这个原则。
另外的一个时机是，每次要修改时，首先令修改很容易（警告：这件事有时候会很难），然后再进行这次的修改。
比如，笔者最近在做一个长链接客户端 SDK，最初这个 SDK 功能很简单，我直接加功能即可，后面有一次当我要修改的时候，我发现这个 SDK 的修改已经变得异常复杂了，这个时候我知道我应该重构了。
重构法则
这里对一些我们实际场景中遇到，但是通常会被我们忽视的一些法则进行列举。
霰弹式修改
如果我们代码中的模块特别多，如果我们每次遇到一个变化都需要在不同的小模块中做许多小修改，我们所面临的坏味道就是霰弹式修改。
这个时候我们需要思考重构，最好我们不同的模块都是正交的。
慎重注释
有的时候，我们写注释是因为这段对应的代码逻辑很糟糕。
因此当你感觉需要撰写注释的时候，请先尝试重构，试着将所有的注释变成多余。
提炼变量
对于复杂语句，提炼变量可以增加可读性。