读程序员的制胜技笔记07_重构

1. 理查德·费曼(Richard Feynman)曾经说过：“如果你想真正学习一门学科，就写一本关于它的书。”

2. 重构是改变代码结构的艺术

2.1. 写出好代码通常只是成为高效开发者的一半标准

2.2. 另一半标准则是敏捷地转换代码

2.3. IDE提供了很好的重构工具

2.4. 将重构视为一项日常任务，是我们编程工作的一部分

2.5. 大多数时候，重构操作根本不影响代码的可靠性

3. 要点

3.1. 重构带来的好处比你认为的还要多

3.2. 可以在增量步骤来完成重大的架构改动

3.2.1. 总得有一个路线图来指导进行增量工作

3.3. 使用测试以在大型重构工作中减少隐患

3.4. 你要估计的不仅仅是成本，还有风险

3.5. 当重构的成本大于收益时，就得对重构打个问号了

3.6. 使用依赖注入来消解那些强依赖关系

3.6.1. 可以降低代码的刚性

4. 为什么要重构

4.1. 减少重复，增加代码的可复用场景

4.1.1. 将一个可以被其他组件复用的类移到公共位置，这样其他组件就能使用它

4.1.2. 从代码中提取方法并使它们能够被复用

4.2. 让实现代码和你的心理预期更加接近

4.2.1. 重命名是重构过程中的一部分，可以帮你实现更好的设计，使之更接近你的心理预期

4.3. 让代码更容易理解和维护

4.4. 防止某些类别的bug出现

4.4.1. 把一个类改成一个结构，可以防止与null有关的bug

4.4.2. 在项目中启用可空引用(nullable reference)并将数据类型改为不可为空(non-nullable)的，这是重构中避免bug的基本操作

4.5. 为重大的架构变化做准备

4.6. 摆脱代码中的刚性部分(rigid part of the code)

4.6.1. 通过依赖注入，你可以去掉依赖关系，拥有一个松散的耦合设计

5. 架构修改

5.1. 一次性进行大规模的架构修改几乎没有什么好下场

5.2. .NET Framework是最初的软件生态系统，在20世纪90年代末创建，增强了开发者的生活幸福感

5.3. .NET Framework相当于JDK（Java开发工具包），JDK也有Java运行时、Java语言编译器、Java虚拟机，可能还有一些从Java衍生的其他东西

5.4. 微软创建了一个通用的API规范，定义了一个通用的.NET功能子集，被称为.NET标准

5.4.1. Java没有类似的问题，因为甲骨文公司用它的律师“梦之队”成功地扼杀了所有不兼容的竞品

5.5. 微软后来创建了新一代的.NET Framework，它是跨平台的

5.5.1. 它最初被称为.NET Core

5.5.2. 从.NET 5开始改名为.NET

5.5.3. 与.NET Framework不直接兼容，但它们可以使用一个共同的.NET标准子集规范进行互操作

5.6. 识别组件

5.6.1. 处理大型重构工作的最好方式就是将你的代码分割成在语义上不同的组件(component)

5.6.2. MVC（model-view-controller，模型-视图-控制器模式）

5.6.3. MVVM（model-view-view model，模型-视图-视图模型）

5.6.4. MVP（model-view-presentation，模型-视图-演示模式）

5.6.5. 将不同的关注点相互解耦

5.7. 评估工作量和风险

5.7.1. 如何知道会有多少工作量

5.7.1.1. 只有在对两个框架的工作方式有了初步的概念之后才能确定

5.8. 树立威信

5.8.1. 其他开发同事不可能没注意到代码库里的新项目，但只要你事先和他们沟通你要实现的改动，并且他们能直接适应，那么在项目进展中实现改动应该是没有问题的

5.8.2. 核心目的还是减少工作量，与此同时尽可能地保持与主分支的同步

5.9. 重构让重构更容易

5.9.1. 在跨项目移动代码时，你会遇到比较难拆分的强依赖关系

5.9.2. 依赖注入(dependency injection，DI)

5.9.2.1. 不要把它和依赖倒置(dependency inversion)混淆

5.9.2.2. 基本含义是“在抽象层面的依赖”(depend on abstraction)

5.10. 最后冲刺

5.10.1. the final stretch

5.10.2. 在某些时候，你必须冒着与其他开发者起冲突的风险，将你的代码迁移到新的代码库中

6. 可靠重构

6.1. 让重构可靠的“秘术”是测试

6.2. 如果你能确保你的代码有一个良好的测试覆盖率，你可以有更多重构的操作空间

7. 什么时候不重构

7.1. 重构的好处是，它能让你思考代码如何改进

7.2. 重构的坏处是，在某些时候，你可能会仅仅为了重构而重构，它成了一种目的而不是一种方法

7.3. 不重构的标准

7.3.1. 重构的唯一理由是“这样更优雅”

7.3.1.1. 优雅不仅是主观的，而且是模糊的，因此意义不大

7.3.2. 目标组件赖于一个非常小的组件集

7.3.2.1. 意味着以后对它的重构和迁移会非常方便

7.3.3. 重构缺乏测试覆盖

7.3.3.1. 阻止你重构的红灯，尤其是在这个组件的依赖包袱非常重的情况下

7.3.3.2. 组件缺少测试也意味着你不知道你在做什么

7.3.4. 一个公共依赖项

7.3.4.1. 即便测试覆盖率还不错，并且重构理由也很充分，你也可能会打乱团队的工作流程，影响到你同事的工作效率

7.3.4.2. 如果你追求的好处不足以抵消操作成本，那你应该考虑推迟重构操作

7.3.5. 符合任何一条，就应该考虑避免重构，或者至少推迟重构的时间