第 21 章：决定什么重要
系列：软件设计的哲学 · 第 21/22 章
全书导读：00-overview.md
一句话总结
设计原则不是 checklist——在时间、人力与风险约束下，你必须判断哪些模块值得战略式投入、哪些可以战术式通过，上下文决定优先级。
核心观点浓缩
- 第 2 版新增章：全书原则的应用层——知道深模块好，还要知何处必须深
- 投资梯度：核心域、高变更、高扇出接口 → 多设计时间；稳定边缘 → 可简化
- 完美设计不存在；足够降低复杂度即胜利，避免分析瘫痪
- 与产品/业务对齐：可靠性、扩展性、交付日期——显式 trade-off 表
- 技术债可接受，若** knowingly** 借且计划还；无意识债才是杀手
- 再访机制：每个战术式决策设日历提醒或 milestone，到期必须升级或删除
关键概念 / 金句
| 高优先级设计 | 可战术式 |
|---|---|
| 插件 API、持久化格式 | 一次性迁移脚本 |
| 多团队共用的 Session 核心 | 内部调试工具 |
| 安全与数据完整性路径 | 原型 UI |
「战略式编程是默认姿态，但不是每个函数都值得设计两次。」
本章在全书中的位置
第 21 章为全书取舍枢纽，衔接第 19 章潮流批判与第 22 章结论。它回答实践者最常问的问题：「原则我都懂，明天 deadline 怎么办？」——用优先级框架代替放弃设计。第 2 版单独增章，说明「原则正确」与「资源有限」之间的张力无法靠更多规则消除，只能靠显式决策。
个人思考与启发
面扫导出格式六种，若每种都设计两次会延期。划定「OBJ/STL 用户-facing、必须稳定」与「内部中间格式可迭代」，资源投在前者深模块 + 测试，后者允许战术式，整体复杂度仍可控。与产品对齐时，用变更频率 × 扇出矩阵排优先级，比凭感觉「这个模块很重要」更可辩护。季度复盘时可重排矩阵，防止临时战术式永久化。
与《程序员修炼之道》对照
- 明白需求、范围 creep 警惕——先定什么重要再写代码
- 「品质三角」：范围、时间、资源；本书补充设计深度为可调维度
- 知识组合：把设计决策记录在 ADR，便于日后重评优先级
- 曳光弹可用于验证战术式路径，但上线前须对核心模块补战略式抽象
- 曳光弹可用于验证战术式路径，但上线前须对核心模块补战略式抽象
重点与注意
重点：开工前与干系人确认非目标（明确不做什么）与质量栏。
重点：战术式决策要可见（TODO/issue），避免伪装成战略式完成品。
注意：「决定什么重要」不是给浅设计找借口——核心路径不能省。
注意：团队需共同优先级语言，否则各人战术式标准不一，整体熵增。
注意：向管理层解释延期时，用变更放大案例（改一处动十处）比抽象谈「质量」更有说服力。
导航：第 20 章 为性能而设计 · 下一篇：第 22 章 结论