1 · 读书笔记：重构

Refactoring

https://book.douban.com/subject/1419359

1.1 · 核心观点：

1. 是什么（What） 重构是在不改变软件外部可观察行为的前提下，调整代码内部结构。它不是“大改重写”，也不是顺手美化代码，而是一组可小步执行、可持续验证的结构改进动作，目标是让代码更容易理解、更容易修改。

2. 为什么（Why） 代码会不断腐化。需求迭代、赶进度、复制粘贴、临时分支和糟糕命名都会让系统逐渐失去可读性与一致性。重构的价值在于延缓这种退化，把修改成本压低，让后续开发不必反复为旧设计埋单。它本质上是在管理长期复杂度，而不是追求短期整洁。

3. 怎么做（How） 实践上应遵循“小步修改、频繁运行测试、持续保持可工作状态”的节奏。先识别坏味道，例如重复代码、过长函数、过大的类、发散式修改、霰弹式修改、特性依恋和数据泥团；然后用一系列微小而安全的手法处理它们，例如提炼函数、搬移函数、封装变量、分解条件表达式、以多态取代条件分支、引入参数对象等。该做的是每次只做一个局部改动、让测试始终兜底；不该做的是一边重构一边改需求，或者把“推倒重写”误当成重构。

1.2 · 启发点（关键洞察）：

1. 坏代码最大的问题不是“丑”，而是它会持续放大后续修改成本。今天多花一分钟理解代码，明天可能就要多花一小时改动它。
2. 重构不是开发的附属品，而是开发本身的一部分。只要代码要继续演进，重构就不该被推迟到“以后有空再做”。
3. 坏味道不是 bug 证据，而是设计信号。它提醒你这里可能存在抽象边界失衡、职责分配不当或知识重复。
4. 好命名、短反馈循环和自动化测试，是重构能否持续发生的三个基础设施。没有测试，重构很快就会退化成“凭感觉改代码”。
5. 很多 if/else 泛滥、参数组合爆炸、重复逻辑散落的问题，本质上不是代码写得不够勤奋，而是模型没有抽象好。
6. 与其在 code review 里反复提醒风格问题，不如通过重构把结构调整到“不容易写错”的状态。

1.3 · 行动：

1. 以后改旧代码时，不再只补丁式修修补补；每次顺手消灭一个最明显的坏味道，例如重复逻辑、模糊命名或超长函数。
2. 对最近常改的模块做一次坏味道盘点，重点看是否存在重复代码、过长函数、发散式修改和数据泥团，并记录对应的重构手法。
3. 把“先有测试，再动结构”作为默认习惯。没有测试保护的地方，先补最关键的行为测试，再开始重构。
4. 遇到复杂条件分支时，优先思考是否可以通过提炼函数、提前返回、引入策略对象或多态来降低分支复杂度。
5. 在 code review 中增加一个问题：这次改动是在继续堆复杂度，还是顺手把结构往更容易演进的方向推进了一步。

1.4 · 金句：

1. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler
2. “When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.” — Martin Fowler
3. “If you have to spend effort looking at a fragment of code and figuring out what it’s doing, then you should extract it into a function and name the function after the ‘what’.” — Martin Fowler
4. “Refactoring is a controlled technique for improving the design of an existing code base.” — Martin Fowler
5. “The true test of good code is how easy it is to change it.” — Martin Fowler