参考地址：https://ngte.cowtransfer.com/s/f7dbad9e43e145，中文地址：https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/

A Philosophy of Software Design

John Ousterhout是斯坦福大学的Bosack Lerner计算机科学教授。他是Tcl脚本语言的创建者，并且以在分布式操作系统和存储系统中的工作而闻名。Ousterhout在耶鲁大学获得了物理学学士学位，并在卡内基梅隆大学获得了计算机科学博士学位。他是美国国家工程院院士，并获得了无数奖项，包括ACM软件系统奖，ACM Grace Murray Hopper奖，美国国家科学基金会总统年轻研究者奖和UC Berkeley杰出教学奖。

第21章 结论

这本书是关于一件事的：复杂性。处理复杂性是软件设计中最重要的挑战。这是使系统难以构建和维护的原因，并且通常也使它们变慢。在本书的整个过程中，我试图描述导致复杂性的根本原因，例如依赖性和模糊性。我已经讨论了可以帮助您识别不必要的复杂性的危险标记，例如信息泄漏，不必要的错误情况或名称过于笼统。我已经提出了一些通用的思想，可以用来创建更简单的软件系统，例如，努力研究更深和更通用的类，定义不存在的错误以及将接口文档与实现文档分离。最后，我讨论了产生简单设计所需的投资思路。

所有这些建议的缺点是它们会在项目的早期阶段创建额外的工作。此外，如果您不习惯于思考设计问题，那么当您学习良好的设计技巧时，您甚至会放慢脚步。如果对您而言唯一重要的事情就是尽快使当前代码工作，那么思考设计就好像是在费劲工作，而这实际上妨碍了您实现真正的目标。

另一方面，如果良好的设计对您来说是重要的目标，那么本书中的思想应使编程更有趣。设计是一个令人着迷的难题：如何用最简单的结构解决特定问题？探索不同的方法很有趣，找到一种既简单又强大的解决方案是一种很好的感觉。干净，简单和明显的设计是一件美丽的事情。

此外，您对优质设计的投资将很快获得回报。在项目开始时仔细定义的模块将为您节省时间，因为您一遍又一遍地重复使用它们。您六个月前编写的清晰文档将为您节省返回代码添加新功能的时间。花在磨练设计技能上的时间也将有所回报：随着技能和经验的增长，您会发现可以越来越快地制作出好的设计。一旦知道了什么，一个好的设计实际上并不会比一个简单的设计花费更多的时间。

成为优秀设计师的好处是，您可以在设计阶段花费大部分时间，这很有趣。可怜的设计师花费大量时间在复杂而脆弱的代码中寻找错误。如果提高设计技能，不仅可以更快地生产出更高质量的软件，而且软件开发过程也将变得更加愉快。

总结

Summary of Design Principles设计原则摘要

1. 复杂性是逐步增加的：您必须流汗一些小东西（请参阅第11页）。
2. 工作代码还不够（请参阅第14页）。
3. 持续进行少量投资以改善系统设计（请参阅第15页）。
4. 模块应较深（请参见第22页）
5. 接口的设计应尽可能简化最常见的用法（请参阅第27页）。
6. 一个模块具有一个简单的接口比一个简单的实现更重要（请参阅第55、71页）。
7. 通用模块更深入（请参阅第39页）。
8. 通用和专用代码分开（请参见第62页）。
9. 不同的层应具有不同的抽象（请参见第45页）。
10. 降低复杂度（请参阅第55页）。
11. 定义不存在的错误（和特殊情况）（请参阅第79页）。
12. 设计两次（请参阅第91页）。
13. 注释应描述代码中不明显的内容（请参见第101页）。
14. 软件的设计应易于阅读而不是易于编写（请参见第149页）。
15. 软件开发的增量应该是抽象而不是功能（请参见第154页）。

Summary of Red Flags红旗摘要

• 浅模块：类或方法的接口并不比其实现简单得多（请参见第25、110页）。
• 信息泄漏：设计决策反映在多个模块中（请参阅第31页）。
• 时间分解：代码结构基于执行操作的顺序，而不是信息隐藏（请参见第32页）。
• 过度暴露：API强制调用者注意很少使用的功能，以便使用常用功能（请参阅第36页）。
• Pass-Through Method：一种方法几乎不执行任何操作，只是将其参数传递给具有相似签名的另一种方法（请参见第46页）。
• 重复：一遍又一遍的重复代码（请参见第62页）。
• 特殊通用混合物：特殊用途代码未与通用代码完全分开（请参阅第65页）。
• 联合方法：两种方法之间的依赖性很大，以至于很难理解一种方法的实现而又不理解另一种方法的实现（请参阅第72页）。
• 注释重复代码：注释旁边的代码会立即显示注释中的所有信息（请参阅第104页）。
• 实施文档污染了界面：界面注释描述了所记录事物的用户不需要的实施细节（请参阅第114页）。
• 含糊不清的名称：变量或方法的名称过于精确，以至于它不能传达很多有用的信息（请参阅第123页）。
• 难以选择的名称：很难为实体提供准确而直观的名称（请参见第125页）。
• 难以描述：为了完整起见，变量或方法的文档必须很长。（请参阅第131页）。
• 非显而易见的代码：一段代码的行为或含义不容易理解。（请参阅第148页）。