A Philosophy of Software Design | John Ousterhout | Talks at Google
字幕解读
Ousterhout 认为软件设计缺少系统讨论和教学，介绍以反复实现、代码评审和修改来训练设计能力的课程。设计上应追求深模块与小接口，尽量通过合理语义消除错误处理负担；开发者还需从只求功能落地的战术心态转向战略投入，持续降低复杂度，换取未来更快的开发。演讲承认目前课程高度依赖教师评审，难以扩展，也没有量化证据支持投资回报周期。
英文字幕轨道 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 通过迭代项目、同行评审、教师细致反馈和重写，可把设计原则落实到具体代码中。
- 深模块用简单接口隐藏大量实现，能降低使用者必须理解的复杂性；应优先追求抽象质量，而非机械限制代码行数。
- 可通过定义更宽容的正常语义消除许多错误情形；战略性维护需要持续小步投入，避免临时补丁累积成系统复杂度。
视频章节 6
- 软件设计为何缺乏教学
- 用反复评审训练设计
- 深类与简单接口
- 让错误情形消失
- 从战术转向战略设计
- 设计投入与小步改进
具体观点与证据 4
接口成本包括使用者必须理解的副作用与依赖，不只是函数签名；深模块应以较小认知成本提供较多功能。
深度不是代码行数，演讲也承认某些浅模块无法避免。
everything someone has to have in their mind in order to use that class.将删除变量定义为确保变量不存在，可消除重复清理时无需处理的异常。
只适用于能自然重定义契约的情况；无法履行调用契约的I/O错误仍须报告。
redefine the semantics, so that unset makes a variable not exist.系统复杂性来自多人持续叠加的小妥协，不能指望以后修一个大问题就全部清除。
经验性设计判断，不是已量化的维护成本模型。
It's hundreds or thousands of mistakes made by many people over a period of time.设计投资应融入小步迭代，而不是写代码前花数月一次性设计整个系统。
讲者承认无法提前准确预见系统；建议投入比例与回本期限缺乏量化证据。
You have to use a somewhat iterative approach.补充字幕原文 2
深类的关键是以简洁接口隐藏大量能力，从而降低使用方需要承担的理解成本。
very simple interface with a very large amount of functionality underneath it演讲者主张尽可能缩小必须显式处理异常的位置；更好的情况是重新定义语义来消除异常路径。
the number of places where people have to deal with exceptions解读边界
课程和原则主要来自讲者的教学与工程经验；讲者明确表示缺少设计投入回报周期的量化数据，课程也尚未解决规模化问题。
相关视频与证据 2
抽象风险与模块深度的互补视角提防错误抽象，也要让必要抽象足够深
Metz 提醒保留重复有时比维护错误抽象便宜；Ousterhout 则强调深模块以简单接口隐藏大量能力。把两者并读可帮助判断抽象质量：抽象不应只是消除重复，而应真正提供稳定、足够有价值的能力边界。
RailsConf 2014 - All the Little Things by Sandi Metz ↗
当抽象错误时，保留重复可能比以后修改抽象更便宜。
It is far cheaper to keep duplication than it is to have to mess with the wrong abstraction.▶ 14:52–14:59 · 观看片段A Philosophy of Software Design | John Ousterhout | Talks at Google
好的深模块用简单接口承载大量功能，降低调用者的理解负担。
very simple interface with a very large amount of functionality underneath it适用边界 两位讲者没有互相回应。Metz 反对的是错误抽象，并未主张避免一切抽象；Ousterhout 也没有说每段重复代码都应被抽成模块。
接口设计的共同原则用小接口和深实现减少使用者负担
Bloch 建议 API 保持小而清晰，拿不准的功能先不加入；Ousterhout 的深模块则以简单接口承载大量底层功能。两者共同指向一种具体设计收益：把复杂实现留在边界之后，让调用者只需理解少量稳定概念。
How To Design A Good API and Why it Matters ↗
对 API 功能是否必要拿不准时，应倾向于先不加入。
When it doubt, leave it out.▶ 24:42–24:45 · 观看片段A Philosophy of Software Design | John Ousterhout | Talks at Google
深模块以简单接口隐藏大量功能，降低使用者必须理解的细节。
very simple interface with a very large amount of functionality underneath it适用边界 公共 API 的功能取舍与内部模块深度是不同层级的设计问题；小接口本身不保证内部模块设计良好。