软件设计的哲学（中文版）A Philosophy ofSoftware Design (John Ousterhout) (Z-Library)

软件设计的哲学 来源：http://gdut_yy.gitee.io/doc-aposd

⽬录 原⽂：http://gdut_yy.gitee.io/doc-aposd/ 斯坦福教授、Tcl 语⾔发明者 John Ousterhout 的著作《A Philosophy of Software Design》，⾃出版以来，好评如潮。按照 IT 图书出版的惯 例，如果冠名为“实践”，书中内容关注的是某项技术的细节和技巧；冠 名为“艺术”，内容可能是记录⼀件优秀作品的设计过程和经验；⽽冠名 为“哲学”，则是⼀些通⽤的原则和⽅法论，这些原则⽅法论串起来，能 够形成⼀个体系。正如”知⾏合⼀”、“世界是由原⼦构成的”、“我思故我 在”，这些⽿熟能详的句⼦能够⼀定程度上代表背后的⼈物和思想。⽤ ⼀句话概括《A Philosophy of Software Design》，软件设计的核⼼在于 降低复杂性。 前⾔ 第 1 章 介绍 第 2 章 复杂性的本质 第 3 章 ⼯作代码是不够的 第 4 章 模块应该是深的 第 5 章 信息隐藏(和泄漏)

第 6 章 通⽤模块更深⼊ 第 7 章 不同的层，不同的抽象 第 8 章 降低复杂性 第 9 章 在⼀起更好还是分开更好？ 第 10 章 定义不存在的错误 第 11 章 设计它两次 第 12 章 为什么写评论呢？四个理由 第 13 章 注释应该描述代码中不明显的内容 第 14 章 选择的名字 第 15 章 先写评论 第 16 章 修改现有的代码 第 17 章 ⼀致性 第 18 章 代码应该是显⽽易⻅的 第 19 章 软件发展趋势 第 20 章 设计性能 第 21 章 结论 总结

前⾔ 原⽂：http://gdut_yy.gitee.io/doc-aposd/preface.html Preface People have been writing programs for electronic computers for more than 80 years, but there has been surprisingly little conversation about how to design those programs or what good programs should look like. There has been considerable discussion about software development processes such as agile development and about development tools such as debuggers, version control systems, and test coverage tools. There has also been extensive analysis of programming techniques such as object-oriented programming and functional programming, and of design patterns and algorithms. All of these discussions have been valuable, but the core problem of software design is still largely untouched. David Parnas’ classic paper “On the Criteria to be used in Decomposing Systems into Modules” appeared in 1971, but the state of the art in software design has not progressed much beyond that paper in the ensuing 45 years. 80 多年来，⼈们⼀直在为电⼦计算机编写程序，但令⼈惊讶的 是，关于如何设计这些程序或什么是好的程序应该是什么样⼦的 讨论却很少。关于软件开发过程(如敏捷开发)和开发⼯具(如调试 器、版本控制系统和测试覆盖⼯具)，已经有了相当多的讨论。还 ⼴泛分析了编程技术，如⾯向对象编程和函数式编程，以及设计 模式和算法。所有这些讨论都是有价值的，但是软件设计的核⼼

问题在很⼤程度上仍然没有触及。David Parnas 的经典论⽂“关于 将系统分解成模块的标准”发表于 1971 年，但是在随后的 45 年 ⾥，软件设计的技术⽔平并没有超过这篇论⽂。 The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently. Problem decomposition is the central design task that programmers face every day, and yet, other than the work described here, I have not been able to identify a single class in any university where problem decomposition is a central topic. We teach for loops and object-oriented programming, but not software design. 计算机科学中最基本的问题是问题分解：如何处理复杂的问题并 将其分解为可以独⽴解决的部分。问题分解是程序员每天都要⾯ 对的中⼼设计任务，但是，除了这⾥描述的⼯作之外，我还⽆法 在任何将问题分解作为中⼼主题的⼤学中确定⼀个班级。我们讲 授循环和⾯向对象的程序设计，⽽不是软件设计。 In addition, there is a huge variation in quality and productivity among programmers, but we have made little attempt to understand what makes the best programmers so much better or to teach those skills in our classes. I have talked with several people I consider to be great programmers, but most of them had difficulty articulating specific techniques that give them their advantage. Many people assume that software design skill is an innate talent that cannot be taught. However, there is quite a bit of scientific evidence that outstanding performance in many fields is related more to high-

