# 来源与适用说明

主要来源：John Ousterhout《A Philosophy of Software Design》，原技能作者使用的[中文翻译站点](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/preface.html)。原技能定稿前已通读该站的前言、第 1—21 章与总结，并核对图示；站点同时展示英文正文，术语有歧义时可对照阅读。阅读范围为该站所呈现版本，不代表其他版次。

本规范使用自己的表述，把设计观点转成开发与审查时的工作判断；没有复制书中代码或大段正文。工程示例、按任务缩放的流程、授权边界和验证方式属于本规范的应用约定，不声称是作者逐条提出的要求。

| 主题 | 原文章节 | 使用位置 |
| --- | --- | --- |
| 持续设计与复杂性的判据 | [第 1 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch01.html)、[第 2 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch02.html) | 变更放大、认知负荷、未知的未知 |
| 持续投入设计、避免战术性补丁 | [第 3 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch03.html) | 小幅改进与方案比较 |
| 接口与实现、深模块 | [第 4 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch04.html) | 从调用方评价封装效果 |
| 封装设计知识、避免泄漏 | [第 5 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch05.html) | 按知识归属划分职责 |
| 适度通用 | [第 6 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch06.html) | 减少场景绑定，保持常见用途易用 |
| 相邻层的抽象差异 | [第 7 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch07.html) | 检查透传层及其实际价值 |
| 复杂性归属与配置 | [第 8 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch08.html) | 优先由有能力负责的模块完成决策 |
| 拆分、合并、通用与专用代码 | [第 9 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch09.html) | 检查拆分后的独立理解能力 |
| 异常与特殊情况 | [第 10 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch10.html) | 契约简化、恢复与聚合处理 |
| 比较设计 | [第 11 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch11.html) | 对重要决策设计两次 |
| 注释的作用及其内容 | [第 12 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch12.html)、[第 13 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch13.html) | 接口契约与实现理由 |
| 命名 | [第 14 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch14.html) | 准确表达概念，避免歧义 |
| 先写注释 | [第 15 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch15.html) | 实现前检查契约是否清晰 |
| 演进与文档维护 | [第 16 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch16.html) | 当前约束下改善边界，保持文档就近和唯一 |
| 一致性与显然的行为 | [第 17 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch17.html)、[第 18 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch18.html) | 沿用有效约定，解释隐式行为 |
| 抽象增量、测试、继承和设计模式 | [第 19 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch19.html) | 设计与验证互相反馈，按收益使用机制 |
| 性能设计 | [第 20 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch20.html) | 基线、瓶颈、关键路径与重测 |
| 总体目标与危险信号 | [第 21 章](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ch21.html)、[全书总结](https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/summary.html) | 以降低复杂度检验原则的适用性 |

理解“以抽象为增量”时保留条件：可以等功能需要某项抽象时再设计它；一旦需要，就把这项抽象设计清楚。它不要求在需求出现前先建通用平台。

前言把降低复杂度作为总体目标。具体原则是否采用，应由实际收益判断，不能把任何一条原则机械化成层数、方法长度、接口数量或重构配额。

## 不直接转成强制规范的观点

- 作者建议持续投入部分开发时间，但所举比例及收益曲线不是本规范的工时指标或生产率承诺。
- 作者批评以用例逐个通过为中心的 TDD，同时肯定单元测试与缺陷回归。这里保留其对设计的要求，不禁止现有测试方法。
- 第 10 章的持续重试和进程崩溃来自特定运行环境，不适合作为通用默认操作；恢复方式仍取决于系统契约。
- 第 18 章关于具体类型声明的建议，不覆盖项目的依赖抽象约定。调用者必须知道的性能或并发保证应写入契约，无需一律暴露内部容器类型。
- 继承、装饰器、设计模式和 getter/setter 都按实际封装收益判断，不一律禁用，也不因机制名称熟悉而默认采用。