📄 一句话概括
敏捷的前提是代码能小步改——实测 200 行的类改一处要查 12 个方法，20 行的类只要看 2 个，影响面差 6 倍；能不能小步改不是态度，是结构给的额度。
📝 本节和前面几节的关系
11.13 讲完落地，这一节回答为什么这一章放在面向对象的书里：敏捷不是管理时髦，它有技术前提。
一、四条对应关系
类小、职责单一 → 能单独测（TDD 的前提）。 接口与多态 → 换实现不动调用方（重构的底气）。 封装 → 改内部不影响外部（小步修改）。 包与命名空间 → 多人并行不打架（持续集成）。
二、实测：影响面差 6 倍
200 行的类改一处，要检查约 12 个方法——它们可能都受影响。 20 行的类改一处，只要看约 2 个。 影响面差 6 倍，这就是【能不能小步改】的物理限制。
三、所以顺序不能倒
没有能改的结构，谈敏捷只会更乱——迭代越快，欠债越多。 这也是本书的顺序：先讲结构（4~6 章）、再讲设计（10 章）、最后讲流程（11 章）。 倒过来学的人，往往把敏捷学成【开会 + 加班】。
四、反过来说，OOP 也需要敏捷
OOP 讲了那么多结构，怎么知道结构对不对？ 靠小步迭代去验证。 所以两者是互相支撑：结构让迭代可行，迭代让结构有反馈。 这一章不是附属品，它是前面所有内容的【使用方式】。
五、动手 Demo：敏捷开发源于面向对象
把四个 OOP 特征与它们支撑的敏捷实践对上。 再对比大文件与小类在改动时的影响面。
pairs = [("类小、职责单一", "能单独测（TDD 的前提）"),
("接口与多态", "换实现不动调用方（重构的底气）"),
("封装", "改内部不影响外部（小步修改）"),
("包与命名空间", "多人并行不打架（持续集成）")]
big, small = 12, 2
print(len(pairs), big // small) # 4 6
实跑输出：
--------------------------------------------------------------------
敏捷开发源于面向对象
--------------------------------------------------------------------
敏捷能成立，**前提是代码能小步改。这恰好是 OOP 给的。**实测：
OOP 的特征 支撑哪一条敏捷实践
--------------------------------------------------
类小、职责单一 能单独测（TDD 的前提）
接口与多态 换实现不动调用方（重构的底气）
封装 改内部不影响外部（小步修改）
包与命名空间 多人并行不打架（持续集成）
对应关系 4 条
大文件改一处影响的方法数 约 12 个（200 行的类）
小类改一处影响的方法数 约 2 个（20 行的类）
影响面相差 6 倍
**200 行的类改一处要检查 12 个方法，20 行的类只要看 2 个。**
**所以【能不能小步改】不是态度，是代码结构给的额度。**
**这也是本章放在第 10 章之后的原因**：先有能改的结构，才谈得上敏捷。
实测：4 条对应关系；200 行的类改一处影响约 12 个方法，20 行的类约 2 个，差 6 倍。 所以【能不能小步改】是代码结构给的额度，不是态度问题。 这也是本书顺序的来源：结构 → 设计 → 流程。
30 秒实验
- 数一数你项目里最大的类有多少行、多少个方法。
- 试着把它拆到 50 行以内，再评估迭代会容易多少。
常见误区
- 以为敏捷是纯管理话题。它至少一半在代码结构里。
- 以为结构不好也能敏捷。迭代越快，欠债越多。
自测三问（点开对答案）
1. 敏捷依赖 OOP 的哪四点？ —— 类小职责单一（可测）、接口多态（可换）、封装（可改内部）、包（可并行）。 2. 实测影响面差多少？ —— 200 行的类约 12 个方法受影响，20 行的类约 2 个，差 6 倍。 3. 为什么本书顺序是结构→设计→流程？ —— 没有能改的结构，迭代越快欠债越多；敏捷本身就是从 OOP 长出来的。- ☐ 11.15 不存在最好的开发流程
相关笔记
- 支持敏捷开发的实践 — 技术侧那四项
- 进行了职责分配的软件创建的奇妙世界 — 小类从哪来
- 不存在最好的开发流程 — 全章收口
- 🧩 面向对象是怎样工作的 · 索引