第二个系统效应

什么是第二个系统效应？

• 现象: 设计第二个系统时, 倾向把第一个系统中"小心谨慎地推迟"的修饰功能和想法全部加上;
• 结果: 得到 Ovid 所说的"大馅饼"--功能丰富充沛, 但其中一半从不被常规使用;
• 区别于单纯功能膨胀: 还存在对某些技术细化、精炼的趋势, 而那些技术可能因基本设想变化已经落伍;

为什么第二个系统最危险？

• 第一个系统: 结构师知道自己不够了解, 会精炼、简洁、谨慎地工作, 把装饰性功能推迟到"下一个"项目;
• 第二个系统: 结构师已有十足信心, 熟练掌握了这类系统的知识, 于是把积压的想法一次释放;
• 第三个、第四个系统: 先前经验相互验证, 能识别出通用特性和不够通用的部分, 风险反而下降;
• 根因: 责任分离--制订功能规格说明的责任与"开发快速、成本低廉产品"的责任分离时, 结构师的创造热情失去约束;

有哪些典型例子？

例子	加了什么	为什么错
IBM 709	操作集合极其丰富	只有一半操作被常规使用
Stretch 计算机	架构、设计实现、物理实现都过度设计	被评价为"产品线的终结", 粗糙、浪费、不优雅
OS/360 链接编辑器	支持静态覆盖, 覆盖服务做得极好	系统基本运行方式已是多道程序和动态内核分配, 与静态覆盖直接冲突; 且它自身太大太慢
OS/360 TESTRAN	优雅的快照和内存转储, 无需重编译的选择性跟踪	交互式解释器、增量编译和快速编译已使批调试概念落伍
OS/360 调度程序	固定批作业管理做得杰出	对远程任务项、多道程序、永久驻留交互式子系统几乎无帮助, 甚至使其更难

• 边界: OS/360 是"典型的画蛇添足的例子"; 20 年后作者补注, Windows NT 似乎是 90 年代的例子;
• 特例: 只有控制程序如此--OS/360 中一些编译器团队正构建第三、第四个系统, 卓越的产品证明了这一点;

结构师如何影响实现而不越权？

• 前提: 面对成本估算过高, 结构师可以选择削减设计, 或建议成本更低的实现方法;
• 挑战实现方式时的四条准则:
  • 牢记开发人员承担创造性的实现责任, 结构师只能建议, 不能支配;
  • 时刻准备为所指定的说明建议一种实现方法, 同样准备接受其他能达到目标的方法;
  • 对建议保持低调和平静;
  • 准备放弃坚持所作的改进建议;
• 双向: 也应听取开发人员在体系结构上的改进建议;

如何避免第二个系统效应？

• 结构师自身: 有意识地关注第二个系统的特殊危险, 运用自我约束准则避免功能修饰;
• 舍弃而非添加: 根据系统基本理念和目的的变更, 主动舍弃一些功能;
• 量化约束: 为每个小功能分配值--每次改进, 功能 x 不超过 m 字节内存和 n 微秒;
• 值的用途: 一开始作为决策向导, 物理实现期间充当指南和对所有人的警示;
• 项目经理: 坚持由至少有两个以上系统开发经验的结构师做决定, 并不断提出正确的问题, 确保概念和目标在详细设计中得到完整体现;