具体描述
程序员、项目经理和架构师终极修炼必读！
图灵奖得主、软件工程之父、《人月神话》作者 Frederick Brooks 经典著作，揭秘软件设计本质！
如果说《人月神话》结束了软件工业的神话时代，粉碎了“银弹”的幻想，从此人类进入了理性统治一切的工程时代，那么《设计原本》则再次唤醒了人类心中沉睡多年的激情，引导整个业界突破理性主义的无形牢笼，鼓励以充满大胆创新为本的设计作为软件工程核心动力的全新思维。可以说，不读《人月神话》，则会在幻想中迷失；而不读《设计原本》，则必将在复杂低效的流程中落伍！《设计原本》开启了软件工程全新的“后理性时代”，完成了从破到立的圆满循环，具有划时代的重大里程碑意义，是每位从事软件行业的架构师、项目经理和研发人员都应该反复研读的经典著作。
作者简介
Frederick P. Brooks，Jr.博士在北卡罗来纳大学教堂山分校计算机科学系担任Kenan讲座教授。由于在IBM System/360的研发项目中担任项目经理，后又在Operating System/360的设计阶段担任了软件项目经理，他以“IBM System/360之父”而闻名于世。因为这些成绩，他和Bob Evans、Erich Bloch一起荣获了1985年的美国国家技术奖章（National Medal of Technology）。 此前，他还曾经是IBM Stretch和Harvest计算机体系结构的架构师。
Brooks博士是教堂山分校计算机科学系的创建人，并担任了该系从1964年到1984年的系主任。他也曾在美国国家科学委员会（National Science Board）和美国国防科学委员会（Defense Science Board）任职。目前，他正在从事计算机体系结构、交互式计算机图形学和虚拟环境等领域的教学和研究工作。
目录信息
前言
第一部分 设计之模型
第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 and Evolution》 图书设计
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章 推荐读物
致谢
参考文献
· · · · · · (收起)
读后感
弗朗西斯·培根在《学术的进展》里提到：将对一门艺术的领悟联系并应用到另一门艺术中，历经若干次这样的经历而有所悟，脑海里自然就孕育出了新思想。 换言之，在各种领域里，无论是艺术设计还是工程设计，是存在着对于设计流程、设计方式都广泛适用的属性和经验。故...
评分标题的这句话来自于本书，这让我想起了爱因斯坦的那句话：天才是99%的汗水+1%的天分。没有1%的天分，再多的汗水也无助于你成为天才。Brooks作为项目经理，对于真正的人才是非常渴求的。 本书难得的地方在于：对于一个很宽泛的主题（设计的设计）能够说出不少有价值的话题，这一...
评分翻译的很有趣，很文学，有一两句给我印象较深： （1）诚哉斯言 （2）殊为不幸 这种用词，在计算机科学类图书中很少见，可见译者的苦心。 －－－－－－－－－－－－－－－－－－ 系统提示：抱歉，你的评论太短了 评论本就三言两语，何必强求以影响用户体验？ 如果你真的需要这种...
评分看这翻译水平，联想到译者目的，基本上就是为了在外面说起来，自己翻译过书，完全把这本书当回事，不把读者当回事，胡乱翻译。不知道这本书的编辑是干什么吃的 摘抄几句： A style consistently applied is a component, even if only the “dress,” of the conceptual integr...
评分Brooks的另外一篇著作《人月神话》，是IBM公司的System/360系统和软件系统OS/360项目开发的反省报告。OS/360是60年代开发的一个庞大软件系统，同时投入了巨大的成本包括人力，分析其开发经验和教训是非常有意义的，值得借鉴和思考，所以《人月神话》在软件史上有其重要的地位。...
用户评价
设计绝不是纯思维的产物，而从一开始就是个解决问题的工具；设计师必须面对现实中的问题，采用设计的手段解决之，并在随后的实现和应用中接受批判和考验，一轮轮地改进原始的设计，使之一方面能够以更【一致/普适/统一】、【简洁】和【经济】的方式解决问题，另一方面也在更高的意义上体现设计理念。
评分有一些不错的想法和很专业的见解，但是“原本”这个翻译很不好，毕竟并不是一本关于设计的理论书，更像是一本设计师自己的随身笔记本，杂乱的记着各种事后的反思和经验，还是值得一读
评分Design of design
评分软件架构与设计领域的《人月神话》
评分翻译得不行
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.quotespace.org All Rights Reserved. 小美书屋 版权所有