设计原本（英文版）
2010-12-10
机械工业出版社
Frederick P. Brooks, Jr.
420
无
I write to prod designers and design project managers into thinking hard about the process of designing things, especially complex systems. The viewpoint is that of an engineer, focused on utility and effectiveness but also on efficiency and elegance.Who Should Read This Book?In The Mythical Man-Month I aimed at "professional programmers, professional managers, and especially professional managers of programmers." I argued the necessity, difficulty, and methods of achieving conceptual integrity when software is built by teams.This book widens the scope considerably and adds lessons from 35 more years. Design experiences convince me that there are constants across design processes in a diverse range of design domains. Hence the target readers are:1. Designers of many kinds. Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?
无论是软件开发、工程还是建筑，有效的设计都是工作的核心。《设计原本:计算机科学巨匠Frederick P.Brooks的思考(英文版)》将对设计过程进行深入分析，揭示进行有效和优雅设计的方法。 本书包含了多个行业设计者的特别领悟。作者精确发现了所有设计项目中内在的不变因素，揭示了进行优秀设计的过程和模式。通过与几十位优秀设计者的对话，以及他自己在几个设计领域的经验，作者指出，大胆的设计决定会产生更好的结果。 作者追踪了设计过程的演进，探讨了协作和分布式设计，阐明了哪些条件造就了真正卓越的设计者。他探讨了设计过程的具体细节，包括多种预算约束条件、美学考虑、设计经验主义及工具。同时，他将这些讨论与现实中的案例结合起来，这些案例从房屋建造到ibm的operating system/360。成功的关键因素贯穿全书，每个设计者、设计项目经理和设计研究者都应该知道。
Frederick P. Brooks，北卡罗来纳大学计算机科学系的Kenan教授。他因领导开发IBM System/360计算机家族以及Operating System/360而荣获美国国家技术奖，并因对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献而获得A. M.图灵奖。他是畅销书《人月神话》的作者。
Ⅰ models of designing chapter 1 the design question chapter 2 how engineers think of design-the rational model chapter 3 what's wrong with this model chapter 4 requirements, sin, and contracts chapter 5 what are better design process modelsⅡ collaboration and telecollaboration chapter 6 collaboration in design chapter 7 telecollaborationⅢ design Perspectives chapter 8 rationalism versus Empiricism in design chapter 9 user models-better wrong than vague chapter 10 inches, ounces, bits, dollars-the Budgeted resource chapter 11 constraints are friends chapter 12 esthetics and style in technical design chapter 13 exemplars in design chapter 14 how expert designers go wrong chapter 15 the divorce of design chapter 16 representing designs' trajectories and rationalesⅣ a computer scientist's dream system for designing houses chapter 17 a computer scientist's dream system for designing houses——mind to machine chapter 18 a computer scientist's dream system for designing houses——machine to mindⅤ great designers chapter 19 great designs come from great designers chapter 20 where do great designers come fromＶＩ trips through design spaces: case studies chapter 21 case study: beach house "view/360" chapter 22 case study: house wing addition chapter 23 case study: kitchen remodeling chapter 24 case study: system/360 architecture chapter 25 case study: IBM Operating system/360 chapter 26 case study: book design of computer computer chapter 27 case study: a joint computer center organization: triangle universities computation center chapter 28 recommended reading acknowledgments bibliography people index subject index
插图：Designers need to dig more energetically and personally into the actual experiences and processes of implementation. Even an isolated and unrepresentative implementation experience can wonderfully inform a designer's often idealized or inchoate vision of how implementation is done. I recommend it highly.There is a danger that a modest sample experience of implementation will unduly influence a design, if the designer's personal experience is all that is available——-it is by nature unrepresentative. Probably the best balance is achieved with concurrent engineering as the main design practice. Here, the true implementers are intimately involved in the design process; their broad experience provides the balance for a designer's limited implementation examples. (In the software field, this same practice sometimes is called just an agile method.)Pulling implementers forward into the design process makes its own demands. Shipyard workers who are skilled at following standard engineering drawings may be less skilled at envisioning the finished construct from the standard plans and sections, hence unable to catch mistakes or to foresee implementation "gotchas." Augmenting the standard plans and sections with richer visuals, even virtual-environment explorations, may provide the tools that lubricate the concurrent design process.
《设计原本:计算机科学巨匠Frederick P.Brooks的思考(英文版)》：计算机科学大师探究设计原本，《人月神话》作者最新力作。
无
作者大概怎么也想到他的这本书在中国被称为“——原本”。
好。。。。。。。。。。。。。。。
内容不错，但英文太深，建议读中文的
这是一本绝对的好书，送货速度也是相当的快，第二天就能到
原汁原味的版本，需要精心阅读，毕竟不是我们的母语，但论述的很透彻
感觉英文有点吃不消。建议买中文版吧。大牛除外
灰常喜欢这本书.强烈推荐计算机砖业的各位同学阅读.
因为内容没看 所以不知道好不好，但是配送速度快，纸张好。
思想就是根本，设计就是理念。
包装很到位，而且书也没有任何折压的痕迹。内容不错。很喜欢
书的味道，不是很喜欢。和想象中不同，可能是英文版的缘故吧。纸质不是很喜欢。但是书的能容还行，可能不同的出版社有各自的习惯吧。
购买的时候简单的看了看评论，没有详细了解书的内容和背景。到手后读了几篇，主要是从大规模系统的设计入手的，不是很合我的胃口，所以定位为“休闲阅读”——不过不能否认这本书还是有水准的。
值了69块大洋书还有淡淡的墨香，感觉很好！内容自然是经典了！
好书，质量不咋地
好书呀，这个一定要多看看
特意买的英文版的
林夕珍藏系列：我所爱的香港
译者的翻译水平很差。
译文里虽然没有错别字，但充满了佶屈聱牙式的直译，阅读的体验极差。一句话需要看上三五遍才能看懂；再看一遍，基本上就可以直译成英文了。
如果译者还有计划翻译类似的专著，建议译者仔细研究一下翻译理论，免得误人子弟。
好多句子不通。
“但却失之过分繁复” 这种明显影响阅读效率的句子就不能翻译的舒服点？
“经常地，多个模块以及对于同一个缺陷的多个修复会同时提供给社区”。
现在的翻译都直接保留原句句型的？
总言之，写的不错，看得很累。
我是冲着Brooks的名头去买这本书的。读的第一本Brooks的书是汪颖翻译的《人月神话》，翻译、审核都不错。然而这本《设计原本》质量应该说还有待提高。今天在飞机上花2小时仔细读了几章，发现了一些难以理解的地方。我看能否找到原文，对比一下才知道是翻译的问题还是原文就如此。
“有没有一种方法，可以作为设计的基本原则，在我每次进行设计的时候都给与我帮助？”苦于抓不到设计本质的我请教一位学习平面设计的好友。
他给我的建议是在每次设计时回答三个问题：
1.Who：这个设计的受众是谁？
2.What：这是哪方面的设计？
3How：具体应该如何去做设计？
Brooks在本书中提供了一个更加详细的理想模型：
1.目标
2.必要条件
3.效用函数
4.约束
5.资源分配，预算和关键预算
6.设计树
遗憾的是，这只是一个理想中的模型，在现实中并不一定适用，例如很难确保设计树是完备的，没有遗漏最合理的设计方案。作者推崇的Boehm模型虽然没有详细论述，但无疑更自然些，毕竟我们的自然界正是一个不断演化的产物。
关于卓越设计师的教育是我非常赞同的，在其他领域也有越来越多的人在反思类似的问题。我们的知识体系已经太过庞大，庞大到如果先去学习相关的内在原理需要花费数年的时间，而与实践相脱节的理论学习往往不能让学生把握要点。
诚然现代教育体系如同流水线培育了大批具有专业知识人才，但卓越的设计师永远不是流水线能够锻造出来的。个人认为最合理的培养机制应该是类似以往手工业流行的学徒制，教授者本来就是实际工作的参与者而不是仅仅是理论研究者。师傅能把自己的经验教训和理论知识倾囊相授，而徒弟能在掌握理论知识的同时具体地去参与真实项目的设计工作。这样的培养方式对师傅的要求很高，徒弟的数量也上不去，但为了得到卓越的设计师，这一切都是值得的。
这部巨作是《人月神话》作者布鲁克斯最新力作。译者说，《诗》有之：“‘高山仰止，景行行止’。虽不能至，然心向往之。”在此引用一下，果然是大师之作啊。 在书中，布鲁克斯尖锐地指出： ”很多设计者从心理上和实践上都没有对设计过程进行很好的理解。大部分的设计成本是返工，即纠正错误，这通常达到总成本的1/3。平庸的设计肯定是浪费了世界的资源，破坏了环境，影响了国际竞争力。“ 良好的设计不仅可以工作，而且能带来快乐。本书指引工程师关心效用和功能的同时也注重效率和优雅。设计的最高境界：不是一个技术活儿，而是一个艺术活儿。作者通过桥梁的设计来类比，确实，软件设计也是一个工程类的设计，这个和我们的建筑设计、桥梁设计等等都是一样的。这个本身可以是一个创造美的过程！ 没有一个学科是可以独立的，布鲁克斯还是个不错的建筑设计师呢。所以说，触类旁通，学术间的交叉融合可以带来不一样的惊喜！我个人的感受是，软件设计原来不是那一小片天！这是布鲁克斯告诉我的。 在第二章《工程师怎样进行设计思维——理性模型》中，布鲁克斯以在海边盖房子这个生活化的例子来阐述设计者考虑设计过程，深入分析了设计模型背后的工程思想，通过将工程师的思维过程程序化地展现，批判了这一模型。深刻分析了它的本源，它为什么能够生存，从而自然而然地指出它的缺陷，指导我们在什么情况下用比较和谐。同样，作者在书中对主流开发的各个方面进行了描述,但是缺乏解决的具体手段和思考策略,作者也希望的是读者自己根据书中的线索去领悟自身需要的设计思考方式，因为设计是没有界定的吧。布鲁克斯鼓舞我们：大胆的设计决定会产生更好的结果。 此外，书中附有不少的设计插图，便于读者理解，不错。是一本值得收藏的好书！
2011年是IBM 诞生一百周年，IBM全球董事长及首席执行总裁彭明盛SamJ.PalmIS ano于2011年2月在美国约翰霍普金斯大学发表了IBM百年系列活动的开幕演讲。这100多年的历史告诉我们了些什么呢？记得，在IBM 50周年庆上，小汤姆沃森，也就是IBM公司的董事长和其创始人的儿子在在另一所伟大大学的讲堂里，向未来的领导人们发表了演讲。当年演讲时，全球财富500强企业的前25家企业，在2010年只有四家依然存在。
而IBM100年的历史人物中，有一个人物不得不提，那就是IBM 360系统之父计算机科学巨匠Brooks。或许中国的很多读者还不认识他，但提及这本刚推出的《设计原本》可以说是作者功成名就之后，从业60年的巅峰之作。
作者在从业60年里，扮演过软件架构师、建筑设计师、企业家、作者等几个的重要角色，作者发现所有行业背后的设计过程都是出乎一致的一样。于是将自己60年的经验集结成书，告诉大家只要你能做好一件事，就能做好任何一件事情背后的设计过程。
详情：http://site.douban.com/widget/notes/1288347/note/134998039/
团购书名：《设计原本:计算机科学巨匠frederick p. brooks的思考》中文版+英文版
团购截止日期：3月7日 12:00
最终团购折扣说明（每个地址限购3套）
总报名累计1 — 99套 6.8折
总报名累计100 — 199套 6.5折
总报名累计200 — 299套 6.2折
总报名累计300 — 399套 6.0折
总报名累计400 — 499套 5.5折
总报名累计500套以上 5.0折
团购报名总人数查询：http://www.sojump.com/jq/620608.aspx
计算机大师心中的建筑设计情怀
Frederick P.Brooks 在计算机领域可谓是无人不晓。他因领导开发IBM System/360计算机系列以及操作系统而荣获美国国家技术奖，因为对其计算机体系结构研究作出的里程碑式的贡献而获得了A.M.图灵奖。
布鲁克斯在他60多年的职业生涯中涉及了计算机架构、软件、房屋、图书和组织机构五个领域的工作，而且作者发现这些领域里，设计过程都极为相似，比如思维过程、人与人的交互、迭代、约束条件和劳动等。而他在IBM公司100年之际推出了他的新作《设计原本》，也就是要让人们反思这些隐藏在这些设计活动背后不变的设计过程。
在建筑设计方面，布鲁克斯设计过程的演进，探讨了协作和分布式设计，阐明了哪些条件造就了真正的卓越设计者。他解释了设计过程的具体细节，包括多种预算约束条件、美学考虑、设计经验主义及工具，同时他将这些讨论与现实中的案例结合起来，这些案例从房屋建造到计算机的系统设计。
一本品位独特的图书。
很少有人像Frederick P. Brooks, Jr. 一样对软件开发的实践（而不是学术理论）产生那么大的影响。他在《人月神话》中记录了他作为IBM System/360计算机以及Operating System/360项目领导者的经验，这些经验不断地促使我们形成项目管理的观念。很难找到比他的“没有银弹：软件工程中的根本问题和次要问题”（《Information Processing 1986, Proceedings of the IFIPS Tenth World Computer Conference》，H.-J. Kugler编辑。Amsterdam: Elsevier Science, 1069-1076）一文被引用更多的文章。“银弹”的概念代表了对困难的软件和编程问题的某种近乎神奇的解决方案，这是我们的词汇表中不可缺少的一个词。
Brooks的这本新书《设计原本》拓展了他以前的思想，添加了对设计的本质和重要性的新领悟。毫无疑问，这本书将会成为所有专业开发者书架上必备的书籍。
这本书的副书名是“计算机科学巨匠Frederick P. Brooks的思考”。书中包含了可以作为独立的文章进行阅读的20章，每一章与其他章的耦合都比较松散。这是好事，因为大多数读者都希望阅读本书的每一章（不一定要按顺序），然后在继续下一章阅读之前思考一下所讲的内容。除了这些文章外，这本书还提供了8个案例，涉及的范围从海滩小屋的设计到IBM System/360的架构。这些案例阐释了本书中的一些重要概念。
什么是设计？Dorothy Sayers（英国作家和戏剧家，Brooks引用了他的话）说设计有3个阶段：概念构造的形成，在真实媒质上的实现，与真正用户的交互。Brooks在他的“银弹”一文中指出，第一个阶段（即概念构造）是软件工程最困难的阶段。但在1986年时，“概念构造”似乎更侧重计算机在执行指令时内部发生了什么。在这本新书中，关注的重点更多地转移到架构、外观，以及程序工件与环境的交互上。有趣的是，Brooks在第1章的开始引用了培根的话：
（新思想来自于）将一门艺术中的领悟联系并应用到另一门艺术中，历经若干次这样的经历而有所悟，脑海里自然就孕育出了“新思想”。
这清晰地表达了跨学科的灵感和锻炼。Brooks没有深入这个概念，即使在后面的内容中讨论如何“创造”了不起的设计师时，他也没这样做。
有几章讨论了设计和设计过程的模型。Brooks在这里严厉批评了流行的“理性主义者”设计模型（读者可能最熟悉的就是“瀑布方法”），并断言“理性模型过于简单”。书中指出了理性模型的诸多缺陷，包括“对理性模型的最具破坏性的批评可能是，最有经验的设计完全不是这样工作的”。（在本书中提到David Parnas多次，但没有提到他的著名文章“The Rational Design Process: How and why to fake it”，这篇文章也对理性模型提出了严厉批评。）本书对其他一些设计模型也进行了讨论，包括：
·迭代演进式开发，与此最接近的是Brooks对敏捷方法的讨论。
·Boehm的螺旋模型。
·开源的、Raymond的“集市模型”。
这些讨论的结论是：设计需要某种过程以及该过程的模型（主要是为了沟通并支持协作），Barry Boehm的螺旋模型是Brooks认为最有希望的模型。
《设计原本》中的其他章节关注了以下几个问题：
·协作与团队设计，包括远程协作所引发的问题。
·关于“理性主义”与“经验主义”的讨论，Brooks自认是一个经验主义者。
·约束条件的价值。其中印证了许多“设计”文献，这些文献来自工业、产品和图形设计师。设计草案（用于启动设计过程的文档）必须足够模糊，允许自由思考和表达，但必须清楚定义所有的约束条件。约束条件勾画出边界，创造性的、有想像力的、创新的设计将在这个边界之内发生。
·讨论美与风格。
·一些关于设计技术和实践的讨论，Brooks发现它们是有价值的。
·需求、罪过与合约。
·一个案例，讲述了为什么任务控制语言（Job Control Language, JCL，如果你没有在大主机上工作的愉快经历的话）可能是“有史以来最糟糕的编程语言”！
本书末尾用两章的篇幅讨论卓越的设计和卓越的设计师的问题。Brooks果断指出，卓越的设计来自卓越的设计师，而非卓越的设计过程。Brooks说，我们教育和培训软件专业人员的方式无助于培养出卓越的设计师。他指出，培养卓越的设计师的一个主要障碍就是缺少持续的实践和批评。
InfoQ有机会对Brooks提出了一些跟进问题，本文包括了这次访谈的内容。问题与回答如下：
开发项目有一个生命周期，要么是经典的线性瀑布式，要么是迭代增量式（敏捷）。设计是在生命周期特定阶段发生的事情，还是分布在所有阶段？
它集中发生在迭代开发的前面几次循环，但有时候发生在所有迭代中。
如果设计发生在所有的开发阶段中，是否在每个阶段中具有不同的形式、实质或要点？
当然是这样的！在第一次迭代中，总体架构是中心问题。在接下来的迭代中，设计工作集中于更精细的层面，除非是在满足最后期限之后的回溯，或者人们意识到需求的改变或新的机会。
约束条件在设计过程中扮演什么角色？（本问题的背景知识：其他领域的设计师常常依赖一份“草案”，他们预期/需要草案中有模糊之处，以便能够自由地“设计”，但他们需要清楚表达约束条件，这些约束条件定义了目标区域，最优设计只能在这个区域中产生。）
它们既促成了整体架构，又在较小程度上促成了细节设计。
是否有明显可以确定的设计“错误”，它们是否能在犯下时就可以意识到？（或者，这样的错误是否像代码中的缺陷，通常需要在犯下之后许久才发现？）
大错是在开始时犯下的，而且很少意识到。如果最终被发现，通常是在现场实施之后。较小的错误是在编码开始时出现，或者是在第一个真正的用户测试原型时被发现。
大多数设计师认为他们的活动是高度协作的，至少是客户与设计师之间的协作，但设计更多时候涉及一个团队。您是否同意设计是一种协作？如果是这样，设计团队的地理分布或临时分布会带来什么影响？（显然，在今天的离岸外包环境中寻求并行设计，以应对软件开发的一般挑战。）
我用了两章讨论协作和远程协作。是的，今天大多数的设计都涉及团队。通用产品的设计不涉及与客户的协作，如iPad。对于为一个客户设计定制的产品，我非常喜欢对原型和代用品（如建筑的虚拟环境模型）尽早地、激烈地、频繁地、不断地进行用户测试。但是，我不认为这是与用户和客户进行协作设计。
您是否有一份清单，例如6点建议，可以总结您的书向设计者提供的最重要的经验？
1）专心研究以前设计者的工作，看看他们如何解决问题。
2）尝试弄明白他们为什么做出那样的设计决定，这是对你自己最有启发性的问题。
3）仔细研究以前设计者的风格。最好的方式是尝试用他们的一些风格勾画设计草图。
4）保存一本“草图本”，将您的想法、设计和局部设计记录下来，不论使用何种媒质。
5）在开始设计时，写下您对用户和使用方式的假定。
6）设计、设计、设计！
在您的“银弹”文章中，您谈到了“概念构建”和人类在头脑中完成这项工作时遇到的巨大困难。您觉得在这本书中一些思想是否关注并解决了概念构造这一基本困难？
肯定关注了，肯定没解决。
在第3章中，您漂亮地批评了理性设计过程，特别是瀑布式方法所包含的理性设计思想，并指出这种思想是有害的，必须抛弃。您对这种有害模型的持续存在有何看法？是否人们就是很倔强？或者尽管开发者更了解，但管理层会犯错？是否有一些文化上的偏见（尤其是西方文化上的偏见）阻碍人们抛弃瀑布模型？
第4章讨论了软件工程中的瀑布模型的持续存在（在其他学科中并不常见）是因为设计者过早期望得到有约束力的合同和确定的需求。
在第20章中，您批评了我们的教育系统（温和，但确是事实），并建议设计者需要参与“批评性实践”。Richard Gabriel长期以来一直主张计算机科学/软件工程大纲应该采用他在取得诗歌硕士学位时一样的大纲（他在很久之前获得了计算机科学博士学位）：大量的练习（每天至少一首诗）、大量的批评（来自同学和导师）、勤奋学习大师和大师的诗歌、不断自省、周期性的反省。这似乎与您的建议相似，那么您是否主张大学提供一个“软件好艺术硕士”学位？
不。熊恩在《the Education of the Reflective Practitioner》一书中提出了同样的建议，还有例子，更适合设计。所有的工程学大纲都应该强调这种方式。
哪些其他领域的研究将有助于毕业生变成卓越的软件设计师？
1）算法和数据结构是最重要的基础课程。
2）计算机硬件架构。
3）应用领域，特别是商业数据处理、数据库技术和数据挖掘。
4）心理学，特别是知觉心理学，因为用户是最重要的。
理性设计过程，实际上是所有计算机科学和软件工程，有意识地采用了宇宙的基本模型（20世纪的物理学），即确定性的、机械的、理性的宇宙。如果那就是自然或现实，那么理性的、搜索树式的设计过程模型就很有意义。如果宇宙实际上是复杂的适应性系统，那么理性模型就会失效。您是否走得更远，奠定了复杂系统的设计或修改过程的基础，如文化或商务企业？
我不会自大到建议这样的东西。
IDEO是一家非常有名的设计公司，它的总裁Tom Kelly写了一些关于设计、设计过程和设计思考的书。他最好的一本书是《Ten Faces of Innovation》，其中他确定了每个设计团队需要的10个角色（人类学家、实验员、嫁接能手、跨栏运动员、合作者、指导者、用户体验设计师、布景师、专业护理人员和讲故事的人）。如果您知道这本书，是否类似的角色应该出现在软件设计团队中？怎样做到？
我不了解这本书。听起来有趣，而且有用。
您提到了Christopher Alexander和他的影响并在注释中提到了《The Synthesis of Form and A Pattern Language》一书。那代表了“理性的Alexander”，但“Timeless Way of Building”和他的杰作“Opus, Nature of Order”却更为“神秘化”。“神秘的Alexander”是否对您的设计和设计过程思想有所影响？
我受到了《The Timeless Way of Building》一书的影响。
软件领域的设计将大多数注意力放在人工制品上，即执行程序的计算机。越来越多的实践（但学术界还没开始）开始关注“用户体验设计”，即计算机所处的系统和生态环境。对于用户体验设计者如何从本书中获益，您是否有一些建议？
我觉得前面给出的建议同样适用于用户体验设计，但这个领域与软件工程领域相比，自由式教育更为重要。
您能列举出值得所有人学习的3名设计大师（任何领域）和3名软件设计大师，4至5个设计杰作，并简单说明为什么吗？
·巴赫，作曲家
·伦勃朗，画家
·Seymour Cray，超级计算机设计师
·Christopher Wren，建筑，特别是他在伦敦设计的教堂
·Nicholas Wirth，计算机语言
·Donald Knuth，算法
我不认为所有的人都应该学习同样的例子。人们需要接受范例的设计原则方面的基本教育，这样才能深入研究一个范例，欣赏这些设计问题和解决方案。但是，即使是门外汉也能欣赏一致性和设计概念的统一性。
原文网址：http://www.infoq.com/articles/brooks-design-book-review
本书中国互动出版网china-pub正在低价火热预订中，网址：http://www.china-pub.com/197442。
《设计原本:计算机科学巨匠frederick p. brooks的思考》对设计过程进行深入分析，揭示进行有效和优雅设计的方法，包含了多个行业设计者的特别领悟。作者精确发现了所有设计项目中内在的不变因素，揭示了进行优秀设计的过程和模式。通过与几十位优秀设计者的对话，以及他自己在几个设计领域的经验，指出，大胆的设计决定会产生更好的结果。
作者追踪了设计过程的演进，探讨了协作和分布式设计，阐明了哪些条件造就了真正卓越的设计者。他探讨了设计过程的具体细节，包括多种预算约束条件、美学考虑、设计经验主义及工具。同时，他将这些讨论与现实中的案例结合起来，这些案例从房屋建造到ibm的operating system/360。成功的关键因素贯穿全书，每个设计者、设计项目经理和设计研究者都应该知道。
简单介绍下（引自http://ideaskestrel.appspot.com/?p=10001）
1.设计的定义，什么是设计？
1）The formulation of the conceptual constructs
2）Implementation in real media
3）Interactivity with users in real use
关于设计，本身实现，测试，验证也都是设计的一个组成过程，不是说概念构建好了设计就完成了。
2.设计的一些模式（Design Models)，设计的理想中的模型当然是瀑布模型，通过概念上的设计树，理论上只需要穷举这棵树的所有 分 支，总是可以找到方案的。但是现实上有些情况是行不通的，因为 - The hardest part of design is deciding what to design.如果把设计看成问题解决的一个过程，对于问题空间和解空间的认识都是不断的深化的。对于设计来说，对问题的认识，也就是对需求的把握，我这里引用一些书中提到的见解：
- A chief service of a designer is helping clients discover what they want designed.
- Any attempt to formulate all possible requirements at the start of a project will fail
and would cause considerable delays.
- About requirements,not only wish list,but also constraints,prioritized,weightings,these
are also important information.
Generating requirements by committee, by the nature of the
beast, tends to produce products that are too rich,reject the impractical requirements,
extract the essence.
关于瀑布模型，是这么论述的：
- How can we explain the persistence of the Waterfall Model:
The one-word answer is sin: pride, greed, and sloth.
Because humans are fallen, we cannot trust each other’s
motivations. Because humans are fallen, we cannot communicate
perfectly.For these reasons, “Get it in writing.” We need written agreements
for clarity of communication; we need enforceable contracts for
protection from misdeeds by others and temptations for ourselves.
显然，作者更倾向于迭代的设计模型：
CO-Evolution Designing Models:
It seems that creative design is not a matter of first fixing the problem
and then searching for a satisfactory solution concept. Creative
design seems more to be a matter of developing and refining
together both the formulation of a problem and ideas for a solution,
with constant iteration of analysis, synthesis and evaluation processes
between the two notional design ‘spaces’—problem space and
solution space.
The model is evolutionary in that both the understanding of the problem and
the development of the solution are incrementally generated and incrementally
evaluated.
3.关于协作的设计(Collaboration)
在这本书中，作者多次强调了设计的概念完整性（Conceptual Integrity)的重要性，概念完整性带来的一致性也使得系统更容易被学习，被理解。而协作设计最大的挑战是如何保持概念完整性。这里提到一个不错的作法，就是联想到很多的建筑设计都是通过招标方式来筛选好的设计，不同的设计团队针对同样的项目提出各自的设计方案，然后最优秀的方案将会中标，软件设计是否也可以借鉴这种方式？因为竞争可以刺激出更完善的想法。另外设计Review也是一个很重要的环节，设计Review主要应该着重于质疑，设计者将会针对这些质疑阐述理由。
4.关于设计的一些观点（Design Perspectives）
1)学习设计的典型范例（Exemplars)可以避免愚蠢的重复发明，但是不能忽视其相对应的约束条件和假设的前提。当这些假设不存在的时侯，原来正确的设计就不一定还适用于你的现实情况。这也是为什么设计专家仍然可能会犯错误 - 按照过往成功系统的经验来设计，而没有注意到某些假设在实际情形下已经不成立了。
- The designer should know well the exemplars of his craft, their strengths, their weaknesses. originality is no excuse for ignorance.
- In engineering, if not in the arts, gratuitous innovation (that is, not anticipated to be “better” in some useful sense) is a foolish idea and a selfish indulgence of pride—because of the unavoidable risk of unintended downside consequences.
- Designers who master the styles of their predecessors have more treasures upon which their originality can draw.
2)研究失败的案例比学习成功的案例更能让人收获良多。
3)使用者模型
设计者经常自觉不自觉的把自己当成用户，并以此作出关于使用者的假设。而这些假设可能是错误的。尽管这样， 把这些假设清晰的表达出来也比停留在对使用者模型模糊的认识上更好，因为这样更容易被质疑。（因为清楚的表达出来，记录下来了。）
4)Constraints Are Friend
设计专用型的应用相比通用型的应用来说，专用型的设计更容易造就杰出的设计，因为种种特定的限制缩小了设计者所有搜索的解空间。
5)设计风格：
- Orthogonality: Do Not Link What Is Independent.（正交性）
- Propriety: Do Not Introduce What Is Immaterial.（高内聚）
- Generality: Do Not Restrict What Is Inherent.
6)关于设计过程的一些见解
- Design Isn’t Just to Satisfy Requirements, but Also to Uncover Requirements
- Design Isn’t Simply Selecting from Alternatives, but Also Realizing Their Existence
5.伟大的设计者
- 预先制定的软件过程往往会抑制伟大的设计，因为软件过程是预先设定的框架，倾向于做可预见的事情，缺少自然的混乱，重点是工期控制，按规则办事，为避免失误过于小心，不会做过多的尝试，不会采取极端的方案，通常会选择妥协， 而不是作出伟大的设计。而且，伟大设计者的宝贵的时间经常被浪费在为寻求一致而召开的一些会议室上。
- 那么，软件过程（Product process）主要适合于follow-on类型的产品，而不是革命性的产品。它虽然无法造就 伟大的设计，但是确实对中庸的设计者有帮助。伟大的设计一定出自伟大的设计者之手。Great designs do not come from great processes; they come from talented people doing hard work. Apple is quoted as saying, “We’re at Level I [on the Capability Maturity Model] and will always be.”Yet Apple’s results speak for themselve
- Great Designers Require Bold Leaders Who Demand Innovation.First and foremost, the top leader of the organization must passionately want innovative products with great designs.
- Growing Yourself as a Designer:
1)Constantly Sketch Designs(经常不懈的做草图设计）
Leonardo’s Notebooks are a rich example of how this is best practiced. The aspiring young software designer might well keep a notebook of patterns he encounters and invents in his own constructions.
2)Seek Knowledgeable Criticism of Your Designs(从批判性的实践中学习知识）
3)Study Exemplars and Precedents(从模范和范例中学习)
Each great designer mastered the rich legacy of his predecessors and then added his own
new concepts.In approaching a precedent design, it is crucial to assume competence—the right
question is“What led such a smart designer to do that?”rather than“Why did he do such a fool thing
as that?”Usually, the answer lurks in the designer’s objectives and constraints; discovering it usually
brings new insights.
4)A Self-Education Project—Floor Plan for a 1,000-Square-Foot House
6.Case study
卓越设计师，也可以批量生产，只是暂时没人设计出这样的课程而已。
就像是卓越的程序，可以无限复制一样。
太泛泛了,如果能把其中一个点说明白就好了.
标准的社论书评.
Telecollaboration 这个感觉应该是远程协作吧，电信协作……
远程协作是正确的