1.3 何为实在?
设计理念 如果许多个体有共用的名字,则可以认为它们对应着同一个构想或形式。你懂我的意思吗? 我懂。 随便举个实例好了。世上有一些床和桌子,有许许多多,对吗? 对。 但是它们仅仅拥有两个构想或形式:一个是床的,一个是桌子的。 的确如此。 任何人在制作一张床或一张桌子给我们使用时,都要遵循这构想。 —柏拉图(公元前360年),《理想国》卷十 在2008年举办的第7届设计思想研讨会上,每位演讲者都发表了他们对相同四支设计团队会议的分析。3 这些会议的录像和抄本都提前很早发给大家看过。 雷丁大学的Rachael Luck在架构会谈中提出一个原先未引起任何人注意,后来却被大家一致意识到的实体,即设计理念(Design Concept)。4 毫无疑问,架构师和客户总是不断提到这个共识中的无形实体(即设计理念)。演讲者在谈及它时,常常会对着演示画面含糊地指点,但显然他们的意思并不是指整个演示画面或是画面中的某个特定事物。而他们实际上关注的总是研发中的设计的概念完整性(conceptual integrity)。 Luck的见解让设计理念取得了独立地位,这与我本人的经验有着强烈的共鸣。在开发IBM System/360“大型机”(mainframe)家族的单一体系结构时(1961~1963),体系结构组就经常谈及该实体,尽管没有明确地为其正名。得益于Gerry Blaauw的远见卓识,我们明确地把System/360的设计活动划分成架构(architecture)、实现(implementation)和具现(realization)的阶段。5 其基本理念在于,整个计算机家族既对开发人员呈现统一的接口(即体系结构),而又能提供多种并存的实现机型(位于性能和价格曲线的不同区间)。(参见第24章) 正是因为同时存在多个实现机型,以及几位工程经理之间你追我赶,才促成了这套体系结构向更通用、更简洁的方向演化,并且避免为了省小钱而做出的妥协。然而这种力量,仅仅是架构师们出于想要捍卫各自想要做出简洁机器的直觉和心愿才达成的。6 随着体系结构设计的不断推进,我观察到一件乍看上去很奇怪的现象。对于体系结构团队而言,实在的System/360,就是设计理念本身,即那台柏拉图式的理想机器。那些在工程基础上建造出来的、物理或电子意义上的Model 50、Model 60、Model 70和Model 90等机型,不过就像柏拉图说的那样,是那台实在的System/360的影子。而实在的System/360最完整、最忠实的化身,并不在那些芯片或金属元件里,而是在《IBM System/360 Principles of Operation》这本给程序员参考的机器语言手册中的文字和图表里。7 在建造View/360海滨小屋(参见第21章)时,我也有过类似的体验。它的设计理念在建造活动开始以前很久就已经是实在的了。后来图纸和纸板模型虽然更改过多次,但是设计理念始终如一。 说起来很有意思,我从未发现在Operating System/360软件家族有过这样的设计理念实体。或许其架构师觉得有,又或许我对其概念核心了解得还不够。也许我感受不到OS/360软件家族设计理念的原因在于它实际上由四个分立的部分混合而成:一个主控程序(supervisor)、一个调度程序、一个I/O控制系统,以及一个由编译器和实用工具组成的庞大软件包(参见第25章)。 价值何在 识别出隐形的设计理念,并在设计对话中转化成实在的实体,是否可以带来积极的价值呢?我认为答案是肯定的。 首先,伟大的设计都具备概念完整性—统一、经济、简洁。正如古罗马作家、建筑大师Vitruvius所说,它们不仅能有效运作,而且使人开心。8 我们会使用优雅、简洁、漂亮这种字眼来形容桥梁、奏鸣曲、电路、自行车、计算机,还有iPhone。识别出设计理念这个实体,有助于我们在独立做自己的设计时去追寻这样的完整性,有助于在团队设计时围绕它协同工作,也有助于将它传授给年轻人。 其次,经常提及设计理念,对于设计团队的内部沟通也有极大的帮助。概念统一这个目标,只有通过大量的对话才能达成。 如果设计理念本身是焦点,而不是拐弯抹角的表达或残缺不全的细节,那么沟通就可以非常直截了当。 因此,电影制片人都使用故事板(storyboard)来将他们的设计讨论的关注点始终保持在设计理念上,而不会陷入实现细节。 一旦深入细节,自然会使得概念的不同版本之间的冲突显现出来,并迫使人们形成决议。例如,System/360体系结构需要一种十进制数据类型,作为已经有着成千上万用户的IBM十进制机型的兼容过渡之用。我们正在研发中的体系结构里已经有了数种数据类型,包括32位定点补码整型以及可变长字符串类型。 十进制数据类型定义成与两者中的任何一个相似都是可行的。那么,哪个更符合System/360的设计理念呢?两方面都拿出了强有力的论据,而不同的侧重点则依赖于个人对于设计理念的不同见解。有些架构师主张的设计理念受早年的科学计算机的影响,而另一些架构师主张的设计理念则受早年的商用计算机的影响。而System/360的设计目标明确地规定,对于这两种计算机上运行的应用程序都要提供良好支持。 我们选择了把十进制数据类型建立在字符串类型的基础之上,因为对于十进制数据类型这个特殊的用户群,即IBM 1401的用户来说,这是他们中的大多数人最熟悉的数据类型。如果再给我一次机会,我仍然会做出这样的决定。
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一1.3 何为实在?
时间: 2024-09-25 08:18:59
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一1.3 何为实在?的相关文章
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一
前 言 我写这本书的目的,意在督促设计师和设计项目经理们去努力思考设计活动的过程(process),特别是复杂系统的设计过程.本书是站在工程师的角度来思考的,不仅注重实用(utility)与效益(effectiveness),也兼顾效率(efficiency)和优雅(elegance).1 谁应该读这本书 <人月神话>一书的目标读者是"职业程序员.职业经理人,尤其是管理程序员的职业经理人".在该书中,我讨论了团队在开发软件时,获得概念完整性(conceptual integ
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一2.4 注释和参考文献
2.4 注释和参考文献 1. 按照Simon(1981)<The Sciences of the Artificial>的习惯,在整本书中我采用"man"作为一个一般性的名词加以使用,两种性别都包括在其指代的对象中,同样"he"(他)."him"(他的―形容词用法)和"his"(他的―名词用法)也一律作为兼具两性的代词.我觉得继续使用符合传统的,把女性和男性平等地置于这些一般性的代词指代之中的做法十分亲切,这好过生
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一3.10 注释和参考文献
3.10 注释和参考文献 1. 工程师需要的是最低限度满足解,而科学家需要的是发现,这往往可以通过在更大范围里探索而求得. 2. Blaauw和Brooks(1997),<Computer Architecture>,26-27,79-80. 3. Parnas(1979),"为简化可伸缩性软件而进行的软件设计",明确地将设计过程作为树型结构的遍历来处理.他强烈主张使设计尽可能地灵活.他敦促人们设计的灵活性是重要的目标之一.在软件工程领域,面向对象的设计也好,敏捷开发方法论
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一1.4 对设计过程的思考
1.4 对设计过程的思考 有关设计的思考源远流长,至少可以追溯到Vitruvius(逝于公元前15年).他的著作<De Architectura>是古典时期以来有关设计的重要文献.主要的里程碑包括达·芬奇(1452-1529)的<Notebooks>,以及Andrea Palladio(1508-1580)的<Four Books of Architecture>. 而有关设计过程本身的思考则很晚才出现.根据Pahl和Beitzr的考证,最远可以追溯到1852年,这是随
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一2.2 该模型的构思从何而来
2.2 该模型的构思从何而来 将设计过程建模为一种系统化的.按部就班的过程的观念,似乎肇端于德国机械工程社团.Pahl和Beitz在他们7次修改其稿的伟大论著中阐述了目前被最广泛地接受的观点.4 他们对达・芬奇(1452-1519)的<Notebooks>中关于设计备选方案的系统化搜索过程进行实践并分析,而并非只泛泛阅读那显式写出的陈述. Herbert Simon在其著作<The Sciences of the Artificial>(1969,1981,1996)中独立地提出设
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一1.6 注释和参考文献
1.6 注释和参考文献 Sayers(1941),<The Mind of the Maker>. 2. Brooks (1986),<No silver bullet>. 3. McDonnell (2008),<About Designing>.该书是第7届设计思想研讨会(Design Thinking Research Symposium,DTRS7)的论文汇编. 4. Luck (2009),"Does this compromise your des
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一3.4 效用函数无法以增量方式求值
3.4 效用函数无法以增量方式求值 理性模型的假定是,设计是对于设计树的搜索,并且在每个节点人们可以对若干下一级分支的效用函数求值. 事实上,除非探索到所有分支的所有叶节点的程度,否则人们就很难做到这一点,因为大量的效用指标(如性能.成本等)严重依赖于随后的设计细节.因此,虽然对效用函数的求值在原则上是可行的,但是在实践上,人们会在这里再次遭遇组合爆炸. 那么,设计师该怎么做?估算!理所当然,正式的也好,非正式的也罢,都要做估算.在求精的步骤中,人们必须对设计树进行剪枝. 经验.很多辅助信息都有
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一3.6 约束在持续变化
3.6 约束在持续变化 即使设计目标固定而且已知,所有的必要条件皆已枚举清楚,设计树已经刻画精确,并且有用性函数也有着明确无误的定义,设计过程仍然会是迭代的,因为约束在持续变化. 通常情况下是环境发生改变-市政厅会通过令人沮丧的规定给设计投下新的阴霾:电气规范每年都会更新:本来计划要用的芯片被供应商召回,等等.一切都在不断变化,即使在我们的设计向前推进的过程中,周围世界的改变也从未停步. 约束也会因设计过程中甚至加工过程中的新发现而发生变化-建筑工人碰到了无法凿穿的岩层,分析结果表明芯片的冷却问
《设计原本—计算机科学巨匠Frederick P. Brooks的反思》一一1.2 什么是设计
1.2 什么是设计 <牛津英文词典>对设计这个动词的定义如下: 形成计划或方案,在头脑中整理或构思--以备后续执行. 这一定义的要点在于计划.在头脑中和后续执行.所以,设计(作为一个名词)属于受造的事物(created object),它先于被设计之物而存在且与后者相关,但又截然不同.英国作家.编剧Dorothy Sayers在她那本发人深省的著作<The Mind of the Maker>里,将创作过程细分为三个不同的阶段,并分别称之为构想(idea).运能(energy)或称