quality practice than innate ability (see, for example, Talent is Overrated by Geoff Colvin). 此外，程序员之间在质量和⽣产率上存在巨⼤差异，但是我们⼏ 乎没有尝试去了解什么使最好的程序员变得更好，或者在我们的 课堂上教授这些技能。我曾与⼏位我认为是优秀的程序员的⼈进 ⾏过交谈，但是他们中的⼤多数⼈都难以阐明赋予他们优势的特 定技术。许多⼈认为软件设计技能是天⽣的天赋，⽆法教授。但 是，有相当多的科学证据表明，许多领域的杰出表现更多地与⾼ 质量的实践有关，⽽不是与先天能⼒有关（例如，参⻅ Geoff Colvin 的《⼈才被⾼估》）。 For many years these issues have perplexed and frustrated me. I have wondered whether software design can be taught, and I have hypothesized that design skill is what separates great programmers from average ones. I finally decided that the only way to answer these questions was to attempt to teach a course on software design. The result is CS 190 at Stanford University. In this class I put forth a set of principles of software design. Students then work through a series of projects to assimilate and practice the principles. The class is taught in a fashion similar to a traditional English writing class. In an English class, students use an iterative process where they write a draft, get feedback, and then rewrite to make improvements. In CS 190, students develop a substantial piece of software from scratch. We then go through extensive code reviews to identify design problems, and students revise their projects to fix the problems. This allows students to see how their code can be improved by applying design principles.

多年来，这些问题使我感到困惑和沮丧。我想知道是否可以教授 软件设计，并且我假设设计技巧是区分优秀程序员和普通程序员 的原因。我最终决定，回答这些问题的唯⼀⽅法是尝试教授软件 设计课程。结果是斯坦福⼤学的 CS 190。在这⼀节课中，我提出 了⼀套软件设计原则。然后，学⽣将通过⼀系列项⽬来吸收和实 践这些原理。该课程的授课⽅式类似于传统的英语写作课。在英 语课堂上，学⽣使⽤迭代过程，在其中编写草稿，获取反馈，然 后重写以进⾏改进。在 CS 190 中，学⽣从头开始开发⼤量软 件。然后，我们将进⾏⼤量的代码审查以识别设计问题，然后学 ⽣修订其项⽬以解决问题。这使学⽣可以了解如何通过应⽤设计 原理来改进其代码。 I have now taught the software design class three times, and this book is based on the design principles that emerged from the class. The principles are fairly high level and border on the philosophical (“Define errors out of existence”), so it is hard for students to understand the ideas in the abstract. Students learn best by writing code, making mistakes, and then seeing how their mistakes and the subsequent fixes relate to the principles. 现在，我已经教过 3 次软件设计课程，并且本书是基于该课程中 出现的设计原理编写的。这些原则是相当⾼的⽔平，并且是哲学 上的边界（“定义错误不再存在”），因此学⽣很难以抽象的⽅式理 解这些思想。通过编写代码，犯错误，然后查看他们的错误以及 后续的修正与这些原则之间的关系，学⽣将学得最好。 At this point you may well be wondering: what makes me think I know all the answers about software design? To be honest, I don’t.

