第 19 章：软件潮流
系列：软件设计的哲学 · 第 19/22 章
全书导读：00-overview.md
一句话总结
敏捷、TDD、设计模式、微服务等潮流本身不保证好设计——用「是否降低复杂度」一尺量之，而非用流行度代替判断。
核心观点浓缩
- 方法论常把可测目标（速度、覆盖率、故事点）与好设计混为一谈
- 敏捷价值在反馈与迭代，但若变成「拒绝设计思考」则有害
- TDD 有用场景，但覆盖率崇拜可催生浅接口与过度 mock
- 设计模式 是词汇非目标；为模式而模式增加 indirection 与复杂度
- 微服务/类爆炸 等 scale 方案在小项目上是主动制造分布式复杂度
- 正确姿态：吸收实践、拒绝教条——一切服从复杂度（第 2 章）
- 第 2 版点名 Clean Code 部分规则：当规则与降低复杂度冲突时，复杂度优先
关键概念 / 金句
| 潮流 | 可用之处 | 误用风险 |
|---|---|---|
| 敏捷 | 短反馈、优先交付价值 | 「没时间做设计」 |
| TDD | 锁定行为、防回归 | 测实现细节、阻碍重构 |
| 模式 | 沟通共同语言 | 强行套用 23 种 |
| 强类型/FP 时尚 | 约束错误空间 | 学究式炫技 |
「流行不等于正确；唯一可靠的标准是复杂度是否下降。」
本章在全书中的位置
第 19 章开启取舍篇（第 19–21 章），从可读性转向元方法论：在前半模块原则之上，警惕流程与时尚稀释设计投资。为第 21 章「决定什么重要」铺垫——资源有限，不能追逐所有潮流。Ousterhout 并非反敏捷/反测试，而是反用流程指标替代设计判断。
个人思考与启发
团队曾推「每个类都要单元测试 90%」，结果大量测 private 分支，重构改名测试全红。改为只测 public 契约与关键路径后，覆盖率数字下降，但回归信心与重构速度反而上升。Scrum 每日站会若只报进度不问设计债，敏捷仪式反而强化战术式编程——潮流的价值在反馈环，不在取消思考。引入 KPI 前先问它测量的是复杂度还是活动量。
与《程序员修炼之道》对照
- 批判性思维、上下文是关键——两书对教条持相同怀疑
- 修炼之道偏个人与团队习惯；本书更系统拆解设计类潮流
- 「好的 enough 软件」：交付与质量平衡，非盲目跟 Scrum 仪式
重点与注意
重点：引入新实践前写一句「期望降低哪种复杂度症状？」——答不出则暂缓。
重点：第 2 版加强了对 Clean Code 式规则崇拜 的批评——规则是启发式非律法。
注意：反对教条 ≠ 反对所有测试/迭代；战略式编程仍要验证与反馈。
注意：领导层 KPI 若只盯速度，会在组织层放大战术式编程——需文化配合。
注意：评估新工具（框架、ORM）时用试点模块测复杂度变化，非全库一刀切。
注意：Retro 只谈流程不谈设计时，补问「本周哪处复杂度升了」一条即可。
导航：第 18 章 代码应显而易见 · 下一篇：第 20 章 为性能而设计