画蛇添足（The Second-System Effect）

 画蛇添足（The Second-System Effect）

聚沙成塔，集腋成裘。

- 奥维德

Adde parvum parvo magnus acervus erit.

[Add little to little and there will be a big pile.]

- OVID

如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束结构师的创造性热情呢？

基本回答是结构师和建筑人员之间彻底、仔细和谐的交流。另外，还有很多值得关注的、更细致的答案。

Interactive Discipline for the Architect

结构师的交互准则和机制

建筑行业的结构设计师使用估算技术来编制预算，该估算技术会由后续的承包商报价来验证和修正。承包商的报价总会超过预算。接下来，设计师会重新改进他的预算或修订设计，调整到下一期工程。他也可能会向承包商建议，使用更加便宜的方法来实现设计。

类似的过程也支配着计算机系统和计算机编程系统的结构师。

相比之下，结构师有能在设计早期从承包商处得到报价的优势，几乎是只要他询问，就能得到答案。他的不利之处常常是只有一个承包商，承包商可以增高或降低结构师的估计（estimates，预算，投资），来反映对设计的好恶。实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

面对估算过高的难题，结构师有两个选择：削减设计，或者建议成本更低的实现方法以挑战预算（cut the design or challenge the estimate by suggesting cheaper implementations.）。后者是固有的主观感性反应。此时，结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须

• 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；

• 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；

• 对上述的建议保持低调和平静；

• 准备放弃坚持所作的改进建议；

一般开发人员会反对体系结构上的修改建议。通常他是对的--当正在实现产品时，某些特性的修改会造成意料不到的成本开销。

Self-Discipline—The Second-System Effect

自律--开发第二个系统所带来的后果

2024年3月17日20:34:55：这里是想说，有一个架构师（结构师），他刚刚开发完他人生中的第一个操作系统，现在他要去开发第二个操作系统了。

在他开发第一个系统的时候，由于他自觉水平和能力都不够，所以他会小心谨慎地工作。

第一个系统如愿以偿获得了成功。

而现在他要开发第二个系统了，这一次，他不再谨慎，第一次的成功给了他过度的自信。

他要放飞自我了。

而现在一整个团队都是这样的架构师。

在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。

在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为"下一个"项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。

第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。

一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。结果如同Ovid所述，是一个"大馅饼"。例如，后来被嵌入到7090的IBM 709系统，709是对非常成功和简洁的704系统进行升级的二次开发项目。709的操作集合被设计得如此丰富和充沛，以至于只有一半操作被常规使用。

让我们来看看更严重的例子--Stretch计算机的结构（architecture）、设计实现（implementation）、甚至物理实现（realization），它是很多人被压抑创造力的宣泄出口。如果Strachey在评审时所述：

对于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中有很多这样的例子。

2024年3月17日20:39:04：这里说的second-system effect指的是，若一个架构师团队中的大多数架构师在参与当前的系统开发任务之前，都只有唯一一次系统开发经历，那这个团队会遇到麻烦。

怎么办呢？

答案是找开发过至少2个系统的架构师寻求建议。他们是老油条了。

例如，链接编辑器的设计，它用来对分别编译后的程序进行装载，解决它们之间的交叉引用。除了这些基本的功能，它还支持程序的覆盖（overlay）。这是所有实现的覆盖服务程序中最好的一种。它允许链接时在外部完成覆盖结构，而无需在源代码中进行设计。它还允许在运行时刻改变覆盖，而不必重新编译。它配备了丰富的实用选项和各种功能。某种意义上，它是若干年静态覆盖技术开发的顶峰。

然而，它同时也是最后和最优秀的恐龙，因为它属于一个基本运行方式为多道程序，以动态内核分配为基础的系统，这直接与静态覆盖的概念相冲突。如果我们把投入在覆盖管理上的工作量，用在提高动态内核分配和动态交叉引用的性能上，那么系统将会运行得多么好啊！

另外，链接编辑器需要如此大的空间，而且它本身就包含了很多链接库，以至于即使在不使用覆盖管理功能，仅仅使用链接功能的时候，它也比绝大多数系统的编译程序还要慢。具有讽刺意味的是，链接程序的目的是为了避免重新编译。这种情况就像一个挺着大肚子的节食者一样，直到系统的思想已经十分优越时，才开始对原有技术进行细化和精炼。

TESTRAN调试程序是这个趋势的另一个例子。它在批调试程序中是出类拔萃的，配备了真正优雅的快照和内存信息转储功能。它使用了控制段的概念和卓越的生成技术，从而不需要重新编译或解释，就能实现选择性跟踪和快照。这种709共享操作系统3中魔术般的概念得到了广泛的使用。

但同时，整个无需重编译的批调试概念变得落伍了。使用语言解释器和增量编译器的交互式计算系统，向它提出了最根本的挑战。即使是在批处理系统中，快速编译/慢速执行编译器的出现，也使源代码级别调试和快照技术成为优先选择的技术。如果在构建和优化交互式和快速编译程序之前，就已经着手TESTRAN的开发，那么系统将是多么的优秀啊！

还有另外一个例子是调度程序。OS/360的调度程序是非常杰出的，它提供了管理固定批作业的杰出功能。从真正意义上讲，该调度程序是作为1410－7010磁盘操作系统后续的二次系统，经过了精炼、改进和增强。它是除了输入－输出以外的非多道程序批处理系统，是一种主要用于商业应用的系统。但是，它对OS/360的远程任务项、多道程序、永久驻留交互式子系统，几乎完全没有影响和帮助。实际上，OS/360调度程序的设计使它们变得更加困难。

结构师如何避免画蛇添足--开发第二个系统所引起的后果（second-system effect）？

是的，他无法跳过二次系统（2024年3月17日20:47:21：意思是，一个架构师没法绕过不开发第2个系统就去开发第3个系统，就像你没法不经过2楼就走到3楼）。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。

一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能x不超过m字节的内存和n微秒。这些值会在一开始作为决策的向导，在物理实现期间充当指南和对所有人的警示。

项目经理如何避免画蛇添足（second-system effect）？

他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

s