设计原本
当前位置:首页 > 计算机网络 > 计算机理论 > 设计原本
出版社:机械工业出版社
出版日期:2011-1-1
ISBN:9787111325574
作者:Frederick P. Brooks, Jr.
页数:268页
章节摘录
版权页：插图：理性模型是一种自然的思维模型。理性模型，如上所述、如上所评，似乎看上去相当幼稚。但它是人们能够自然而然地想到的一种思维模型。其思维自然程度可以从Simon版本、瀑布模型版本以及Pahl和lBeitz版本分别独立地提出而得到强烈的印证。然而，从最早的时候开始，设计界就有了对于理性模型有说服力的批评。设计师们根本不那样做事。也许对理性模型最具解构性的批评——尽管也许亦是最难以证明的——就是经验最丰富的设计师根本不那样做事。虽然已经发表出来的批评只是偶尔才会有“皇帝没有穿衣服耶！”这样指出该模型并未反映出专业实践做法的呛声，但是人们还是可以感觉到不厌精细的分析背后的这种压倒性的主张。。 Nigel Cross，其绅士般的言论，也许是最具张力的不同意见。引经据典之下，他毫不讳言地说：有关问题求解的习惯思维，往往看起来和专家级设计师们的行为背道而驰。不过，设计活动和使用习惯思维进行问题求解的活动有着相当多的不同之处……我们必须在从其他领域引入设计行为模型时倍加小心。对于设计活动的实证研究经常会发现，“有直感力的”设计能力乃是最有成果的，也是和设计的内廪性质最密切相关的。不过，设计理论的有些方面就是企图针对设计行为开发出反直觉的模型和处方来。又及，在绝大多数设计过程的模型中都忽视了性质上处于同等地位的设计推理。在有着公论的关于设计过程的模型中，比如说由德意志工程师协会颁布的模型中（VDI，1987）……就主张设计活动应该分成一系列的阶段进行……在实践中，设计活动似乎是以在子解域和子问题域的区间振荡的方式进行，同时也是将问题分解，尔后合并所有的子解决方案的过程。我发现，这个争鸣意见本身以及其实证材料都很具说服力。此处提及的振荡的确可以说是我所有设计经验的特点所在。“外套在哪里摆放？”这样的需求发掘了我们房屋设计过程的深层次内容就是个典型例证。Royce对于瀑布模型的批评。Royce在他的论文原稿中描述了瀑布模型，以便他能够演示其不足之处。”他的基本观点在于，尽管在毗邻方块之间有反向箭头表示逆向的工作流，但是该模型仍然行不通。不过，他的对策仅仅是采取了容许逆工作流箭头指回两个前向方块的模型罢了。治标不治本。
内容概要
Frederick P. Brooks 北卡罗来纳大学计算机科学系的Kenan教授。他因领导开发IBM System/360计算机家族以及Operating System/360而荣获美国国家技术奖，并因对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献而获得A. M.图灵奖。他是畅销书《人月神话》的作者。
书籍目录
Frederick P. Brooks Jr. 论设计的本质
译者序
前言
作者简介
第一部分 设计之模型
第1章 设计之命题
1.1 培根所言是否正确
1.2 什么是设计
1.3 何为真实？设计的概念
1.3.1 价值何在
1.4 对于设计过程的思考
1.5 设计类别
1.5.1 系统设计与艺术设计
1.5.2 常规，适应性，原创设计
第2章 工程师怎样进行设计思维——理性模型
2.1 模型概览
2.2 该模型的构思从何而来
2.3 理性模型有哪些长处
第3章 理性模型有哪些缺陷
3.1 我们在初始阶段并不真正地知道目标是什么
3.2 我们通常不知晓设计树的样子——一边设计一边探索
3.3 （设计树上的）节点实际上不是设计决策，而是设计暂定方案
3.4 有用性函数无法以增量方式求值
3.5 必要条件及其权重在持续变化
3.6 约束在持续变化
3.7 对于理性模型的其他批评
3.8 但是，尽管有这些缺陷和批评，理性模型仍然不屈不挠地存在
3.9 那又如何？我们的设计过程模型真的那么事关紧要吗
第4章 需求、罪念以及合同
4.1 一段恐怖往事
4.2 殊为不幸，无独有偶
4.3 抵制需求膨胀和蠕变
4.4 罪念
4.5 合同
4.6 一种合同模型
第5章 有哪些更好的设计过程模型
5.1 为什么要有一个占主导地位的模型
5.2 共同演化模型
5.3 Raymond的集市模型
5.3.1 运作机理
5.3.2 模型优势
5.3.3 什么时候可以采用集市模型
5.4 Boehm的螺旋模型
5.5 设计过程模型：第2 ~ 5章的讨论小结
第二部分 协作与电信协作
第6章 协作设计
6.1 协作是在本质上是好的吗
6.2 团队设计是现代标准
6.2.1 为什么工程设计从个人转向团队
6.3 协作的成本
6.4 挑战是概念完整性！
6.4.1 异议
6.5 如何在团队设计中获得概念完整性
6.5.1 现代设计是各学科间的协商吗
6.5.2 系统架构
6.5.3 一名用户界面设计师
6.6 协作何时有帮助
6.6.1 确定利益相关人的需求和愿望
6.6.2 概念探索—激进的可选方案
6.6.3 设计复查
6.7 协作何时无用—对设计本身
6.7.1 概念设计尤其不应该协作
6.8 两人团队很神奇
6.9 对于计算机科学家意味着什么
第7章 电信协作
7.1 为什么要电信协作
7.1.1专业化
7.1.2 家
7.1.3整天工作不停
7.1.4成本
7.1.5政策
7.2 到那里，做那事—IBM System/360计算机系列的分布式开发，1961–1965
7.3 让电信协作有效
7.3.1 面对面的时间很重要
7.3.2 干净的接口
7.4 电信协作的技术
7.4.1 低科技常常足够
7.4.2视频会议
第三部分 设计观点
第8章 设计中的理性主义与经验主义
8.1 理性主义与经验主义
8.2 软件设计
8.3 我是个铁杆的经验主义者
8.4 其他设计领域中的理性主义、经验主义与正确性
第9章 用户模型——错误胜过含糊不清
9.1 明确的用户与用例模型
9.2 果真如此吗
9.3 团队设计
9.4 假如事实不可用该如何是好
9.4.1 猜测
9.4.2 错误胜过含糊不清
第10章 英寸、盎司、位与美元——预算资源
10.1 何谓预算资源
10.2 美元并非万灵丹
10.3 即便美元也有不同，替代品剖析
10.4 预算资源是可变的
10.5 那又如何
10.5.1 明确确认
10.5.2 公开跟踪
10.5.3 严格控制
第11章 约束是我们的朋友
11.1 约束
11.2 不完全如此
11.3 设计悖论：通用的产品要比特定用途的更难以设计
11.4 小结
第12章 技术设计中的美学与风格
12.1 技术设计中的美学
12.2 何谓逻辑美
12.2.1 简约
12.2.2 结构清晰
12.2.3 一致性
12.2.4 什么才是好的计算机架构
12.4.5 一致性的更多优点
12.6 技术设计中的风格
12.7 何谓风格
12.8 风格的属性
12.9 要想获得一致的风格——记录下来
12.10 如何获得良好的风格
第13章 设计中的范本
13.1 很少会有全新的设计
13.2 范例的角色
13.3 计算机与软件设计呢
13.3.1 你使用何种范本
13.4 学习范本的设计原理
13.4.1 第一代计算机
13.4.2 第三代计算机
13.4.3 虚拟内存
13.4.4 小型计算机的变革
13.4.5 微型计算机与RISC的变革
13.5 如何训练才能改进基于范本的设计
13.5.1 范例集合
13.5.2 超越集合
13.5.3 软件设计怎样呢
13.6 范本——懒惰、创意与自满
13.6.1 一些观点
13.6.2 懒惰
13.6.3 创意与自满
第14章 专业设计者缘何犯错
14.1 错误
14.2 曾经最糟糕的计算机语言
14.2.1 何谓JCL
14.2.2 JCL到底怎么了
14.2.3 JCL缘何是这个样子的
14.3小结
第15章 设计的分离
15.1 设计与使用和实现的分离
15.2 为什么分离
15.3 分离的结果
15.4 补救措施
15.4.1 补救措施1：用户场景体验
15.4.2 补救措施2：通过增量式设计和增量式交付与用户密切交互
15.4.3 补救措施3：并发工程
15.4.4 补救措施4：设计者的教育
第16章 展现设计的演变途径和理由
16.1 简介
16.2 知识网线性化
16.3 我们的设计演变途径记录
16.4 我们研究房屋设计过程的过程
16.4.1 什么是设计树
16.5 深入设计过程
16.5.1 设计不只是满足需求，也是发现需求
16.5.2 设计不是简单地选择可选方案，也是意识到它们的存在
16.5.3 设计变化时树也变化—如何展现演进过程
16.6 决策树与设计树
16.7 模块化与紧密集成的设计
16.8 Compendium和可选工具
16.8.1 Task Architect
16.8.2 项目管理工具
16.8.3 IBIS和它的衍生品
16.8.4 Compendium
16.9 DRed：一个诱人的工具
第四部分 计算机科学家设计房屋的梦想系统
第17章 计算机科学家的建筑设计理想系统——从思维到机器
17.1 挑战
17.2 一个设想
17.2.1 渐进完善
17.2.2 模型库
17.2.3 渐进完善模式的不足
17.3 从思维到机器输入的设想
17.3.1 名词-动词组合
17.4 说明动词
17.5 说明名词
17.6 说明文字
17.7 说明助词
17.8 说明视点和视图
17.8.1 内部视图
17.8.2 外部视图
第18章 计算机科学家的建筑设计理想系统——从机器到思维
18.1 双向通道
18.2 视觉显示——多并发窗口
18.2.1 制图桌和绘图视图
18.2.2 2D内容视图
18.2.3 3D视图
18.2.4 外部视图
18.2.5 工作手册视图
18.2.6 规格视图
18.3 声音展示
18.4 触觉展示
18.5 泛化
18.6可行性
第五部分 卓越的设计师
第19章 卓越的设计来自卓越的设计师
19.1 卓越的设计和产品过程
19.2 产品过程：优点和不足
19.2.1 产品过程抑制了卓越的设计吗
19.2.2 为什么要有产品过程
19.3 观点碰撞：过程抑制，过程不可避免；怎么做
19.3.1 卓越的设计来自卓越的设计师，去找到他们
19.3.2 卓越的设计需要大胆的领导者，他们要求创新
19.3.3 如何设计一个鼓励卓越设计的过程
19.3.4寻求概念完整性：信任一名主设计师来完成设计
第20章 卓越的设计师从哪里来
20.1 我们必须教他们设计
20.2 我们必须为卓越设计而招募人才
20.3 我们必须深思熟虑地培养他们
20.3.1 让两架梯子真实而体面
20.3.2 规划正式的教育经历
20.3.3 规划不同的工作经历
20.3.4 规划离开组织机构去休假
20.4 管理他们时必须发挥想象力
20.5 必须严密地保护他们
20.5.1 防止他们分心
20.5.2 保护他们不受管理者干扰
20.5.3 防止他们去做管理
20.6 把自己培养成一名设计师
20.7 不断画设计草稿
20.8 寻求有知识的人对您的设计的批评
20.9 研究教学示例和先例
20.10 一个自我教育项目：1000平方英尺房屋的建筑平面图
第六部分 设计空间之旅：案例研究
第21章 案例研究：海滨小屋“View/360”
21.1 亮点和特性
21.2 背景介绍
21.3 目标
21.4 机会
21.5 约束条件
21.7 设计决定
21.8 考虑正面
21.9 小屋的尺寸
21.10 设想的开始
21.11 在设计之后，构建之前的设计改动
21.12 在框架和外墙完成和初次入住之后的设计改动
21.13 评估（在37年后）
21.13.1 乐事
21.13.2 实用性
21.13.3 牢固性
21.13.4 如果我“废弃一个计划”呢
21.14 学到的一般经验
第22章 案例研究：增加厢房
22.1 亮点和特性
22.2 背景介绍
22.2.1 背景
22.3 目标
22.3.1 最初目标
22.3.2 后来发现的目标
22.4 约束条件
22.5 非约束条件
22.6 事件
22.7 设计决定和迭代
22.7.1 考察
22.7.2 分割设计问题
22.7.3 东部
22.7.4 西部一半的功能安排
22.7.5 方式变化：忘掉预算是设计约束条件
22.7.6 新发现的需求：
22.7.7 功能安排的会合
22.7.8 构建期间的改动
22.8 评估——成功与未解决的缺点
22.8.1 新功能
22.9 学到的一般经验
第23章 案例研究：厨房重新建模
23.1 亮点和特性
23.2 背景介绍
23.2.1 背景
23.3 目标
23.4 机会
23.5 约束条件
23.6 关键宽度预算的推理
23.6.1 从北到南需要的宽度
23.6.2 试验性的设计
23.6.3 另一些宽度解决方案
23.6.4 最终的宽度设计
23.7 长度预算的推理
23.8 其他设计决定
23.8.1 照明
23.9 评估
23.10 满足的其他迫切需求
23.11 在设计中使用图纸、CAD、模型、仿真模型和虚拟环境
23.11.1 虚拟环境的发现
23.12 学到的一般经验
第24章 案例研究：System/360体系结构
24.1 亮点和特性
24.2 项目介绍和相关背景
24.2.1 相关背景
24.3 目标
24.3.1 主要目标
24.3.2 其他重要目标
24.4 机遇（截至1961年6月）
24.5 挑战和限制
24.6 最重大的设计决策
24.7 里程碑事件
24.8 结果评估
24.8.1 稳定性
24.8.2 有用性——竞争力，各个市场的分析
24.8.3 闪光点
24.9 取得的经验教训
第25章 案例研究：IBM Operating System/360操作系统
25.1 亮点和特性
25.2 项目介绍和相关背景
25.2.1 System/360系列机型
25.2.2 1961年的软件格局
25.3 接受挑战
25.4 设计决策
25.4.1 系统架构
25.5 结果评估
25.5.1 成功之处
25.5.2 设计中的不足
25.5.3 流程中的不足
25.6 设计师团队
25.7 取得的经验教训
第26章 案例研究：《Computer Architecture: Concepts and Evolution图书设计
26.1 亮点和特性
26.2 项目介绍和相关背景
26.2.1 相关背景
26.3 项目目标
26.4 机遇
26.5 约束
26.6 设计决策
26.7 结果评估
26.8 经验教训
第27章案例研究：联合计算中心组织：三角区大学计算中心
27.1 亮点与特性
27.2 介绍与内容
27.2.1 内容
27.3 目标
27.3.1 主要目标
27.3.2 其他目标
27.4 机会
27.5 约束
27.6 设计决策
27.7 董事会所考虑的投票方案
27.7.1 权力均衡的限定
27.8 测量评估
27.8.1 牢固性
27.8.2 实用性
27.8 经验总结
第28章 推荐阅读
致谢
参考文献
编辑推荐
《设计原本:计算机科学巨匠Frederick P.Brooks的思考》：如果说《人月神话》是作者刚刚完成若干个改变了全球计算系统格局的重大项目，在人生和事业的巅峰时期的激情之作，那么《设计原本:计算机科学巨匠Frederick P.Brooks的思考》则是作者功成名就之后。在研究和教学中将先前在设计领域中的探索心得和实践经验切磋琢磨、去伪存真、取其精华的反思之作。可以说，比起锐气有余的《人月神话》，《设计原本:计算机科学巨匠Frederick P.Brooks的思考》更多了几分高屋建瓴的大局观以及数十年如一日积淀而成的丰富材料，是设计领域真正的大师之作。《设计原本:计算机科学巨匠Frederick P.Brooks的思考》几乎涵盖所有有关设计的议题：从设计哲学谈到设计实践，从设计过程到设计灵感，既强调了设计思想的重要性，又对沟通中的种种细节都做了细致入微的描述，并且谈到了因地制宜做出妥协的具体准则。其中，作者特别强调的是设计的概念完整性，这不仅对于设计过程中步骤流转时的信息传递十分关键，并且也是沟通中最需要重点注意的地方。全书的案例研究是另一大亮点，在进行抽象的模型和思想论述时，作者时时注意运用图表和案例说话，深入浅出地表达复杂艰涩的思想。并通过层次丰富的案例。展示了设计既能治大国，又可烹小鲜的强大力量和无穷魅力。我们能够从作品的字里行间感受到计算机体系结构刚刚诞生的黄金年代充满了怎样的设计思想和工程实践的生机和活力。而作者也十分擅长专业史料的记载和整理，并且以他独有的方式为读者展示出极为清晰的脉络。无论是软件开发、工程还是建筑，有效的设计都是工作的核心。《设计原本:计算机科学巨匠Frederick P.Brooks的思考》将对设计过程进行深入分析，揭示有效和优雅设计的方法。《设计原本:计算机科学巨匠Frederick P.Brooks的思考》包含了多个行业设计者的特别领悟。作者精确发现了所有设计项目中内在的不变因素，揭示了优秀设计的过程和模式。通过与几十位优秀设计者的对话，以及他自己在几个设计领域的经验，作者指出，大胆的设计决定会产生更好的结果。作者追踪了设计过程的演进，探讨了协作和分布式设计，阐明了哪些条件造就了真正卓越的设计者。他解释了设计过程的具体细节，包括多种预算约束条件、美学考虑、设计经验主义及工具。同时，他将这些讨论与现实中的案例结合起来，这些案例从房屋建造到IBM的Operating System／360。贯穿全书的成功的关键因素，是每个设计者、设计项目经理和设计研究者都应该知道的。《人月神话》作者最新力作，计算机科学大师探究设计原本。
作者简介
无论是软件开发、工程还是建筑，有效的设计都是工作的核心。《设计原本:计算机科学巨匠Frederick P. Brooks的思考》将对设计过程进行深入分析，揭示进行有效和优雅设计的方法。
本书包含了多个行业设计者的特别领悟。Frederick P. Brooks, Jr.精确发现了所有设计项目中内在的不变因素，揭示 了进行优秀设计的过程和模式。通过与几十位优秀设计者的对话，以及他自己在几个设计领域的经验，作者指出，大胆的设计决定会产生更好的结果。
作者追踪了设计过程的演进，探讨了协作和分布式设计，阐明了哪些条件造就了真正卓越的设计者。他探讨了设计过程的具体细节，包括多种预算约束条件、美学考虑、设计经验主义及工具。同时，他将这些讨论与现实中的案例结合起来，这些案例从房屋建造到IBM的Operating System/360。成功的关键因素贯穿全书，每个设计者、设计项目经理和设计研究者都应该知道。
图书封面
发布书评
精彩书评 (总计21条)
-
注：【】部分为笔者心得，非原文摘抄。* 新思想来自于将对一门艺术的领悟联系并应用到另一门艺术中，历经若干次这样的经历而有所悟，脑海里自然就孕育出了新思想。——《The Two Books of the Proficience and Advancement of Learning》* 设计代表着：* * 概念性构思的形成；* 在真实的媒体中实现；* 在真实的体验中与用户交互。* 对大多数的创作者来说，构思的不完整性和bu'yi'zhi'xing 只有到了实现的时候才变得明显起来。* 构思、实现和交互这三个阶段的操作是循环进行的。* 【想法需要实践才能得以完善。】* 良好的设计j具有概念的一致性——统一、经济、清晰。* 【不要相信项目经理说的“我们前期抓紧点儿，后期就不用太辛苦”，这是句笑话！不过也不要因此而放松对困难的警惕，我的意思是全程都要抓得很紧。】* 现实情况是，设计师只把理性模型视为一种理想化的东西。它以某种方式描述了在我们的认识中设计过程应该如何运作，但在现实生活中，并不是那么一回事。* 设计中最困难的部分在于决定要设计什么。* 设计师的主要任务是帮助客户发现他们想要的设计。* 要在设计过程的一开始就明确地列出已知的约束，作为架构师所谓的设计任务书的组成部分。* 任何在项目伊始就规划所有的可能需求的企图都会失败，并以可观的延误告终。——《Engineering Design》* 需求激增现象必须予以钳制，方法是防患于未然或将这种势头遏制于摇篮之中。* 及早任命手腕强硬、经验丰富、领域知识到位的经理，并要求他们在整个初始系统交付期间全程参与。尔后，授权他们“以其认为必要的方式度身定制标准流程和步骤”。* 创新性设计并不是先把问题定死，再去寻找一个令人满意的概念解决方案这么一回事；它似乎更像是对于问题的构造本身以及解决方案的思路这两者同时进行研发和完善的工作。——“创造型设计中问题和解空间的共同演化”* 所有设计过程都共有的关键要素在于对用户的需求、希望和验收标准的发掘。* 与具有代表性的用户保持经常性的而非连续不断的互动，沟通的手段则是相继改进的原型。* 线性地按部就班的理想模型具有很大的误导性。* 【智力密集型工作不遵循“人多力量大”。】* 在团队设计中，确保概念完整性最重要的方式就是授权给一名系统架构师。此人必须在相关的技术领域具有能力。他必须对要设计的这类系统拥有经验。最重要的是，他必须对系统的特点和目的具有清晰的愿景，必须真正关心系统的概念完整性。* 头脑风暴的标准规则是：关注数量、不要批评、鼓励发散思维、组合并改进想法和勾画出所有想法让大家能看到。* 概念设计尤其不应该协作。* 真实的设计有着更复杂的目标和更复杂的约束条件要满足，对于满意程度的测量也更复杂。真实的设计总是爆发出无数的细节。* 真实的团队设计总是需要一个设计变更控制过程，以免我们左手弄坏右手创造的东西。* 无论多少协作都不能消除对“枯燥无味的劳作和孤独的思考”的需要。* 远程协作技术让越来越多的专业人士能够住在他们喜欢的地方，并在别处工作。* 【远程团队协作必须保证所用的所有设计和开发软件版本一致。】* 最成功的远程协作建立在大量的面对面沟通的历史基础之上。* 有用的工具创造总是从用户和任务开始的，最好是在工具创造者有一个真正的用户和一个真正要完成的任务时。* 理解力有两种形式：直觉与推演。无论哪一种都需要以知识作为后盾。——《Rules for the Direction of the Mind》* 分析得越精细，就越能精确地度量出必要条件的满足程度以及约束的遵从程度。* 真理来源于错误而非混乱。——《新工具》* 假设越详细、越明确就越有助于设计者们提早进行具体的思考。* 缜密的猜测胜于无言的假设。* 总架构师必须具备率领团队前进的能力。* 明确的假设即便是错误的也要好于含糊的。错误的假设起码会受到质疑，而含糊的则不会。* 如果希望设计，特别是团队设计具备概念完整性，那么你应该明确地指定好稀缺资源，公开地跟踪并严格控制它。* 设计者的必要行为是有意识地预算。* 整个团队需要清楚关键资源的当前预算。* 只能有一个人来控制预算与重新预算，这是必须的。* 通用产品要比特定用途的产品更难于设计。* 一般来说，目的越具体，设计任务就会越容易。* 风格是思想的外衣，良好的思想就像是穿着考究的绅士一样更具优势。——Chesterfield勋爵* 好的建筑架构要满足“坚固、效用与情趣”的要求。——Vitruvius* “优雅”需要简约。* 【真正的简约并不束缚发展空间。】* 技术设计中的“优雅”要求设计中基本的结构性概念要易于为人所理解，否则逻辑就应该是直截了当且易于解释的。* 没有包含所需功能的架构是错误的架构。* 不要将独立的东西耦合起来。* 不要引入无形的东西。* 【组件设计应该保持与整体风格一致。】* 要想获得一致的风格，就得写成文档。* 清晰的风格未必是好的风格，但混乱的风格则绝非好的风格。* 有抱负的设计者必须要为风格的一致性而奋斗。* 设计团队必须将设计恰当地记录下来，团队还必须在维护阶段保持概念上的完整性，将管理与构成可视化设计的各种微观决策记录下来。* 有目的地学习其他设计者的风格。* 为你的产品选择拥有清晰风格与高品位的设计者，根据他们之前的工作作出判断。* 在任何设计领域中都不能懒惰，都需要高度的热情与勤勉才能掌握大量的范本。* 7天的惊奇很快就会过去。随着新颖的退却，情趣也将一并消失。寻找新奇事物的人永远都是被动的。没有永恒不变的情趣。* 把欲望当做动力会让很多作品走向堕落。* 困扰专业设计者的错误不在于错误地设计了东西，而是设计了错误的东西。* 对于专业设计者来说，成功是一件危险的事情。失败会促使人们去分析、仔细审查以及重新思考。成功会导致设计技术与设计者过度自信。这两种信任可能会发生错位。* 个人产品的设计者总是其用户。* 在修复你不懂的东西时，要小心。* 设计不只是满足需求，也要发现需求。* 设计不是简单地选择可选方案，也需要意识到存在潜在的可选方案。* 金字塔、大教堂以及火箭之所以存在，并不是拜几何、结构理论或者热力学所赐，而是因为这是它们的创造者灵光一闪的产物。——《Engineering and the Mind's Eye》* 渐进完善模式真正的危害在于范本库本身。拙劣的样本、太少的模型、过于狭隘的范围——这些不足之处都将极大地限制呈现出来的设计。* 卓越的设计来自卓越的设计师，而不是来自卓越的设计过程。* 从过程的本质上来说，产品过程是“面向否决”的，目标是阻止不好的想法并且抓到疏忽。* 对于创新而言，人们必须跳到过程之外。* 卓越的设计需要大胆的领导者，他们要求创新。* 经理本身一定不能对设计放马后炮。* 每个超出一般水平的人都接受了两种教育：第一种来自他的老师；第二种更私人也更重要，来自他自己。——《Memoirs of My Life and Writings》* 必须为卓越设计而招募人才。* 培养设计师与培养经理不同，第一件事就是要为他们打造一条职业发展道路，让他们的报酬和社会地位能够反映他们对创新企业的价值。* 寻求有知识的人对你的设计进行批评。* 即使是诚实的、有能力的、尽职的架构师也会犯错误。* 任何成功的设计都需要你维护很长时间。* 架构总是可以看成是设计过程的原型。——《The Sciences of the Artificial》* 大多数项目需要将总时间表的更多部分投入设计工作之中。* 从相同的体系结构出发，给出多个并存的实现。* 对于全新的设计，而非后续产品而言，从一开始就要将设计工作的一部分投入在性能及其它必要属性指标的建立上，并做好成本估算。* 市场预测的方法论是为后续产品，而不是为全新的创新产品所设计的。* 【让一线人员参与决策。】* 给予系统架构师以充分的设计授权。 -
2011年是IBM 诞生一百周年，IBM全球董事长及首席执行总裁彭明盛SamJ.PalmIS ano于2011年2月在美国约翰霍普金斯大学发表了IBM百年系列活动的开幕演讲。这100多年的历史告诉我们了些什么呢？记得，在IBM 50周年庆上，小汤姆沃森，也就是IBM公司的董事长和其创始人的儿子在在另一所伟大大学的讲堂里，向未来的领导人们发表了演讲。当年演讲时，全球财富500强企业的前25家企业，在2010年只有四家依然存在。而IBM100年的历史人物中，有一个人物不得不提，那就是IBM 360系统之父计算机科学巨匠Brooks。或许中国的很多读者还不认识他，但提及这本刚推出的《设计原本》可以说是作者功成名就之后，从业60年的巅峰之作。作者在从业60年里，扮演过软件架构师、建筑设计师、企业家、作者等几个的重要角色，作者发现所有行业背后的设计过程都是出乎一致的一样。于是将自己60年的经验集结成书，告诉大家只要你能做好一件事，就能做好任何一件事情背后的设计过程。 -
译者的翻译水平很差。译文里虽然没有错别字，但充满了佶屈聱牙式的直译，阅读的体验极差。一句话需要看上三五遍才能看懂；再看一遍，基本上就可以直译成英文了。如果译者还有计划翻译类似的专著，建议译者仔细研究一下翻译理论，免得误人子弟。
精彩短评 (总计101条)
-
理解高层次的设计理念，对以后设计系统架构，多方面多角度理解问题，发现潜在问题，很有帮助。 -
用心看，用心理 -
概念完整性 -
非常牛逼，非常没用。太能东拉西扯了，我的蛋好疼。 -
刚开始读 -
我的年度最佳之一 -
看了一点 不敢妄论 -
:
TP311.5/4224-6 -
设计之设计。 -
这种上流的书我档次太低体会不到精髓... -
计算机科学巨匠的思考，真本书真正的教会我们如何思考。虽然书写的不错，但是看过之后真心感觉中文版翻译的真是太烂了。 -
这本书并不是介绍具体的计算机领域的设计案例，而是站在更高的维度，从工程师设计的角度，讲解了设计过程中需要面临的过程挑战、约束、目标、协作等问题的探讨 -
我想一把火烧了机械工业出版社。书中案例对我来说有些遥远，评价一般。 -
讲了很多os360开发,IBM开发这个系统的故事, 讲了开源的集市开发,是人月神话之后, 又一力作,项目经理和管理者以及设计人员更应该读些书 -
应该说The Design of Design是一本很有趣味的书， Frederick P. Brooks, Jr.在多个领域中进行的架构设计精彩而又有价值，揭示了设计的本质。很多设计的经验、技巧都是来自于作者的开发经历，而且作者本人在架构中承担了重要的角色，从中看到了作者对纯粹的架构设计和计算机架构、建筑设计、组织架构设计的思想，感觉受益匪浅。架构设计并不只是在纸上画出一个草图甚至知识大脑中的一个结构，就像德鲁克对管理的描述类似，它是一种实践的过程，通过优秀的设计，实实在在的发现需求，并且满足需求，确定的开发出系统；不但要考虑所有可能的属性和约束，而且要能够确定无疑的实施，是通过确定的工具和方法论系统真实的被完成，或者证明错误，对过程也要有管理和设计；而且动态的应对变化。 -
作者是个通材，硬件，软件，建筑，写作。每章的内容很少，都是泛泛而谈，很难有深入的认识，自己太外行，或者能力不足以参透。但我猜一个同时喜欢这么多东西的读者应该会读得很爽。 -
没看呢。不知道怎么就让我写评论了。。。汗 -
书不错，要想有收获的话，比较费心。翻译水准实在不敢恭维，编辑很随意地选择了几个人翻译，似乎是只要学校不错，翻译过东西，或者有热心，就ok了。等写完，看翻译成这样，将就着出版了。只能说，一本好书，被一个不负责任的编辑糟践了。 -
以前看过人月神话，现在又看着本设计原本感觉真的很不错，如果几年前看几好了。呵呵 -
一般吧。。。 -
书比较薄，不过内容很实在。 -
读过关于设计非常有见解，深入浅出的解析设计、框架的基本要素 -
万事皆系统，系统须设计。如何设计、设计纬度……各学科通用，大有助益。 -
都不知道该如何归类。严格意义上。我不能算是看过 -
纯属收藏了 -
很不错的一本书，不过理论性很强，适合细细品读，反复阅读。 -
从s/360的经验中总结了需求和最终程序实现之间如何进行需求分析和设计决策，经验很实在 -
难得的好书，受益匪浅。 -
有深度，不是那种随便看看的总结、观点，讲了作者对软件设计的深刻理解。 -
纸质一般，帮老公买的，内容无法评论。 -
网站设计现在很重要 -
自己还暂时不能理解完全，以后再看 -
冲着《人月神话》作者去的，看完有点小失望。 -
翻译还是有点问题 但总体来说不错了;如何衡量系统的权重, 对于系统要考虑的方方面面 不错的参考散列点.应当会是对于"系统"经验越多 感受越深 -
内容好，印刷质量一般 -
好看，一下午读完不是梦 -
不过书的质量还是很不错的，内容也挺充实 -
精华需要沉淀，很好，值得持续品读 -
大师的作品，值得阅读！ -
它让我第一次面对广义系统设计的具体内容。很少有这样跨领域的设计师以跨领域地态度描写设计活动了。 -
看了前面，看了有点难懂 -
很好 业余时间看看 好好 -
对于理解设计
还是有一定帮助的！ -
在迷途中摸索，不如借鉴下前辈们的想法。 -
读了一半，目前没有什么感觉。 -
帮朋友买的，感觉不错哈，包装很好 -
这本书比想象中生动有趣，以房屋建造等策划案例，来描绘出一个项目从设计到实现的流程。 -
观点很精辟，推荐订阅该书 -
大概是因为自己缺乏经验吧，难以跟作者产生共鸣。作者自己都承认是经验主义者。纸上得来终觉浅，绝知此事要躬行。 -
似懂非懂要再读一遍。
-
路上用零散时间读的，平时不大从这个层面看问题，还是有些启发的， -
没有多少比《人月神话》新鲜的东西，最后的几个案例也无太大价值。培根说，将对一门艺术的领悟联系并应用到另一门艺术中，经过若干次这样的经历而有所悟，脑海里自然就孕育出了新思想。作为一项工程，总是喜欢和建筑类比，但建筑自人类伊始就有了，而软件工程不足百年，而且建筑的设计可以数字化控制了...... -
光看英文的序我就知道要买了，大牛的经验之作 -
大师之作 值得拥有 慢慢阅读 -
我这个小白看不大懂。。。 -
“ 设计师的主要任务乃是帮助客户发现他们想要的设计”（18页）
我们干的更多只是工匠活而已 -
和预想的不同，名为设计原本但并不是对设计思想的专门论述，而只是一本专题文集。 -
螺旋模型也许是最好的模型，因为需求在一开始就确定是很少见的。团队设计最重要的是设计概念的完整性。最佳的设计也需要范本来超越，卓越的设计需要卓越的设计师。 -
其名其妙，不知所云。字面意思不难，但看不出跟设计的联系。大家都说软件不像建筑，作者偏偏爱用自家房子举例。 -
书不错，正在看，值得一读 -
只能说大师的杰作确实不同凡响，感觉国内的顶尖人物还是和国外有很大差距的，在国内这个浮躁的环境是不可能有这样的作品的，很难有人能够像作者一样沉淀下来。理论科学的研究是一切科学技术的基本，中国现在只能说是和人家越来越远，差距越来越大。这和整体的社会风气和科学风气是分不开的，那些只知道向钱看的所谓专家和教授不知道还要祸害到什么时候。在社会上混的越久越能体会那种中国的浮躁和自己的无奈。希望我们国家能够沉淀下来，不要再像暴发户。 -
书是好书，但是模仿《几何原本》（Elements of Geometry）把《The Design of Design》翻译成《设计原本》有故意拔高的嫌疑，而且大概是出于这个原因，翻译上也显得文邹邹的，搞清楚读者群好不好，俺们理工科出身不好那口之乎者也，别东施效颦了！另外，把莱特（Wright）兄弟翻译成“怀特兄弟”，您哪儿的口音？摘要与心得：http://book.douban.com/review/6231417/ -
1、有高度。
2、读后让你内心很平静，有提升超脱的感觉。 -
每种提出都表现出作者的专业水平 -
还正在看 不过风格的确别具一格 开篇就比较吸引人 -
Brooks的一些很珍贵的项目经验分享 -
还没看完 质量不错 -
当到货，大师的作品，应该错不了 -
有点吊，还得看几遍 -
很好，很形象，正在读。 -
图文并茂，讲设计，而不单单是软件的设计 -
还行，设计的本质是约束条件下，对外来前瞻性和对当前的兼顾。这一点没写出来 -
看不懂 -
还没工作，没啥感触，先买了没事看看 -
事实上拜读之后，我获得的最大的启发是在项目管理而不是设计本身。设计毕竟是个过于庞大的话题，不可能通过这样薄薄的一本书简单的陈述完整，我认为这也超出了作者的能力（毕竟即使只是单纯的软件/硬件设计现在也有巨大的分化和差别，这一点作者也提到了）。但宗师毕竟是宗师，每次提到一些项目运行的话题和一些底层设计的时候，还是总能提出非常有启发性的观点。
第八章读得我晕头转向，不清楚是翻译还是哲学名词的问题，或者是当时状态不够清醒，试看原文：
仅仅依靠深思熟虑就能正确设计好复杂的对象吗？……经验主义者认为可以；理性主义者认为不行。
理性主义者认为……在经过……足够仔细的思考后……可以做出完美无暇的设计。
经验主义者认为人类天生就是有瑕疵的……人类做的任何事都是有瑕疵的……任务……根据实验找出瑕疵。
笛卡尔……理性主义者观点；John Locke……提出了经验主义者观点。
（以上均出现在 P.71）
笛卡尔拥抱经验主义，而 Locke 则认为理性主义是数学的基石。（P.74）
以上是我觉得前后矛盾的文字。
PS. 作者在装修厨房的时候居然动用虚拟现实实验室……羡慕啊 -
举例虽然琐碎，但是意在揭示本质。 -
经典且易懂 -
确实翻译得很糟糕。。完全有失原作的风采。读起来磕磕绊绊的，而且晦涩难懂。看完中译本感觉心情很不好，所以又去看原本了。结果原本很惊艳，这下子心情更不好了。。唉。。什么时候关于计算机的优秀丛书可以翻译得好一点呢？ -
设计的设计是什么？ -
大师作品，引人思考啊！何时中国才能有类似的研究呢？ -
经典杰华，值得阅读！ -
不愧为巨著，非常好，强烈推荐 -
《人月神话》的作者有一大作 -
软件设计的新经典 -
书的内容真的很不错。我相信，如果你有这本书就喜欢上的。 -
这个版本翻译的太差，还是要看原版 -
看不太懂 又或者是本书讲的层次比较高一点 难以运用到实际工程之中 -
作者就是写《人月神话》那个。书名很唬人，其实主要还是讲软件设计的，只不过推广了一下。应该是文集，结果很散没有中心思想。 -
我的看法是参考下吧，还行。 -
2014-08-15：没怎么看懂，层次太高了，海滨小屋的设计对买房子有参考价值。//2014-07-01：公司借的，还没看几页 -
为什么不给积分啊？？？？？？？？？？？？？？？？？？？？？？？？？？？？ -
大师的书，工作一段时间后再回头看一遍 -
设计方面的high level的书籍，并不局限于软件设计 -
有过一定工程经验的人看应该会更有感触 -
翻译得不好。内容也比较碎。 -
好书需要慢慢读的 -
物流快
质量好
还没看 -
软件工程必须多个人完成是一个骗局 -
通用的设计思维方式。 - 可能高度不够，看得迷糊
-
没怎么看懂