重构原则——《重构——改善既有代码的设计》

1. 重构理解的3个2

1.1. 2种定义

• (1) 重构(名词)： 对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本；
• (2)重构(动词)： 使用一系列重构手法，在不改变软件可观察行为的前提下，调整期结构。

1.2. 2个拓展

• (1) 重构的目的： 使软件更容易被理解和修改；
• (2) 重构的前提： 不改变软件的可观察行为。

1.3. 2顶帽子

• (1) 添加新功能：添加新功能时，不应该修改既有代码，只管添加新功能，通过测试衡量工作进度；
• (2) 重构代码： 重构时，不能再引入新功能，只管改进程序结构。不能修改测试代码（除非绝对必要时）

2. 重构的目的

• 重构改进软件设计：消除重复代码，好的设计只需要添加少量代码就完成需求
• 重构使软件更容易理解：“准确说出我所要的”，协助理解不熟悉的代码以及让我们看到许多设计层面的东西
• 重构帮助找到bug：对代码重构可以加深对代码行为的理解，并把新的理解加入进去，这一过程很容易找出bug
• 重构提高编程速度：良好的设计是长期快速开发的根本

3. 重构的时机

• 重构不应该专门拨出时间进行，而应该随时随地开展
• 三次法则：对一次放手去做，第二次勉强去做，第三次开展重构
• 添加功能时重构：一方面重构帮助理解既有代码业务逻辑，另一方面既有代码结构无法让你轻松添加新功能
• 修补错误时重构： 出现bug而无法轻易定位，说明代码结构不清晰，需要重构
• 复审代码时重构：可以结合多人的建议让代码更加完善

4. 重构在开发任务中的定位

• 提升长期开发进度的手段
• 重构可能会引入更多的间接层，使得代码愈加难以阅读，但间接层有其优势：允许逻辑共享、隔离变化、封装条件逻辑
• 扔掉“寄生式间接层”，及被调用的地方只有一处或很少。

5. 重构面临的问题

• 难以明确重构的局限性，需要在实践中不断探索总结
• 数据库与程序紧密耦合以及数据迁移困难
• 发布接口的修改
• 项目无法稳定运行时，不考虑重构，建议重写
• 项目临近期限时，不建议重构

6. 重构与设计

• 良好的设计可以节省返工的成本，但程序的变化很多，不可能一开始就设计的非常全面。
• 重构可以对预先不完美的设计进行不断优化，最后不断适应程序的变化而趋于良好的设计
• 即使完全熟悉系统，但也需要实际度量其性能，不能臆测

7. 重构与性能

• 为提高设计而忽视性能的重构不可取
• 好的设计结构可以使性能优化的工作更轻松
• 三种性能优化手法：时间预算，持续关注，先重构后调优
• 时间预算法适用于对性能要求极高的实时系统
• 持续关注法：对程序所有角落进行优化，可能90%都不被经常调用
• 先重构后调优可以让你定位出损耗性能的小块代码，然后用持续调优的手法提升性能，效果更快更明显