There were no classes on software design when I learned to program, and I never had a mentor to teach me design principles. At the time I learned to program, code reviews were virtually nonexistent. My ideas about software design come from personal experience writing and reading code. Over my career I have written about 250,000 lines of code in a variety of languages. I’ve worked on teams that created three operating systems from scratch, multiple file and storage systems, infrastructure tools such as debuggers, build systems, and GUI toolkits, a scripting language, and interactive editors for text, drawings, presentations, and integrated circuits. Along the way I’ve experienced firsthand the problems of large systems and experimented with various design techniques. In addition, I’ve read a considerable amount of code written by other people, which has exposed me to a variety of approaches, both good and bad. 在这⼀点上，您可能会想知道：是什么让我认为我知道有关软件 设计的所有答案？⽼实说，我没有。当我学会编程时，没有关于 软件设计的课程，⽽且我从来没有导师来教我设计原理。在我学 习编程时，⼏乎没有代码审查。我对软件设计的想法来⾃于编写 和阅读代码的个⼈经验。在我的职业⽣涯中，我已经⽤多种语⾔ 编写了⼤约 250,000 ⾏代码。我曾在团队中⼯作过，这些团队从 零开始创建了三个操作系统，多个⽂件和存储系统，基础结构⼯ 具（例如调试器，构建系统和 GUI ⼯具包），脚本语⾔以及⽤于 ⽂本，图形，演⽰⽂稿和集成电路的交互式编辑器。⼀路上，我 亲⾝经历了⼤型系统的问题，并尝试了各种设计技术。另外，我

已经阅读了很多其他⼈编写的代码，这使我接触到了很多⽅法， ⽆论是好是坏。 Out of all of this experience, I’ve tried to extract common threads, both about mistakes to avoid and techniques to use. This book is a reflection of my experiences: every problem described here is one that I have experienced personally, and every suggested technique is one that I have used successfully in my own coding. 从所有这些经验中，我尝试提取通⽤线程，包括有关避免的错误 和使⽤的技巧。本书反映了我的经验：这⾥描述的每个问题都是 我亲⾝经历的，每种建议的技术都是我在⾃⼰的编码中成功使⽤ 的⼀种技术。 I don’t expect this book to be the final word on software design; I’m sure there are valuable techniques that I’ve missed, and some of my suggestions may turn out to be bad ideas in the long run. However, I hope that the book will start a conversation about software design. Compare the ideas in this book with your own experiences and decide for yourself whether the approaches described here really do reduce software complexity. This book is an opinion piece, so some readers will disagree with some of my suggestions. If you do disagree, try to understand why. I’m interested in hearing about things that work for you, things that don’t work, and any other ideas you may have about software design. I hope that the ensuing conversations will improve our collective understanding of software design. I will incorporate what I learn in future editions of this book.

我不希望这本书成为软件设计的定论。我敢肯定，我错过了⼀些 有价值的技术，从⻓远来看，我的⼀些建议可能会变成坏主意。 但是，我希望本书能开始有关软件设计的对话。将本书中的想法 与您⾃⼰的经验进⾏⽐较，并⾃⼰决定此处介绍的⽅法是否确实 降低了软件复杂性。这本书是⼀个观点，所以有些读者会不同意 我的⼀些建议。如果您不同意，请尝试理解原因。我有兴趣了解 对您有⽤的东⻄，不起作⽤的东⻄以及您可能对软件设计有任何 其他想法。我希望随后的对话将增进我们对软件设计的集体理 解。 The best way to communicate with me about the book is to send email to the following address: 与我交流有关这本书的最好⽅法是将电⼦邮件发送到以下地址： software-design-book@googlegroups.com I’m interested in hearing specific feedback about the book, such as bugs or suggestions for improvement, as well as general thoughts and experiences related to software design. I’m particularly interested in compelling examples that I can use in future editions of the book. The best examples illustrate an important design principle and are simple enough to explain in a paragraph or two. If you would like to see what other people are saying on the email address and participate in discussions, you can join the Google Group software- design-book. 我有兴趣听取有关本书的特定反馈，例如错误或改进建议，以及 与软件设计相关的⼀般思想和经验。我对可以在本书未来版本中

使⽤的引⼈注⽬的⽰例特别感兴趣。最好的⽰例说明了重要的设 计原理，并且⾜够简单，可以在⼀两个段落中进⾏解释。如果您 想在电⼦邮件地址上看到其他⼈在说什么并参与讨论，可以加⼊ Google Group 软件设计⼿册。 If for some reason the software-design-book Google Group should disappear in the future, search on the Web for my home page; it will contain updated instructions for how to communicate about the book. Please don’t send book-related email to my personal email address. 如果出于某种原因该软件设计⼿册 Google Group 将来会消失， 请在 Web 上搜索我的主⻚；它将包含有关如何与这本书进⾏交流 的更新说明。请不要将与图书相关的电⼦邮件发送到我的个⼈电 ⼦邮件地址。 I recommend that you take the suggestions in this book with a grain of salt. The overall goal is to reduce complexity; this is more important than any particular principle or idea you read here. If you try an idea from this book and find that it doesn’t actually reduce complexity, then don’t feel obligated to keep using it (but, do let me know about your experience; I’d like to get feedback on what works and what doesn’t). 我建议您在本书中加些建议。总体⽬标是降低复杂性；这⽐您在 此处阅读的任何特定原理或想法更为重要。如果您尝试从本书中 获得⼀个想法并发现它实际上并没有降低复杂性，那么您就不必 继续使⽤它（但是，请让我知道您的经验；我想获得有关有效⽅ 法的反馈意⻅⽽不是）。

