来源与适用说明
主要来源：John Ousterhout《A Philosophy of Software Design》，原技能作者使用的中文翻译站点。原技能定稿前已通读该站的前言、第 1—21 章与总结，并核对图示；站点同时展示英文正文，术语有歧义时可对照阅读。阅读范围为该站所呈现版本，不代表其他版次。
本规范使用自己的表述，把设计观点转成开发与审查时的工作判断；没有复制书中代码或大段正文。工程示例、按任务缩放的流程、授权边界和验证方式属于本规范的应用约定，不声称是作者逐条提出的要求。
| 主题 | 原文章节 | 使用位置 |
|---|---|---|
| 持续设计与复杂性的判据 | 第 1 章、第 2 章 | 变更放大、认知负荷、未知的未知 |
| 持续投入设计、避免战术性补丁 | 第 3 章 | 小幅改进与方案比较 |
| 接口与实现、深模块 | 第 4 章 | 从调用方评价封装效果 |
| 封装设计知识、避免泄漏 | 第 5 章 | 按知识归属划分职责 |
| 适度通用 | 第 6 章 | 减少场景绑定，保持常见用途易用 |
| 相邻层的抽象差异 | 第 7 章 | 检查透传层及其实际价值 |
| 复杂性归属与配置 | 第 8 章 | 优先由有能力负责的模块完成决策 |
| 拆分、合并、通用与专用代码 | 第 9 章 | 检查拆分后的独立理解能力 |
| 异常与特殊情况 | 第 10 章 | 契约简化、恢复与聚合处理 |
| 比较设计 | 第 11 章 | 对重要决策设计两次 |
| 注释的作用及其内容 | 第 12 章、第 13 章 | 接口契约与实现理由 |
| 命名 | 第 14 章 | 准确表达概念，避免歧义 |
| 先写注释 | 第 15 章 | 实现前检查契约是否清晰 |
| 演进与文档维护 | 第 16 章 | 当前约束下改善边界，保持文档就近和唯一 |
| 一致性与显然的行为 | 第 17 章、第 18 章 | 沿用有效约定，解释隐式行为 |
| 抽象增量、测试、继承和设计模式 | 第 19 章 | 设计与验证互相反馈，按收益使用机制 |
| 性能设计 | 第 20 章 | 基线、瓶颈、关键路径与重测 |
| 总体目标与危险信号 | 第 21 章、全书总结 | 以降低复杂度检验原则的适用性 |
理解“以抽象为增量”时保留条件：可以等功能需要某项抽象时再设计它；一旦需要，就把这项抽象设计清楚。它不要求在需求出现前先建通用平台。
前言把降低复杂度作为总体目标。具体原则是否采用，应由实际收益判断，不能把任何一条原则机械化成层数、方法长度、接口数量或重构配额。
不直接转成强制规范的观点
- 作者建议持续投入部分开发时间，但所举比例及收益曲线不是本规范的工时指标或生产率承诺。
- 作者批评以用例逐个通过为中心的 TDD，同时肯定单元测试与缺陷回归。这里保留其对设计的要求，不禁止现有测试方法。
- 第 10 章的持续重试和进程崩溃来自特定运行环境，不适合作为通用默认操作；恢复方式仍取决于系统契约。
- 第 18 章关于具体类型声明的建议，不覆盖项目的依赖抽象约定。调用者必须知道的性能或并发保证应写入契约，无需一律暴露内部容器类型。
- 继承、装饰器、设计模式和 getter/setter 都按实际封装收益判断，不一律禁用，也不因机制名称熟悉而默认采用。