描述
开 本: 16开纸 张: 胶版纸包 装: 精装是否套装: 否国际标准书号ISBN: 9787111416265
图灵奖得主、《人月神话》作者Brooks封笔之作，揭秘软件设计神话！程序员、项目经理和架构师必读的一本书！
如果说《人月神话》是近40年来所有软件开发工程师和项目经理们必读的一本书，那么本书将会是未来数十年内所有软硬件设计师、架构师和软件开发工程师们必读的一本书。
它是《人月神话》作者、著名计算机科学家、软件工程教父、美国两院院士、图灵奖和IEEE计算机先驱奖得主Brooks在计算机软硬件架构与设计、建筑和组织机构的架构与设计等领域毕生经验的结晶，是计算机图书领域的又一部史诗级著作。
本书从工程师和架构师的视角深入地探讨了设计的过程，尤其是复杂系统的设计过程，旨在提高产品的实用性与有效性，以及设计的效率和优雅性。
全书共28章，分为6个部分：第一部分（1～5章）主要讨论了什么是设计、设计过程的思考、设计的类别、理性模型及其缺陷，以及对一些好的设计过程模型的探讨；第二部分（6～7章）主要讨论了协作设计与远程协作；第三部分（8～16章）全面总结了设计中的各种原则、经验和教训，包括设计中的理性主义与实证主义、用户模型、资源预算、约束、设计中的美学与风格、设计中的范本、设计的分离、设计的演变途径和理由，以及专业设计者为何会犯错；第四部分（17～18章）探讨了建筑设计与计算机软硬件设计在设计思想和方法上的一些共同点和不同之处；第五部分（19～20章）探讨了卓越的设计和卓越的设计师之间的关系，以及如何培养卓越的设计师；第六部分（21～28章）对各个领域的各种类型的案例进行了分析和研究，旨在深刻揭示隐藏在这些案例背后不变的设计过程和思想。
除了从事计算机软件相关工作的读者应该阅读本书之外，其他领域的设计者、设计项目经理和设计研究人员也都能从本书中受益匪浅。
前言
第一部分 设计之模型
第1章 设计的疑问
1.1 培根的结论对吗
1.2 什么是设计
1.3 何为实在？设计理念
1.4 对设计过程的思考
1.5 设计面面观
1.6 注释和参考文献
第2章 工程师怎样进行设计思维—理性模型
2.1 模型概览
2.2 该模型的构思从何而来
2.3 理性模型有哪些长处
2.4 注释和参考文献
第3章 理性模型有哪些缺陷
3.1 在初始阶段我们并不真正地知道目标是什么
3.2 我们通常不知晓设计树的样子—一边设计一边探索
3.3 （设计树上的）节点实际上不是设计决策，而是设计暂定方案
3.4 效用函数无法以增量方式求值
3.5 必要条件及其权重在持续变化
3.6 约束在持续变化
3.7 对理性模型的其他批评
3.8 尽管存在诸多缺陷和批评，理性模型依然顽固存在
3.9 那又如何？我们的设计过程模型真的那么事关紧要吗
3.10 注释和参考文献
第4章 需求、罪念以及合同
4.1 一段恐怖往事
4.2 殊为不幸，无独有偶
4.3 抵制需求膨胀和蠕变
4.4 罪念
4.5 合同
4.6 一种合同模型
4.7 注释和参考文献
第5章 有哪些更好的设计过程模型
5.1 为什么要有一个占主导地位的模型
5.2 共同演化模型
5.3 Raymond的集市模型
5.4 Boehm的螺旋模型
5.5 设计过程模型：第2～5章的讨论小结
5.6 注释和参考文献
第二部分 协作与远程协作
第6章 协作设计
6.1 协作在本质上是好的吗
6.2 团队设计是现代标准
6.3 协作的成本
6.4 挑战在于保持概念完整性
6.5 如何在团队设计中获得概念完整性
6.6 协作何时有帮助
6.7 对设计本身而言，协作何时无用
6.8 两人团队很神奇
6.9 对于计算机科学家意味着什么
6.10 注释和参考文献
第7章 远程协作
7.1 为什么要远程协作
7.2 就地取材—IBM System/360计算机系列的分布式开发（1961～1965）
7.3 让远程协作有效
7.4 远程协作的技术
7.5 注释和参考文献
第三部分 设计面面观
第8章 设计中的理性主义与实证主义之争
8.1 理性主义与实证主义
8.2 软件设计
8.3 我是一个根深蒂固的实证主义者
8.4 其他设计领域中的理性主义、实证主义与正确性验证
8.5 注释和参考文献
第9章 用户模型—宁错勿淆
9.1 定义明确的用户模型和使用模型
9.2 团队设计
9.3 如果实际情况难以预料，有什么对策
9.4 注释和参考文献
第10章 英寸、盎司、比特与美元—预算资源
10.1 何谓预算资源
10.2 钱不是万能的
10.3 同一种资源也会有不同风格，甚至有替代品
10.4 预算资源并非一成不变
10.5 那我们究竟该怎么办
10.6 注释和参考文献
第11章 约束是友非敌
11.1 约束
11.2 归结于一点
11.3 设计悖论：通用产品比专用产品更难设计
11.4 注释和参考文献
第12章 技术设计中的美学与风格
12.1 技术设计中的美学
12.2 揭开逻辑之美的面纱
12.3 技术设计中的风格
12.4 何谓风格
12.5 风格的特点
12.6 若要使风格保持一致，请将它写成文档
12.7 如何形成良好的风格
12.8 注释和参考文献
第13章 设计中的范例
13.1 全新的设计是罕见的
13.2 范例所扮演的角色
13.3 计算机和软件设计中的问题
13.4 研究范例的设计原理
13.5 应该用什么样的方式来改进基于范例的设计
13.6 范例—惰性、创新与自满
13.7 注释和参考文献
第14章 智者千虑，必有一失
14.1 错误
14.2 曾经最糟糕的计算机语言
14.3 JCL何至于此
14.4 经验教训
14.5 注释和参考文献
第15章 设计的分离
15.1 设计与使用和实现的分离
15.2 为什么分离
15.3 分离的结果
15.4 补救措施
15.5 注释和参考文献
第16章 展现设计的演变轨迹和理由
16.1 简介
16.2 知识网线性化
16.3 我们的设计演变轨迹记录
16.4 我们研究房屋设计过程的过程
16.5 深入设计过程
16.6 决策树与设计树
16.7 模块化与紧密集成的设计
16.8 Compendium和可选工具
16.9 DRed：一个诱人的工具
16.10 注释和参考文献
第四部分 一套计算机科学家梦寐以求的房屋设计系统
第17章 计算机科学家梦寐以求的房屋设计系统—从头脑到电脑
17.1 挑战
17.2 愿景
17.3 输入机构的愿景：从头脑到电脑
17.4 指定动词
17.5 指定名词
17.6 指定文字
17.7 指定状语
17.8 指定视点和视图
17.9 注释和参考文献
第18章 计算机科学家梦寐以求的房屋设计系统—从电脑到头脑
18.1 双向通道
18.2 视觉显示—多个并列显示的窗口
18.3 听觉展示
18.4 触觉展示
18.5 推而广之
18.6 可行性
18.7 注释和参考文献
第五部分 卓越的设计师
第19章 伟大的设计来自伟大的设计师
19.1 伟大的设计与产品过程
19.2 产品过程—优点和不足
19.3 观点碰撞：过程扼杀创新，但又不可避免，如何是好
19.4 注释和参考文献
第20章 伟大的设计师从哪里来
20.1 我们必须教会他们设计
20.2 我们必须为伟大设计而招募人才
20.3 我们必须有意识地培养他们
20.4 我们必须在管理他们时发挥想象力
20.5 我们必须积极地保护他们
20.6 把自己培养成一名设计师
20.7 注释和参考文献
第六部分 设计空间之旅：案例研究
第21章 案例研究：海滨小屋“View/360”
21.1 亮点和特性
21.2 背景介绍
21.3 目标
21.4 机会
21.5 约束条件
21.6 设计决定
21.7 考虑正面
21.8 小屋的尺寸
21.9 设想的开始
21.10 在设计之后，构建之前的设计改动
21.11 在框架和外墙完成和初次入住之后的设计改动
21.12 结果评估（在项目验收37年后）
21.13 学到的一般经验
第22章 案例研究：增加厢房
22.1 亮点和特性
22.2 背景介绍
22.3 目标
22.4 约束条件
22.5 非约束条件
22.6 事件
22.7 设计决定和迭代
22.8 结果评估—成功与缺憾
22.9 学到的一般经验
22.10 注释和参考文献
第23章 案例研究：厨房重新建模
23.1 亮点和特性
23.2 背景介绍
23.3 目标
23.4 机会
23.5 约束条件
23.6 关键宽度预算的推理
23.7 长度预算的推理
23.8 其他设计决定
23.9 结果评估
23.10 满足的其他迫切需求
23.11 在设计中使用图纸、CAD、模型、仿真模型和虚拟环境
23.12 学到的一般经验
23.13 注释和参考文献
第24章 案例研究：System/360体系结构
24.1 亮点和特性
24.2 项目介绍和相关背景
24.3 目标
24.4 机遇（截至1961年6月）
24.5 挑战和限制
24.6 最重大的设计决策
24.7 里程碑事件
24.8 结果评估
24.9 学到的一般经验
24.10 注释和参考文献
第25章 案例研究：IBM Operating System/360操作系统
25.1 亮点和特性
25.2 项目介绍和相关背景
25.3 接受挑战
25.4 设计决策
25.5 结果评估
25.6 设计师团队
25.7 学到的一般经验
25.8 注释和参考文献
第26章 案例研究：《Computer Architecture: Concepts andEvolution》 图书设计
26.1 亮点和特性
26.2 项目介绍和相关背景
26.3 项目目标
26.4 机遇
26.5 约束
26.6 设计决策
26.7 结果评估
26.8 经验教训
第27章 案例研究：联合计算中心组织：三角区大学计算中心
27.1 要点和特点
27.2 项目介绍和相关背景
27.3 目标
27.4 机遇
27.5 限制
27.6 设计决策
27.7 备选的董事会投票方案
27.8 结果评估
27.9 经验教训
27.10 注释和参考文献
第28章 推荐读物
致谢
参考文献
第一部分
设计之模型
第1章 设计的疑问
第2章 工程师怎样进行设计思维—理性模型
第3章 理性模型有哪些缺陷
第4章 需求、罪念以及合同
第5章 有哪些更好的设计过程模型
第 1 章
设计的疑问
对一种技艺进行观察，并将所思所想运用到另一种技艺中，使得诸般妙用在一人的头脑中不断反思（新思维也就不期而至了）。
—弗朗西斯?培根爵士（1605），《The Two Books of the Proficience andAdvancement of Learning》卷二，第10章
很少有工程师和作曲家……能够通过探讨对方的专业作品而各取所长。我建议，他们可以共同探讨有关设计的问题……（由此）共享他们在创新性的专业设计过程中取得的经验。
—Herbert Simon（1969），《The Sciences of the Artificial》，82页
1.1 培根的结论对吗
弗朗西斯?培根爵士的猜想，也是我们所面临的挑战。设计过程本身真的有这样不变的、放诸各种设计领域而皆准的属性吗？如果真如此，擅长某种特定领域的设计师们，对于这些原理，似乎可以通过克服该领域中所独有的一些困难，而共同地得到比其他领域的设计师们更加清晰的领悟。此外，某些领域，如建筑，无论是在设计还是在高阶设计（meta-design，即设计的设计）的领域，都拥有更加悠久的历史。如果以上说法都成立，并且培根的结论也成立的话，那么即使是工作领域彼此不同的设计人员，通过对比他们的经验和洞见，也有望在其各自专长的技艺领域学到新知识。
1.2 什么是设计
《牛津英文词典》对设计这个动词的定义如下：
形成计划或方案，在头脑中整理或构思……以备后续执行。
这一定义的要点在于计划、在头脑中和后续执行。所以，设计（作为一个名词）属于受造的事物（createdobject），它先于被设计之物而存在且与后者相关，但又截然不同。英国作家、编剧DorothySayers在她那本发人深省的著作《The Mind of theMaker》里，将创作过程细分为三个不同的阶段，并分别称之为构想（idea）、运能（energy）或称实现（implementation）、交互（interaction）。1意思是：
1）将概念结构定形
2）在实际的领域中加以实现
3）在实际的应用中与用户交互
依照这种概念，无论是一本书、一台计算机，还是一个程序，都肇始于灵机一动，构思于时空之外，只在创作者的头脑中得以完成。尔后，通过钢笔、墨水和纸，或者硅和金属，在实际的时空里加以实现。最后，当有人读了这本书、用了这台计算机，或是运行了此程序时，从而与创作者的思想产生了交互，创作过程也就告一段落了。
在我以前的一篇论文中，我将构建软件的工作分为根本（essence和附属（accident）这两部分2，这两个术语引自亚里士多德，并非想要贬低软件创作中附属部分的工作。如果使用更好理解的现代术语，则是必要的（essential）和次要的（incidental）。我所指称的软件创作中的根本部分，是形成其概念结构的心智工艺；而附属部分是它的实现过程。而Sayers所谓的第三步，交互，则在软件得到使用时才会发生。
总而言之，设计就是在头脑中定形，即Sayers所谓的“构想”，它可以在任何具现步骤还没开始之前完成。有一次，莫扎特的父亲问他，有一部三周内要交付公爵的歌剧进度如何。莫扎特的回答既让人大吃一惊，又阐明了设计的概念：
曲子全都谱好了，只是还没写下来。
—致利奥波德?莫扎特信札（1780）
对大多数的创作者来说，构想的不完整性和不一致性只有到了实现阶段才变得明朗化。因此，书面记录，反复实验和“细节敲定”就成了理论家们的看家本领。
构想、实现和交互这三个阶段是交替进行的。实现创造出空间，实现过程中又要进行一轮新的设计。采用这样的方式，莫扎特使用钢笔和纸实现出他构想的歌剧，而指挥则通过与莫扎特的作品进行交互，形成了诠释该作品的一个构想，指挥的构想又通过管弦乐队和歌手的演奏加以实现，最终与观众交互，完成了整个过程。
一个设计（adesign）是一个受造的事物，我将与之相关联的设计过程称为设计（design）而不加任何冠词，还有作为动词的设计（todesign）。这三者紧密相关，我相信在具体的上下文中，它们的含义不会彼此混淆。
1.3 何为实在？设计理念
如果许多个体有共用的名字，则可以认为它们对应着同一个构想或形式。你懂我的意思吗？
我懂。
随便举个实例好了。世上有一些床和桌子，有许许多多，对吗？
对。
但是它们仅仅拥有两个构想或形式：一个是床的，一个是桌子的。
的确如此。
任何人在制作一张床或一张桌子给我们使用时，都要遵循这构想。
—柏拉图（公元前360年），《理想国》卷十
在2008年举办的第7届设计思想研讨会上，每位演讲者都发表了他们对相同四支设计团队会议的分析。3这些会议的录像和抄本都提前很早发给大家看过。
雷丁大学的Rachael Luck在架构会谈中提出一个原先未引起任何人注意，后来却被大家一致意识到的实体，即设计理念（DesignConcept）。4
毫无疑问，架构师和客户总是不断提到这个共识中的无形实体（即设计理念）。演讲者在谈及它时，常常会对着演示画面含糊地指点，但显然他们的意思并不是指整个演示画面或是画面中的某个特定事物。而他们实际上关注的总是研发中的设计的概念完整性（conceptualintegrity）。
Luck的见解让设计理念取得了独立地位，这与我本人的经验有着强烈的共鸣。在开发IBMSystem/360“大型机”（mainframe）家族的单一体系结构时（1961～1963），体系结构组就经常谈及该实体，尽管没有明确地为其正名。得益于GerryBlaauw的远见卓识，我们明确地把System/360的设计活动划分成架构（architecture）、实现（implementation）和具现（realization）的阶段。5其基本理念在于，整个计算机家族既对开发人员呈现统一的接口（即体系结构），而又能提供多种并存的实现机型（位于性能和价格曲线的不同区间）。（参见第24章）
正是因为同时存在多个实现机型，以及几位工程经理之间你追我赶，才促成了这套体系结构向更通用、更简洁的方向演化，并且避免为了省小钱而做出的妥协。然而这种力量，仅仅是架构师们出于想要捍卫各自想要做出简洁机器的直觉和心愿才达成的。6
随着体系结构设计的不断推进，我观察到一件乍看上去很奇怪的现象。对于体系结构团队而言，实在的System/360，就是设计理念本身，即那台柏拉图式的理想机器。那些在工程基础上建造出来的、物理或电子意义上的Model50、Model 60、Model 70和Model90等机型，不过就像柏拉图说的那样，是那台实在的System/360的影子。而实在的System/360最完整、最忠实的化身，并不在那些芯片或金属元件里，而是在《IBMSystem/360 Principles of Operation》这本给程序员参考的机器语言手册中的文字和图表里。7
在建造View/360海滨小屋（参见第21章）时，我也有过类似的体验。它的设计理念在建造活动开始以前很久就已经是实在的了。后来图纸和纸板模型虽然更改过多次，但是设计理念始终如一。
说起来很有意思，我从未发现在OperatingSystem/360软件家族有过这样的设计理念实体。或许其架构师觉得有，又或许我对其概念核心了解得还不够。也许我感受不到OS/360软件家族设计理念的原因在于它实际上由四个分立的部分混合而成：一个主控程序（supervisor）、一个调度程序、一个I/O控制系统，以及一个由编译器和实用工具组成的庞大软件包（参见第25章）。
价值何在
识别出隐形的设计理念，并在设计对话中转化成实在的实体，是否可以带来积极的价值呢？我认为答案是肯定的。
首先，伟大的设计都具备概念完整性—统一、经济、简洁。正如古罗马作家、建筑大师Vitruvius所说，它们不仅能有效运作，而且使人开心。8我们会使用优雅、简洁、漂亮这种字眼来形容桥梁、奏鸣曲、电路、自行车、计算机，还有iPhone。识别出设计理念这个实体，有助于我们在独立做自己的设计时去追寻这样的完整性，有助于在团队设计时围绕它协同工作，也有助于将它传授给年轻人。
其次，经常提及设计理念，对于设计团队的内部沟通也有极大的帮助。概念统一这个目标，只有通过大量的对话才能达成。
如果设计理念本身是焦点，而不是拐弯抹角的表达或残缺不全的细节，那么沟通就可以非常直截了当。
因此，电影制片人都使用故事板（storyboard）来将他们的设计讨论的关注点始终保持在设计理念上，而不会陷入实现细节。
一旦深入细节，自然会使得概念的不同版本之间的冲突显现出来，并迫使人们形成决议。例如，System/360体系结构需要一种十进制数据类型，作为已经有着成千上万用户的IBM十进制机型的兼容过渡之用。我们正在研发中的体系结构里已经有了数种数据类型，包括32位定点补码整型以及可变长字符串类型。
十进制数据类型定义成与两者中的任何一个相似都是可行的。那么，哪个更符合System/360的设计理念呢？两方面都拿出了强有力的论据，而不同的侧重点则依赖于个人对于设计理念的不同见解。有些架构师主张的设计理念受早年的科学计算机的影响，而另一些架构师主张的设计理念则受早年的商用计算机的影响。而System/360的设计目标明确地规定，对于这两种计算机上运行的应用程序都要提供良好支持。
我们选择了把十进制数据类型建立在字符串类型的基础之上，因为对于十进制数据类型这个特殊的用户群，即IBM1401的用户来说，这是他们中的大多数人最熟悉的数据类型。如果再给我一次机会，我仍然会做出这样的决定。
1.4 对设计过程的思考
有关设计的思考源远流长，至少可以追溯到Vitruvius（逝于公元前15年）。他的著作《DeArchitectura》是古典时期以来有关设计的重要文献。主要的里程碑包括达?芬奇（1452～1529）的《Notebooks》，以及AndreaPalladio（1508～1580）的《Four Books of Architecture》。
而有关设计过程本身的思考则很晚才出现。根据Pahl和Beitzr的考证，最远可以追溯到1852年，这是随着机械化生产的高涨而促成的、以Redtenbacher为代表的德国思想。9而在我本人看来，主要的里程碑包括Christopher Alexander的《Notes on the Synthesis ofForm》（1962年），Herbert Simon的《The Sciences of theArtificial》（1969年），Pahl和Beitz的《Konstructionslehre》（1977年），还有设计研究学会（DesignResearch Society）的成立以及《Design Studies》的创刊（1979年）。
Margolin和Buchanan从《DesignIssues》期刊中摘录了23篇文章，其中大部分是有关设计评论与理论的，“对理解设计所涉及的哲学问题进行了若干探讨”（见该书第xi页）。
我的《人月神话》（1975年，1995年）反映了IBMOS/360的设计过程，它后来发展成为了MVS及后续产品。那本书着重描述了这个设计与研发项目中的人、团队与管理等方面。本书第4～6章将讨论与此相关的话题。关注如何在团队设计中达成概念完整性。
Blaauw和Brooks的《Computer Architecture: Concepts andEvolution》（1997年）对IBM System/360（以及System 370到System390，再到现在的SystemZ（64位体系结构的大型机））体系结构以及数十个设计决策的相互关系和基础原理进行了大量讨论。它完全没有涉及设计过程与设计活动中人的因素。不过，该书的1.4节探讨了计算机体系结构中何为良性（goodness）的判断标准，这是与本书内容密切相关的。
1.5 设计面面观
系统设计 vs. 艺术设计
本书旨在讨论复杂系统的设计，站在工程师的视角看问题。工程师关心实用和效益，但同时也要兼顾效率和优雅。
这与艺术家和作家所完成的许多设计大相径庭，后者更强调愉悦感，以及意义的传达。当然，建筑师和工业设计师同时属于两个阵营。
例行设计、改造设计和原创设计
我们通常认为桥梁设计属于高端的工程艺术，其中，一旦形成概念或技术上的突破，就会带来激动人心的和人人可见的成本、功能和美学方面的回报。
然而，公路桥（highwaybridge）上的细分路段都很短。这么一来，50英尺的混凝土桥的设计工作就成了例行的、可自动化的过程。土木工程师们在建造短桥时，早已对设计决策树、约束以及目标了如指掌，并编制成手册了。在新平台上进行已有语言的编译器设计时，情况也一样。相当一部分都是例行的、可自动化的设计。
本书的重点在于原创设计，它不同于通过变换参数就可以一个对象接着一个对象地进行的例行设计（routinedesign），甚至也不同于改造设计（adaptive design），后者只是修改以往的设计或对象，以满足新的用途罢了。
1.6 注释和参考文献
1. Sayers（1941），《The Mind of the Maker》。
2. Brooks （1986），《No silver bullet》。
3. McDonnell （2008），《About Designing》。该书是第7届设计思想研讨会（DesignThinking Research Symposium，DTRS7）的论文汇编。
4. Luck （2009），“Does this compromise your design?”被McDonnell（2008），《About Designing》转载。
5. Blaauw和Brooks （1964），在“Outline of the logical structure ofSystem/360.”中Blaauw进一步地将Sayers提出的“运能”分解为实现和具现，我认为这个区分极其实用。
6. Janlert （1997），“The character ofthings”主张设计应该有个性，并讨论了如何设计出个性来。
7. IBM 公司（1964），《IBM System/360 Principles of Operation》。
8. Vitruvius （公元前22年），《De Architectura》。
9. Pahl和Beitz （1984），《Engineering Design》。
……
评论
还没有评论。