《重构》 2. 重构的原则

第2章介绍了重构的一些重大原则，这里仍然只是记录一些重点以作备忘。

- **重构（名词）**：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

- **重构（动词）**：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

- *如果有人说他们的代码在重构过程中有一两天时间不可用，基本上可以确定，他们在做的事不是重构。*

- 重构和性能优化的差别：重构是为了让代码“更容易理解，更易于修改”；性能优化只关心让程序运行的更快。

- **两顶帽子**：添加新功能时，不应该修改既有代码，只管添加新功能；重构时不能再添加功能，只管调整代码结构。

- 代码结构的流失有累积效应。

- 为何重构

1. 改进软件的设计
    2. 使软件更容易理解
    3. 帮助找到 bug
    4. 提高编程速度

- **“设计耐久性假说”**：通过投入精力改善内部设计，增加了软件的耐久性，从而可以更长时间地保持开发速度。

- **三次法则**：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。**事不过三，三则重构。**

- 重构的最佳时机就在添加新功能之前。

- 并不需要专门安排一段时间来重构，而是在添加新功能或修改 bug 的同时顺便重构。

- *肮脏的代码必须重构，但漂亮的代码也需要很多重构。*

- 添加新功能最快的方法往往是修改现有的代码，使新功能容易被加入。

- *重构的唯一目的就是让我们开发更快，用更少的工作量创造更大的价值。*

- 重构应该总是由经济利益驱动。

- 已发布接口（*published interface*）：接口的使用者（客户端）与声明者彼此独立，声明者无权修改使用的代码。

- 在隔离的分支上工作的越久，将完成的工作集成（*integrate*）回主线就会越困难。

- 持续集成（*CI*），也叫“基于主干开发”（*Trunk-Based Development*）。使用 *CI* 时，每个团队成员每天至少向主线集成一次。代价：必须使用相关的实践以确保主线随时处于健康状态。

- *CI* 和重构能良好的配合。

- 团队必须投入时间和精力在测试上，但收益绝对是划算的。

- 缺乏测试时的重构

1. 如果我的开发环境很好的支持自动化重构，就可以信任这些重构，不必运行测试。

现在工作的主要开发工具是 *Visual Studio* 和 *Intelli IDEA*，对重构都有很好的支持，很多简单的重构都可以自动化的完成。

2. 只使用一组经过验证是安全的重构手法。

- 一般来说，只有在设计系统时就考虑到了测试，这样的系统才容易添加测试。

这个说到痛点上了，最近搭建的 *.NET Core* 项目的时候也没有考虑这方面的需求，很多功能也是基于之前的框架结构，想添加测试总感觉无从下手。

- 数据库：渐进式数据库设计和数据库重构：借助数据迁移脚本，将数据库结构的修改与代码结合，使大规模的、涉及数据库的修改可以比较容易的展开。

- 重构起初是作为极限编程（XP）的一部分被人们采用的。

- 重构的第一块基石是自测试代码。

---

> **建议：**
> 
> 今天发现中文版的一个很大的不足的地方。本书讲解主要是通过具体的示例代码，展示每次代码改动的地方用的确是淡灰色的。丝毫没有起到强调的作用，反而有些看不清楚。对比了下英文版才发现英文版是彩色的，改动的地方用橙色字体展示，很明显。不知道是不是成本的原因导致的，希望下一版至少能改成粗体，以起到强调的作用。

---

> 摘自：[《重构：改善既有代码的设计》][1] -- 马丁·福勒（*Martin Fowler*）

---

[1]: https://union-click.jd.com/jdc?e=&p=AyIGZRhaEwAQBFUZXBIyEgRREl4QChs3EUQDS10iXhBeGlcJDBkNXg9JHU4YDk5ER1xOGRNLGEEcVV8BXURFUFdfC0RVU1JRUy1OVxUBFg5QHlMcMloDXR8JHXtmYiNlWEBFeV1UUjxnS0QLWStaJQITBlYbXB0LFQJlK1sSMkBpja3tzaejG4Gx1MCKhTdUK1sRCxQBVxtdFAcTB1crXBULIloNXwZBXUReEStrJQEiN2UbaxYyUGlUE1xGBhFQBR5bFVUXVAdOU0dWGwFdTwtAAkZTVE9fRTIQBlQfUg%3D%3D (《重构：改善既有代码的设计》)

《重构》 2. 重构的原则

回复内容 *

目录

AUTHOR