Many people have offered criticisms or made suggestions that improved the quality of the book. The following people offered helpful comments on various drafts of the book: Jeff Dean, Sanjay Ghemawat, John Hartman, Brian Kernighan, James Koppel, Amy Ousterhout, Kay Ousterhout, Rob Pike, Partha Ranganathan, Keith Schwartz, and Alex Snaps. Christos Kozyrakis suggested the terms “deep” and “shallow” for classes and interfaces, replacing previous terms “thick” and “thin”, which were somewhat ambiguous. I am indebted to the students in CS 190; the process of reading their code and discussing it with them has helped to crystallize my thoughts about design. 许多⼈提出了批评或提出建议，以提⾼本书的质量。以下⼈员对 本书的各种草稿提供了有⽤的意⻅：杰夫·迪恩，桑杰·格玛⽡特， 约翰·哈特曼，布莱恩·科尼根，詹姆斯·科佩尔，艾⽶·奥斯特豪 特，凯·奥斯特豪特，罗伯·派克，帕塔·朗格纳森，基思·施⽡茨和 亚历克斯·斯内普斯。Christos Kozyrakis 为类和接⼝建议了术 语“深层”和“浅层”，代替了之前有点模糊的术语“厚”和“薄”。我很感 激 CS 190 中的学⽣；阅读他们的代码并与他们讨论的过程有助 于明确我对设计的想法。

第 1 章 介绍 原⽂：http://gdut_yy.gitee.io/doc-aposd/ch1.html Chapter 1 Introduction(It’s All About Complexity) Writing computer software is one of the purest creative activities in the history of the human race. Programmers aren’t bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world. Programming doesn’t require great physical skill or coordination, like ballet or basketball. All programming requires is a creative mind and the ability to organize your thoughts. If you can visualize a system, you can probably implement it in a computer program. 编写计算机软件是⼈类历史上最纯粹的创作活动之⼀。程序员不 受诸如物理定律等实际限制的约束。我们可以⽤现实世界中永远 不会存在的⾏为创建令⼈兴奋的虚拟世界。编程不需要很⾼的⾝ 体技能或协调能⼒，例如芭蕾或篮球。所有编程都需要具有创造 ⼒的头脑和组织思想的能⼒。如果您可以可视化系统，则可以在 计算机程序中实现它。 This means that the greatest limitation in writing software is our ability to understand the systems we are creating. As a program evolves and acquires more features, it becomes complicated, with subtle dependencies between its components. Over time, complexity accumulates, and it becomes harder and harder for programmers to

keep all of the relevant factors in their minds as they modify the system. This slows down development and leads to bugs, which slow development even more and add to its cost. Complexity increases inevitably over the life of any program. The larger the program, and the more people that work on it, the more difficult it is to manage complexity. 这意味着编写软件的最⼤限制是我们了解所创建系统的能⼒。随 着程序的发展和获得更多功能，它变得复杂，其组件之间具有微 妙的依赖性。随着时间的流逝，复杂性不断累积，程序员在修改 系统时将所有相关因素牢记在⼼中变得越来越难。这会减慢开发 速度并导致错误，从⽽进⼀步延缓开发速度并增加成本。在任何 程序的⽣命周期中，复杂性都会不可避免地增加。程序越⼤，⼯ 作的⼈越多，管理复杂性就越困难。 Good development tools can help us deal with complexity, and many great tools have been created over the last several decades. But there is a limit to what we can do with tools alone. If we want to make it easier to write software, so that we can build more powerful systems more cheaply, we must find ways to make software simpler. Complexity will still increase over time, in spite of our best efforts, but simpler designs allow us to build larger and more powerful systems before complexity becomes overwhelming. 好的开发⼯具可以帮助我们应对复杂性，并且在过去的⼏⼗年中 已经创建了许多出⾊的⼯具。但是，仅凭⼯具我们只能做些事 情。如果我们想简化编写软件的过程，从⽽可以更便宜地构建功 能更强⼤的系统，则必须找到简化软件的⽅法。尽管我们尽了最

