一、什么时候重构
引用书中一段话：
第一次做某件事时只管去做，第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。
也就是说当我们做相同的事情第三遍的时候，你就应该去重构了。
1. 预备性重构：让添加新功能更容易
如书中所说，在当我需要添加新功能时，我们应该先去看看现有的代码库，可能你现在添加的功能在现有的函数里已有实现了大部分，只需要改动很小的部分就可以，那么这个时候，你就可以先戴上重构的帽子，将代码进行重构，然后再当完成新的功能就变得很简单。
作者在书中用一个小故事来说明这个道理：
就好比你需要往东去100公里，我不会往东直接开，而是先往北开20公里上高速，在往东开100公里。
2.帮助理解的重构：使代码更易懂
当我们看代码时，脑海里会形成一些理解，我们把这些理解转移到代码本身，这会让这份知识或理解保存的更久远，例如看到一个糟糕的逻辑，一个糟糕的命名，当你理解这些代码时，快速的将其重构，这样后面当你或者其他同事再来看这段代码将变得简单。
3. 有计划的重构和见机行事的重构
“肮脏的代码需要重构，但漂亮的代码也需要很多重构”
重构的时候，并不一定需要专门安排一段时间来重构，而是在添加功能或者修复bug的同时顺便重构；有计划的重构应该很少，大部分重构应该是不起眼的、见机行事的。
4. 复审代码时重构
复审代码也就是我们常说的code review，这种活动可以改善开发状况，还有助于在开发团队中传播知识，也有助于把知识传递给经验欠缺的人员。在这个过程中我们还可以看到代码中的不足，进而通过重构的手段来快速的解决这个问题，并且重构能够帮助复审代码工作得到具体的结果，不仅能当场获得建议，而且许多建议能够立刻实现。
二、重构的挑战
1. 延缓新功能的开发
尽管重构的目的是为了加快开发速度，但是仍然有很多人认为，花在重构的时间是在拖慢新功能的开发进度；
重构的意义不在于把代码库打磨的闪闪发光，重构的意义纯粹是经济角度出发的考量，之所以重构，因为能让我们添加功能更快、修复bug更快。
2. 代码所有权
很多重构不但会影响模块内部，还会影响该模块与系统其他部分的关系，例如：在一些团队中，调用方代码可能是另一只团队拥有，而我们没有权利写入他们的代码库，这个时候可能即便是一个简单的修改函数声明和调用者，都变得困难。
3. 测试
在我们重构代码的时候，如何保证我们的代码没有对现有的功能造成破坏，那么这就需要一套完备的测试套件，并且运行速度要快，否则我不会愿意经常去运行它。所以大多数情况，你想要重构，就得现有自测试的代码。
