第一章
重构的基础：
我们需要为即将修改的代码建立一套可靠的测试环境，为了使重构的结果能够得到保证，我们需要可靠的测试方式
分解并重组：
- 分解和重组的意义：
代码块越小，代码的功能就越容易管理，代码的处理和移动也就越轻松。 - 当我们提炼一个方法时，我们必须知道可能出什么错，如果提炼的不好，就可能给程序引入BUG
- 提炼代码块后，最好修改方法名和变量名使其更合理
思考：当代码块未被提取时，代码块中所使用的变量名的含义有时候会和提取后的含义变得不同，因此改名是有必要的，如书中所说：任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员 - 改名后，我们需要重新编译并测试，确保没有破坏任何东西
- 将代码放到正确的位置，我理解最好是遵循高内聚低耦合的原则
- 去除多余的变量或语句。尽量去除一些临时变量，临时变量往往引发问题，它们会导致大量参数传来出去，在一些比较长的方法中很容易跟丢他们，不利于阅读。
- 重构时最好小步前进，如此依赖犯错的几率最小
- 重构阶段最好只考虑代码结构的合理性，由此可能会出现影响性能的操作，如：循环由一次变成了多次，作者认为在重构阶段不必考虑这些，将代码结构尽可能做合理，让自己处于有利的位置，性能问题交给后续的性能优化。
多态的作用
- 如有必要，使用多态取代条件逻辑
- 将变化的部分放到对应的类中
第二章
何谓重构
- 重构提供了一种更搞笑且受控的代码整理技术
- 重构不会改变软件可观察的行为--重构之后软件功能一如以往。
为何重构
- 重构改进软件设计
- 重构是软件更容易理解
- 重构帮助找到BUG
有时候，我们盯着一大段代码不停地看以期望找到BUG，但有时候这种工作效率很低，这时候不妨尝试将这段代码重构，搞清楚程序结构的同时，也清楚了自己所做的假设，也许可以快速找到BUG - 重构提高变成速度
何时重构
- 添加功能时重构
- 修改BUG时重构
-复审代码时重构
重构的难题
- 数据库
解决办法：在对象模型和数据库模型之间插入一个分割层，这样就可以隔离两个模型各自的变化 - 修改接口
解决办法：
- 如果重构守法改变了已发布的接口，你必须同时维护新旧两个接口，知道所有用户都有时间对这个变化作出反应。
- 尽量让旧接口调用新街口
- 使用deprecation注解标记旧接口
注意事项：不要过早发布接口，尽量减少开放接口的数量
- 难以通过重构手法完成的设计改动
先想想重构的状况，适时决定是否进行重构 - 何时不改重构
- 既有代码太混乱，重构还不如重新写一个来的简单
- 项目已经接近最后期限，也应该避免重构
重构与设计
- 预先设计，编码阶段实施设计过程中，有可能会出现预先设计的解决方案无法解决的问题，这个时候引入重构。
重构与性能
- 三种快速编写软件的方法
- 时间预算法
这通常只适用于性能要求极高的实时系统
- 持续关注法
这种方法要求任何程序员在任何时候做任何事时都要设法保持系统的高性能，但这通常使程序难以维护，根据统计数据，如果一视同仁的·优化所有代码，90%的优化工作都是白费劲的，因为优化的代码大部分很少被执行 - 利用统计数据，寻找程序中哪些地方大量消耗时间和空间，有目的的去进行性能优化