⼤努⼒，但复杂度仍会随着时间的推移⽽增加，但是更简单的设 计使我们能够在复杂性压倒性优势之前构建更⼤，功能更强⼤的 系统。 There are two general approaches to fighting complexity, both of which will be discussed in this book. The first approach is to eliminate complexity by making code simpler and more obvious. For example, complexity can be reduced by eliminating special cases or using identifiers in a consistent fashion. 有两种解决复杂性的通⽤⽅法，这两种⽅法都将在本书中进⾏讨 论。第⼀种⽅法是通过使代码更简单和更明显来消除复杂性。例 如，可以通过消除特殊情况或以⼀致的⽅式使⽤标识符来降低复 杂性。 The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once. This approach is called modular design. In modular design, a software system is divided up into modules, such as classes in an object-oriented language. The modules are designed to be relatively independent of each other, so that a programmer can work on one module without having to understand the details of other modules. 解决复杂性的第⼆种⽅法是封装它，以便程序员可以在系统上⼯ 作⽽不会⽴即暴露其所有复杂性。这种⽅法称为模块化设计。在 模块化设计中，软件系统分为模块，例如⾯向对象语⾔的类。这 些模块被设计为彼此相对独⽴，以便程序员可以在⼀个模块上⼯ 作⽽不必了解其他模块的细节。

Because software is so malleable, software design is a continuous process that spans the entire lifecycle of a software system; this makes software design different from the design of physical systems such as buildings, ships, or bridges. However, software design has not always been viewed this way. For much of the history of programming, design was concentrated at the beginning of a project, as it is in other engineering disciplines. The extreme of this approach is called the waterfall model, in which a project is divided into discrete phases such as requirements definition, design, coding, testing, and maintenance. In the waterfall model, each phase completes before the next phase starts; in many cases different people are responsible for each phase. The entire system is designed at once, during the design phase. The design is frozen at the end of this phase, and the role of the subsequent phases is to flesh out and implement that design. 由于软件具有很好的延展性，因此软件设计是⼀个贯穿软件系统 整个⽣命周期的连续过程。这使得软件设计与诸如建筑物，船舶 或桥梁的物理系统的设计不同。但是，并⾮总是以这种⽅式查看 软件设计。在编程的⼤部分历史中，设计都集中在项⽬的开始， 就像其他⼯程学科⼀样。这种⽅法的极端称为瀑布模型，该模型 将项⽬划分为离散的阶段，例如需求定义，设计，编码，测试和 维护。在瀑布模型中，每个阶段都在下⼀阶段开始之前完成；在 许多情况下，每个阶段都由不同的⼈负责。在设计阶段，⽴即设 计整个系统。 Unfortunately, the waterfall model rarely works well for software. Software systems are intrinsically more complex than physical

systems; it isn’t possible to visualize the design for a large software system well enough to understand all of its implications before building anything. As a result, the initial design will have many problems. The problems do not become apparent until implementation is well underway. However, the waterfall model is not structured to accommodate major design changes at this point (for example, the designers may have moved on to other projects). Thus, developers try to patch around the problems without changing the overall design. This results in an explosion of complexity. 不幸的是，瀑布模型很少适⽤于软件。软件系统本质上⽐物理系 统复杂。在构建任何东⻄之前，不可能充分可视化⼤型软件系统 的设计，以了解其所有含义。结果，初始设计将有许多问题。在 实施良好之前，问题不会变得明显。但是，瀑布模型的结构此时 ⽆法适应主要的设计更改（例如，设计师可能已转移到其他项 ⽬）。因此，开发⼈员尝试在不改变整体设计的情况下解决问 题。这导致复杂性的爆炸式增⻓。 Because of these issues, most software development projects today use an incremental approach such as agile development, in which the initial design focuses on a small subset of the overall functionality. This subset is designed, implemented, and then evaluated. Problems with the original design are discovered and corrected, then a few more features are designed, implemented and evaluated. Each iteration exposes problems with the existing design, which are fixed before the next set of features is designed. By spreading out the design in this way, problems with the initial design can be fixed while the system is still small; later features benefit from

