应用软件百科

广告

《人月神话》之四

2011-08-15 16:43:46 本文行家:成功9134

画蛇添足(TheSecond-SystemEffect) 聚沙成塔,集腋成裘。 -奥维德 Addeparvumparvomagnusacervuserit. [Addlittletolittleandtherewillb

画蛇添足(The Second-System Effect)
聚沙成塔,集腋成裘。
- 奥维德
Adde parvum parvo magnus acervus erit.
[Add little to little and there will be a big pile.]
- OVID
如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来,那么有什么样的准则和机制来约束结构师的创造性热情呢?
基本回答是结构师和建筑人员之间彻底、仔细和谐的交流。另外,还有很多值得关注的、更细致的答案。
结构师的交互准则和机制
建筑行业的结构设计师使用估算技术来编制预算,该估算技术会由后续的承包商报价来验证和修正。承包商的报价总会超过预算。接下来,设计师会重新改进他的预算或修订设计,调整到下一期工程。他也可能会向承包商建议,使用更加便宜的方法来实现设计。
类似的过程也支配着计算机系统和计算机编程系统的结构师。相比之下,他有能在设计早期从承包商处得到报价的优势,几乎是只要他询问,就能得到答案。他的不利之处常常是只有一个承包商,后者可以增高或降低前者的估计,来反映对设计的好恶。实际情况中,尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
面对估算过高的难题,结构师有两个选择:削减设计或者建议成本更低的实现方法——挑战估算的结果。后者是固有的主观感性反应。此时,结构师是在向开发人员的做事方式
- 29 -
提出挑战。想要成功,结构师必须
.. 牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配;
.. 时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法;
.. 对上述的建议保持低调和平静;
.. 准备放弃坚持所作的改进建议;
一般开发人员会反对体系结构上的修改建议。通常他是对的——当正在实现产品时,某些特性的修改会造成意料不到的成本开销。
自律——开发第二个系统所带来的后果
在开发第一个系统时,结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解,所以他会谨慎仔细地工作。
在设计第一个项目时,他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边,作为“下一个”项目的内容。第一个项目迟早会结束,而此时的结构师,对这类系统充满了十足的信心,熟练掌握了相应的知识,并且时刻准备开发第二个系统。
第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时,先前的经验会相互验证,得到此类系统通用特性的判断,而且系统之间的差异会帮助他识别出经验中不够通用的部分。
一种普遍倾向是过分地设计第二个系统,向系统添加很多修饰功能和想法,它们曾在第一个系统中被小心谨慎地推迟了。结果如同Ovid所述,是一个“大馅饼”。例如,后来被嵌入到7090的IBM 709系统,709是对非常成功和简洁的704系统进行升级的二次开发项目。709的操作集合被设计得如此丰富和充沛,以至于只有一半操作被常规使用。
让我们来看看更严重的例子——Stretch计算机的结构(architecture)、设计实现(implementation)、甚至物理实现(realization),它是很多人被压抑创造力的宣泄出口。如果Strachey在评审时所述:
- 30 -
对于Stretch系统,我的印象是从某种角度而言,它是一个产品线的终结。如同早期的计算机程序一样,它极富有创造性,极端复杂,非常高效。但不知为什么,同时也感觉到粗糙、浪费、不优雅,以及让人觉得必定存在某种更好的方法1。
操作系统360对于大多数设计者来说,是第二个系统。它的设计小组成员来自1410-7010磁盘操作系统、Stretch操作系统、Mercury实时系统项目和7090的IBSYS。几乎没有人有两个以上早期操作系统的经验2。因此,OS/360是典型的第二次开发(second-system effect)的例子,是软件行业的Stretch系统。Strachey的赞誉和批评可以毫无更改地应用在其中。
例如,OS/360开发了26字节的常驻日期翻转例程来正确地处理闰年的12月31日的问题,其实它完全可以留给操作员来完成。
开发第二个系统所引起的后果(second-system effect)与纯粹的功能修饰和增强明显不同,也就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化,这些技术已经显得落后。OS/360中有很多这样的例子。
例如,链接编辑器的设计,它用来对分别编译后的程序进行装载,解决它们之间的交叉引用。除了这些基本的功能,它还支持程序的覆盖(overlay)。这是所有实现的覆盖服务程序中最好的一种。它允许链接时在外部完成覆盖结构,而无需在源代码中进行设计。它还允许在运行时刻改变覆盖,而不必重新编译。它配备了丰富的实用选项和各种功能。某种意义上,它是若干年静态覆盖技术开发的顶峰。
然而,它同时也是最后和最优秀的恐龙,因为它属于一个基本运行方式为多道程序,以动态内核分配为基础的系统,这直接与静态覆盖的概念相冲突。如果我们把投入在覆盖管理上的工作量,用在提高动态内核分配和动态交叉引用的性能上,那么系统将会运行得多么好啊!
另外,链接编辑器需要如此大的空间,而且它本身就包含了很多链接库,以至于即使在不使用覆盖管理功能,仅仅使用链接功能的时候,它也比绝大多数系统的编译程序还要慢。具有讽刺意味的是,链接程序的目的是为了避免重新编译。这种情况就像一个挺着大肚子的节食者一样,直到系统的思想已经十分优越时,才开始对原有技术进行细化和精炼。
TESTRAN调试程序是这个趋势的另一个例子。它在批调试程序中是出类拔萃的,配备了真正优雅的快照和内存信息转储功能。它使用了控制段的概念和卓越的生成技术,从而不需
- 31 -
要重新编译或解释,就能实现选择性跟踪和快照。这种709共享操作系统3中魔术般的概念得到了广泛的使用。
但同时,整个无需重编译的批调试概念变得落伍了。使用语言解释器和增量编译器的交互式计算系统,向它提出了最根本的挑战。即使是在批处理系统中,快速编译/慢速执行编译器的出现,也使源代码级别调试和快照技术成为优先选择的技术。如果在构建和优化交互式和快速编译程序之前,就已经着手TESTRAN的开发,那么系统将是多么的优秀啊!
还有另外一个例子是调度程序。OS/360的调度程序是非常杰出的,它提供了管理固定批作业的杰出功能。从真正意义上讲,该调度程序是作为1410-7010磁盘操作系统后续的二次系统,经过了精炼、改进和增强。它是除了输入-输出以外的非多道程序批处理系统,是一种主要用于商业应用的系统。但是,它对OS/360的远程任务项、多道程序、永久驻留交互式子系统,几乎完全没有影响和帮助。实际上,OS/360调度程序的设计使它们变得更加困难。
结构师如何避免画蛇添足——开发第二个系统所引起的后果(second-system effect)?是的,他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险,运用特别的自我约束准则,来避免那些功能上的修饰;根据系统基本理念及目的变更,舍弃一些功能。
一个可以开阔结构师眼界的准则是为每个小功能分配一个值:每次改进,功能x不超过m字节的内存和n微秒。这些值会在一开始作为决策的向导,在物理实现期间充当指南和对所有人的警示。
项目经理如何避免画蛇添足(second-system effect)?他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时,保持对特殊诱惑的警觉,他可以不断提出正确的问题,确保原则上的概念和目标在详细设计中得到完整的体现。
- 32 -
贯彻执行(Passing the Word)
他只是坐在那里,嘴里说:“做这个!做那个!”当然,什么都不会发生,光说不做是没有用的。
- 哈里•杜鲁门,关于总统的权力1
He'll sit here and he'll say, "Do this! Do that!" And nothing will happen.
- HARRY S. TRUMAN, ON PRESIDENTIAL POWER1
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员,那么他如何确保每个人听从、理解并实现结构师的决策?对于一个由1000人开发的系统,一个10个结构师的小组如何保持系统概念上的完整性?在System/360硬件设计工作中,我们摸索出来一套实现上述目标的方法,它们对于软件项目同样适用。
文档化的规格说明——手册
手册、或者书面规格说明,是一个非常必要的工具,尽管光有文档是不够的。手册是产品的外部规格说明,它描述和规定了用户所见的每一个细节;同样的,它也是结构师主要的工作产物。
随着用户和实现人员反馈的增加,规格说明中难以使用和难以构建实现的地方不断被指出,规格说明也不断地被重复准备和修改。然而对实现人员而言,修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。
手册不但要描述包括所有界面在内的用户可见的一切,它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴,而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法,但是他不应该试图支配具体的实现过程。
- 33 -
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。
System/360 Principles of Operation的一致完整性来自仅有两名作者的事实:Gerry Blaauw和Andris Padegs。思路是大约十个人的想法,但如果想保持文字和产品之间的一致性,则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。而且,将定义书写成文字,必须对很多原先并不是非常重要的问题进行判断,并得出结论。例如,System/360需要决定在每次操作后,如何设置返回的条件码。其实,对于在整个设计中,保证这些看似琐碎的问题处理原则上的一致性,决不是一件无关紧要的事情。
我想我所见过的最好的一份手册是System360 Principles of Operation的附录。它精确仔细地规定了System/360兼容性的限制。它定义了兼容性,描述了将达到的目标,列举了很多外部显示的各个部分:源于某个模型与其他模型差异,带来变化的部分和保持不变的部分;或者是某个给定模型的拷贝不同于其他拷贝的地方;甚至是工程上的变更引起拷贝自身上的差异。而这正是一个规格说明作者所应该追求的精确程度,他必须在仔细定义规定什么的同时,定义未规定什么。
形式化定义
英语或者其他任何的人类语言,从根本上说,都不是一种能精确表达上述定义的手段。因此,手册的作者必须注意自己的思路和语言,达到所需要的精确程度。一种颇具吸引力的作法是对上述定义使用形式化标记方法。毕竟,精确度是我们需要的东西,这也正是形式化标记方法存在的理由和原因。
让我们来看一看形式化定义的优点和缺点。如文中所示,形式化定义是精确的,它们倾向于更加完整;差异得更加明显,可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则,描述阶段上或层次上的结构,以及提供例子。它可以很容易地表达异常和强调对比的关系,最重要的是,它可以解释原因。在表达的精确和简明性上,目前所提出的形式化定义,具有了令人惊异的效果,增强了我们进行准确表达的信心。但是,它还需要记叙性文字的辅助,才能使内容易于领会和讲授。出于这些原因,我想将来的规格说明同时包括形式化和记叙性定义两种方式。
- 34 -
一句古老的格言警告说:“决不要携带两个时钟出海,带一个或三个。”同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式,则必须以一种作为标准,另一种作为辅助描述,并照此明确地进行划分。它们都可以作为表达的标准,例如,Algol 68采用形式化定义作为标准,记叙性文字作为辅助。PL/I使用记叙性定义作为主要方式,形式化定义用作辅助表述。System/360也将记叙性文字用作标准,以及形式化定义用作派生的论述。
很多工具可以用于形式化定义,例如巴科斯范式在语言定义中很常用,它在书本中有详细的描述2。PL/I的形式化定义使用了抽象语法的新概念,该概念有很确切的解释3。Iverson的APL曾用来描述机器,突出的应用是IBM 70904和System/3605。
Bell和Newell建议了能同时描述配置和机器结构的新标注方法,并且在许多机型的应用上得以体现,如DEC PDP-86、70908、System/360。
在规定系统外部功能的同时,几乎所有的形式化定义均会用来描述和表达硬件系统或软件系统的某个设计实现。语法和规则的表达可以不需要具体的设计实现,但是特定的语义和意义通常会通过一段实现该功能的程序来定义。理所当然,这是一种实现,不过它过多地限定了体系结构。所以必须特别指出形式化定义仅仅用于外部功能,说明它们是什么。
如同前面所示,形式化定义可以是一种设计实现。反之,设计实现也可以作为一种形式化定义的方法。当制造第一批兼容性的计算机时,我们使用的正是上述技术:新的机器同原有的机器一致。如果手册有一些模糊的地方?“问一问机器!”——设计一段程序来得到其行为,新机器必须按照上述结果运行。
硬件或软件系统的仿真装置,可以按照相同的方式完整运用。它是一种实现,可以运行。因此,所有定义的问题可以通过测试来解决。
使用实现来作为一种定义的方式有一些优点。首先,所有问题可以通过试验清晰地得到答案,从来不需要争辩和商讨,回答是快捷迅速的。通过定义得出的答案,总是同所要求的一样精确和正确。但是,相对于这些优点的,是一系列可怕的缺点。实现可能更加过度地规定了外部功能。例如,无效的语法通常会产生某些结果。在拥有错误控制的系统中,它通常仅仅导致某种“无效”的指示,而不会产生其他的东西。在无错误控制的系统中,会产生各种副作用,它们可能被程序员所使用。例如,当我们着手在System/360上模拟IBM 1401时,有30个不同的“古玩”——被认为是无效操作的副作用——得到广泛的应用,并被认为是定义的一部分。作为一种定义,实现体现了过多的内容:它不但描述了系统必须做什么,
- 35 -
同时还声明了自己到底做了些什么。
因此,当尖锐的问题被提及时,实现有时会给出未在计划中的意外答案;这些答案中,真正的定义常常是粗糙的,因为它们从来没有被仔细考虑过。这些粗糙的功能在其他的设计实现中,往往是低效或者代价高昂的。例如,一些机器在乘法运算之后,将某些运算的垃圾遗留在被乘数寄存器中。该功能确切的特性,即保存运算垃圾,成为了真正定义的一部分。然而,重复该细节可能会阻止某些快速乘法算法的使用。
最后,关于实际使用标准是形式化描述还是叙述性文字这一点而言,使用实现作为形式化定义特别容易引起混淆,特别是在程序化的仿真中。另外,当实现充当标准时,还必须防止对实现的任何修改。
直接整合
对软件系统的体系结构师而言,存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法,而非语义时,它特别有用。这项技术是设计被传递参数和共享存储器的声明,并要求编程实现在编译时的一些操作(PL/I的宏或%INCLUDE)来包含这些声明。另外,如果整个接口仅仅通过符号名称进行引用,那么需要修改声明的时候,可以通过增加或插入新变量,或者重新编译受影响的程序。这种方法不需要修改程序内容。
会议和大会
无需多说,会议是必要的。然而,数百人在场的大型磋商会议往往需要大规模和非常正式地召集。因此,我们把会议分成两个级别:周例会和年度大会——这实际上是一种非常有效的方式。
周例会是每周半天的会议,由所有的结构师,加上硬件和软件实现人员代表和市场计划人员参与,由首席系统结构师主持。
会议中,任何人可以提出问题和修改意见,但是建议书通常是以书面形式,在会议之前分发。新问题通常会被讨论一些时间。重点是创新,而不仅仅是结论。该小组试图发现解决问题的新方法,然后少数解决方案会被传递给一个和几个结构师,详细地记录到书面的变更建议说明书中。
- 36 -
接着会对详细的变更建议做出决策。这会经历几个反复过程,实现人员和用户会仔细地进行考虑,正面和负面的意见都会被很好地描述。如果达成了共识,非常好;如果没有,则由首席结构师来决定。这需要花费时间,最终所发布的结论是正式和果断的。
周例会的决策会给出迅捷的结论,允许工作继续进行。如果任何人对结果过于不高兴,可以立刻诉诸于项目经理,但是这种情况非常少见。
这种会议的卓有成效是由于:
1. 数月内,相同小组——结构师、用户和实现人员——每周交流一次。因此,大家对项目相关的内容比较了解,不需要安排额外时间对人员进行培训。
2. 上述小组十分睿智和敏锐,深刻理解所面对的问题,并且与产品密切相关。没有人是“顾问”的角色,每个人都要承担义务。
3. 当问题出现时,在界线的内部和外部同时寻求解决方案。
4. 正式的书面建议集中了注意力,强制了决策的制订,避免了会议草稿纪要方式的不一致。
5. 清晰地授予首席结构师决策的权力,避免了妥协和拖延。
随着时间的推移,一些决定没有很好地贯彻,一些小事情并没有被某个参与者真正地接受,其他决定造成了未曾遇到的问题。对于这些问题,有时周例会没有重新考虑,慢慢地,很多小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题,我们会举行年度大会,典型的年度大会会持续两周。(如果由我重新安排,我会每六个月举行一次。)
这些会议在手册冻结的前夕召开。出席人员不仅仅包括体系结构小组和编程人员、实现人员的结构代表,同时包括编程经理、市场和实现人员,由System/360的项目经理主持。议程典型地包括大约200个条目,大多数条目的规模很小,它们列举在会议室周围的图表上,每个不同的声音都有机会得到表达。然后,会制订出决策,加上出色的计算机化文本编辑工作(许多优秀员工的卓越的工作成果)。每天早晨,会议参与人员会在座位上发现更新了的手册说明,记录了前一天的各项决定。
这些“收获的节日”不仅可以解决决策上的问题,而且使决策更容易被接受。每个人都在倾听,每个人都在参与,每个人对复杂约束和决策之间的相互关系有了更透彻的理解。
多重实现
System/360的结构师具有两个空前有利的条件:充足的工作时间,拥有与实现人员相同的策略影响力。充足时间来自新技术的开发日程;而多重实现的同时开发带来了策略上的平等性。不同实现之间严格要求相互兼容,这种必要性是强制规格说明的最佳代言人。
在大多数计算机项目中,机器和手册之间往往会在某一天出现不一致,人们通常会忽略手册。因为与机器相比,手册更容易改动,并且成本更低。然而,当存在多重实现时,情况就不是这样。这时,如实地遵从手册更新机器所造成的延迟和成本的消耗,比根据机器调整手册要低。
在定义某编程语言的时候,上述概念可以卓有成效地得到应用。可以肯定的是,迟早会有很多编译器或解释器被推出,以满足各种各样的目标。如果起初至少有两种以上的实现,那么定义会更加整洁和规范。
电话日志
随着实现的推进,无论规格说明已经多么精确,还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释,还有一些仅仅是因为理解不当。
显然,对于存有疑问的实现人员,应鼓励他们打电话询问相应的结构师,而不是一边自行猜测一边工作,这是一项很基本的措施。他们还需要认识到的是,上述问题的答案必须是可以告知每个人的权威性结论。
一种有用的机制是由结构师保存电话日志。日志中,他记录了每一个问题和相应的回答。每周,对若干结构师的日志进行合并,重新整理,并发布给用户和实现人员。这种机制很不正式,但非常快捷和易于理解。
参考资料:
[1] 《人月神话》
百科的文章(含所附图片)系由网友上传,如果涉嫌侵权,请与客服联系,我们将按照法律之相关规定及时进行处理。如需转载,请注明来源于www.baike.com