<<改善既有代码的设计>> 第2章

重构原则：
1.事不过三，三则重构。当对同个业务逻辑或代码块做了类似的操作，而越来越反感的时候。第三次就应该重构了。
2.添加功能时重构：在老代码上添加新特性不方便
注：修补错误时重构可以加深代码理解，并且能更清晰的发现bug。

---

何时不该重构：
1.项目接近Deadline，避免重构。期限过后再重构。
2.旧系统模块bug百出，基本运行也有困难，这就需要重写了。

---

编码应该要”预先设计”，以后可能会在这个基础上增加什么额外功能，然后再”编码”，最后“重构”。

---

重构与性能：短期来看重构的确有可能降低性能，但他使性能优化的调整更容易，最终会得到更好的效果。