1.2 软件危机与工程化转折

1.2 软件危机与工程化转折

上一节给了软件工程的定义与原则，本节回答"这些原则从哪来"。我们把镜头拨回计算机还住机房里的年代，看几个教科书级的事故现场——软件危机不是形容词，而是一段有账目的历史。理解它，你才能真正理解流程、评审、度量这些"繁琐规矩"为什么长成今天这个样子。

从失控的现场说起

上世纪六十年代，硬件按摩尔定律狂奔，软件却还在手工作坊阶段。几个后来被反复引用的项目，勾勒出危机的轮廓：

• IBM OS/360：为 IBM 大型机开发操作系统，动用了约五千人年的工作量，发布后缺陷不断，版本接连修补。主持该项目的 Fred Brooks 后来写出《人月神话》，留下那句著名的观察：向延期项目加人，只会让它延得更久——沟通成本随人数超线性增长。
• 美国国税局退税系统：六十年代末多次重构仍无法按期交付，程序员流失导致代码无人能读懂，最终不得不推倒重来。
• 多次导弹与航天事故：代码里一处标点或单位换算错误即可造成发射失败，事后调查普遍指向同一个结论——软件的开发与验证过程，没有与风险等级匹配的纪律。

把这些现场放在一起，危机的症状可以归纳成四类：

为什么规模一大就必然失灵

危机的根源不是程序员不聪明，而是复杂度随规模超线性增长。人脑能稳定维护的细节有限：一个人写千行代码，逻辑全在脑子里；十个人写十万行，任何两个人的脑子都对不上同一个版本。此时若没有书面契约（设计文档、接口定义、变更记录），协作就变成互相猜测。

三个放大器让情况雪上加霜：

• 不可见性：软件没有实体进度可看，盖楼能看到几层，软件只能看到"还在改"；
• 可变性：客户看到成品才想明白要什么，需求天然漂移；
• 退化性：修缺陷、加功能都在改动旧结构，系统像反复焊接的老桥，越修越脆。

1968 年，北大西洋公约组织在联邦德国加米施召开了一场后来很著名的会议，正式把 software engineering 这个词推向世界。会议的立场很明确：软件开发应该借鉴已有几百年积累的工程学科——先设计后施工、分阶段验收、故障归因、经验沉淀为规范。这就是"工程化转折"：承认软件生产是工程而非个人创作，用过程纪律对抗规模复杂度。

转折带来了什么

工程化转折之后，一批延续至今的实践陆续成形：

• 结构化程序设计：用顺序、分支、循环三种结构取代随意跳转，让代码可读可证；
• 模块化与信息隐藏：系统拆成黑盒模块，接口稳定、实现可换，复杂度被关进盒子；
• 生命周期分阶段：需求、设计、实现、测试、维护各自有产物与进出条件（本章 1.1 的阶段图即源于此）；
• 项目管理与质量保证独立成岗：进度与质量有人专门盯着，不再依赖开发者自觉。

  手工作坊时代                工程化时代
  ┌──────────────┐            ┌──────────────────────────┐
  │ 牛人 + 代码即一切 │   ──►   │ 过程 + 文档 + 评审 + 度量    │
  │ 成败系于个人      │            │ 成败取决于过程与协作          │
  └──────────────┘            └──────────────────────────┘
​

需要注意的是，工程化并不等于重文档。危机教会行业的不是"多写文档"，而是关键信息必须落在人脑之外、可被他人验证的载体上。今天敏捷方法喊着"可工作的软件高于详尽的文档"，反对的从来不是记录，而是没有信息量的仪式——这条线索会在第 2 章反复出现。

案例复盘：云梯平台的前身怎么翻的车

用本册的贯穿案例收个尾。云梯货运调度结算平台的前身是 2016 年由两名骨干用脚本拼出来的结算工具，撑起日常运营没问题；当公司扩张到十几个仓库、结算规则膨胀到上百条时，它开始以每月数起的频率算错运费。复盘给出的诊断与半个世纪前的危机症状一一对应：没有需求记录（规则全在某人的脑子里）、没有测试（改完规则靠人工抽查）、没有版本管理（出问题找不到是哪次改动引入）。后来重建平台，第一步做的不是写代码，而是把结算规则整理成带编号的需求清单、搭起测试环境——这正是本节所有历史教训的直接应用。

一个最著名的现场：一小节代码放倒一枚火箭

危机的历史里有一场教科书级的翻车：上世纪九十年代中期，某型新型火箭首飞，升空约四十秒后自毁。事后调查的结论让人沉默——惯性导航代码在把一个六十四位浮点数转成十六位整数时发生溢出，而这处代码是从上一代火箭原样复用的。上一代火箭里这个数值永远不会超限，新火箭的推力更大，数值越过了旧边界。结论报告里那句著名评价值得抄在工位上：这不是随机的硬件故障，而是一个可以在纸面上复现的、彻头彻尾的系统性缺陷——它本该在评审里被拦住。

这个现场把危机的机理展示得干干净净：复用旧代码本身没错（工程鼓励复用），错在复用时没有重做边界分析，而"复用必须附带重新验证"正是工程化转折之后才沉淀成规章的一条。过程纪律的价值，在这一小节代码面前不需要任何雄辩。

危机过去了吗

常有人问：工具这么先进、语言这么安全，危机应该早就结束了吧？观察一下身边就能得到答案：延期与超支仍是行业家常便饭，"重构一半搁置"的项目遍地都是，线上事故复盘里反复出现"没人了解这段历史代码"。变的是症状的包装——当年的危机表现为"程序写不出来"，今天更多表现为"系统改不动、债务还不起"；不变的是底层机理：复杂度增长的速度持续快过个人技艺增长的速度。过程、评审、度量这些本册要讲的东西，就是行业对这条机理的长期应答。理解了这一点，后面每一章的"繁琐"都有了出处。

本节要点回顾

• 软件危机的四大症状：成本、进度、质量、维护全面失控，且随规模超线性恶化。
• 根源是复杂度超线性增长叠加不可见性、可变性、退化性，个人技艺无法对冲。
• 1968 年工程化转折：软件工程作为学科被正式提出，主张用工程纪律对抗复杂度。
• 结构化、模块化、生命周期分阶段、管理与质量独立成岗，是转折期的四大遗产。
• 工程化的本质是关键信息落在人脑之外，不是堆文档。
• 没有需求记录、没有测试、没有版本管理，是从小工具演变成大事故的常见三连。

看清了失灵的机理，下一节我们把执行这些规程的人请上车——一趟版本列车上到底有哪些岗位，各守哪道闸。