《人月神话》作者Frederick P. Brooks, Jr.大师论设计原本

　　很少有人像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

《设计原本：计算机科学巨匠Frederick P. Brooks的思考》中英文版同步上市，中文版预订前500名享65折优惠！

抢购地址：http://www.china-pub.com/197442