experience gained during the implementation of earlier features, so they have fewer problems. 由于这些问题，当今⼤多数软件开发项⽬都使⽤诸如敏捷开发之 类的增量⽅法，其中初始设计着重于整体功能的⼀⼩部分。设 计，实施和评估此⼦集。发现和纠正原始设计的问题，然后设 计，实施和评估更多功能。每次迭代都会暴露现有设计的问题， 这些问题在设计下⼀组功能之前就已得到解决。通过以这种⽅式 扩展设计，可以在系统仍然很⼩的情况下解决初始设计的问题。 较新的功能受益于较早功能的实施过程中获得的经验，因此问题 较少。 The incremental approach works for software because software is malleable enough to allow significant design changes partway through implementation. In contrast, major design changes are much more challenging for physical systems: for example, it would not be practical to change the number of towers supporting a bridge in the middle of construction. 增量⽅法适⽤于软件，因为软件具有⾜够的延展性，可以在实施 过程中进⾏重⼤的设计更改。相⽐之下，对物理系统⽽⾔，主要 的设计更改更具挑战性：例如，在建筑过程中更改⽀撑桥梁的塔 架数量不切实际。 Incremental development means that software design is never done. Design happens continuously over the life of a system: developers should always be thinking about design issues. Incremental development also means continuous redesign. The initial design for a system or component is almost never the best one; experience

inevitably shows better ways to do things. As a software developer, you should always be on the lookout for opportunities to improve the design of the system you are working on, and you should plan on spending some fraction of your time on design improvements. 增量开发意味着永远不会完成软件设计。设计在系统的整个⽣命 周期中不断发⽣：开发⼈员应始终在思考设计问题。增量开发还 意味着不断的重新设计。系统或组件的初始设计⼏乎从来都不是 最好的。经验不可避免地显⽰出更好的做事⽅式。作为软件开发 ⼈员，您应该始终在寻找机会来改进正在开发的系统的设计，并 且应该计划将部分时间花费在设计改进上。 If software developers should always be thinking about design issues, and reducing complexity is the most important element of software design, then software developers should always be thinking about complexity. This book is about how to use complexity to guide the design of software throughout its lifetime. 如果软件开发⼈员应始终考虑设计问题，⽽降低复杂性是软件设 计中最重要的要素，则软件开发⼈员应始终考虑复杂性。这本书 是关于如何使⽤复杂性来指导软件设计的整个⽣命周期。 This book has two overall goals. The first is to describe the nature of software complexity: what does “complexity” mean, why does it matter, and how can you recognize when a program has unnecessary complexity? The book’s second, and more challenging, goal is to present techniques you can use during the software development process to minimize complexity. Unfortunately, there isn’t a simple recipe that will guarantee great software designs.

Instead, I will present a collection of higher-level concepts that border on the philosophical, such as “classes should be deep” or “define errors out of existence.” These concepts may not immediately identify the best design, but you can use them to compare design alternatives and guide your exploration of the design space. 这本书有两个总体⽬标。⾸先是描述软件复杂性的性质：“复杂 性”是什么意思，为什么重要，以及当程序具有不必要的复杂性时 如何识别？本书的第⼆个也是更具挑战性的⽬标是介绍可在软件 开发过程中使⽤的技术，以最⼤程度地减少复杂性。不幸的是， 没有简单的⽅法可以保证出⾊的软件设计。取⽽代之的是，我将 提出⼀些与哲学紧密相关的⾼级概念，例如“类应该很深”或“定义 不存在的错误”。这些概念可能不会⽴即确定最佳设计，但您可以 使⽤它们来⽐较设计备选⽅案并指导您探索设计空间。