没有定律,只有原则 — 这本书的玩法说明
这一章讲三件事: 这本书里的 201 条「原则」是什么、不是什么; 为什么软件这一行到不了「有定律」的那一天;以及读这本书前必须带上的一句提醒—— 原则会过时,作者自己就亲手宣判过其中几条的死刑。 这一章是全书的「玩法说明」:后面十一章讲的每一条原则,都按本章定义的方式工作。
1. 先看现象:这一行的教训从来没有「生效」过一次就完
1995 年, 本书作者 Alan Davis 把 201 条软件工程原则编成了据他所知的第一本成册的原则集1。 26 年后的 2021 年,他在新版序言里列了一份账单——都是这 26 年里因为软件出的事故:
- 波音 737 MAX 的机动特性增强系统,一个单点故障导致两起空难,346 人死亡,调查结论是软件测试不彻底2;
- 一种叫勒索软件的恶意程序(把你的文件加密、付钱才给解密的那种)反复攻击全球软件系统,说明漏洞一直都在3;
- 阿丽亚娜 5 型运载火箭,一个没预料到的溢出错误(数值大到超出变量——程序里给数值起的名字——能装的范围,类似水杯装不下输入的水)让飞行控制员必须在发射后立即引爆火箭4;
- 火星气候轨道飞行器直接坠毁在火星上,原因是两个程序员对同一个变量(程序里给数值起的名字)的单位理解不同:一个以为是磅,另一个以为是牛顿5。
作者紧接着给了一张对照表,这是理解整本书的钥匙6:
| 桥梁倒塌时 | 软件失败时 | |
|---|---|---|
| 调查问什么 | 建筑方有没有违反建筑规范 | ——多数时候不问「违反了哪条原则」 |
| 工程师怎么回应 | 承认设计或施工有错 | 「编译器出错了」「我是按方法的 15 个步骤做的」「经理让我这么干的」7 |
软件这一行不是没有教训。教训有,而且写成了 201 条——只是没人把它当成「规范」来执行。 这一章就讲清楚:这些「原则」到底是什么东西,凭什么信它们,以及它们的保质期。
2. 顶层全景:原则住在哪一层
作者把这一行用到的所有东西分成四层8:
原则(为什么) 「质量必须第一」「需求里的错误越晚修越贵」
│ 指导
▼
技术(怎么做) 结构化分析、面向对象设计——按部就班的流程
│ 表达于
▼
语言(用什么写) 编程语言、画图符号——基本元素 + 规则 + 语义
│ 实现于
▼
工具(谁来代劳) 编译器、编辑器、版本控制——替你执行某些步骤的软件
图说:原则在最上层,管住下面三层。换语言、换工具、换技术,
原则照旧成立——这正是「原则」和「流行趋势」的分界线。
工具能替你干的活有四种:当顾问、检查错误、自动化(比如编译器把人写的代码翻译成机器能执行的)、辅助编辑9。 本书不教你任何具体技术、语言、工具——它只占最上面那 一层10。
3. 核心原理
3.1 为什么软件工程永远到不了「有定律」的那一天
其他工程学科的原则背后站着物理学、化学、数学。软件不行——软件的产物不是实物, 物理定律管不着一串代码11。
那能不能退一步,靠统计出规律?作者引了 Lehman 的论证,值得原样走一遍12:
物理学为什么可预测 → 物体不管有没有人看着,都按同一条定律走
软件为什么难预测 → 开发过程由人来管理和执行
人的判断、情绪、奇想,长期看不可预测
但 → 软件又确实展现出许多稳定的规律性特征
所以 → 原则列得出来,也确实有用,
只是永远别指望它有物理定律那种精度
这一段是全书的「地基声明」:后面 200 条原则,没有一条是定律,全部是高置信度的经验。 作者甚至明说:理解和实践所有原则也不能预防所有灾难,只能大大降低你出事的概率(某件坏事发生的可能性)13。
3.2 原则会过时——而且作者亲手宣判过几条
1964 年的软件工程原则,今天看很傻:比如「永远用短变量名」「尽量让程序体积小」14。 作者说,三十年后,今天的原则回头看也会一样傻15。
有意思的是中文版译者补的一句:英文原书出版 25 年后重看,超过 95% 的原则都没有过时16。 但作者自己在 2021 年的序言里,逐章点名了几条他已经不再信的。这份「自我处决清单」比任何书评都值钱:
| 原则 | 1995 年的说法 | 作者 2021 年的改口 |
|---|---|---|
| McCabe 的测试难度打分 | 用一个公式算出测试难度,「没有理由不使用」 | 「已经不再有用……对不起,汤姆」17 |
| 形式化方法 | 每个项目至少要有一人熟练掌握 | 26 年里没有一个和他共事的工程师真的用过18 |
| 别榨干硬件 | 内存用满九成,开发成本翻倍 | 对当今多数应用不再成立19 |
| 先正确再提速 | 初始编码别急着优化(优化:让程序跑得更快的改动) | 现代软件工程师不需要再担心这条20 |
判断(我们的,不是书里的): 这本书 2021 年版最大的增值,不是那 201 条本身, 而是作者示范了「原则的正确用法」——每过几年,亲手复核一遍,公开点名哪条死了、哪条还活着。 绝大多数工程组织的「规范文档」从来不干这件事,于是规范本身变成了没人信的古董。 如果错,会错在: 如果原则的本质就是稳定不变(作者自己也宣称「几乎所有的原则都经受住了时间的考验」21), 那么定期复核就是走过场——但上表四条被亲口推翻的原则说明复核确实能抓出真死条目,所以这个担心不成立。
3.3 原则之间会打架
作者提醒:201 条不相互独立(几条合起来可能推出另一条),而且任意两条也不保证 100% 兼容。 他用两句俗语打比方:「距离产生美」和「眼不见,心不烦」都是真理,但不能同时用来论证同一个决定22。
实际影响:本书后面任何一章给出「应该怎么做」时,你都可能找到另一章说「反着也有道理」。 比如第 06 章一面让你「别重复造轮子」,一面写明通用的组件「更难设计,通常执行更慢」——收益和价签写在同一页。 原则不是决策机,是检查清单——真正做取舍的还是拿着清单的人。
3.4 警惕「银弹」:这一行的推销从来不断
先解释这个词。银弹(silver bullet)指那种「一招解决所有问题」的东西,出自「只有银子弹能杀死狼人」的传说; 这个词在这一行的流行,源于 Brooks 的一篇同名论文——书里多处引用它23。
作者给了一套完整的免疫力,四条:
- 每个复杂问题都「有简单解法」的建议,默认是错的。 图灵奖候选人物 Turski 说: 「每一个复杂的问题,都有一个简单的解决方案……但这是错误的!」24
- 技术先于工具。 一个没规矩的木匠拿到更强大的工具,只会变成一个更危险的没规矩的木匠; 把某项技术自动化之前,先手工把它跑通——手工都不灵,自动化照样不灵25。
- 工具只放大人。 文字处理软件让好作家更多产,却不能把平庸的小说家变好; 同理,CASE 工具(上世纪 90 年代流行的一类「把画设计图、做分析自动化」的软件工具)只该配给优秀的工程师26。
- 方法是浪潮,不是终点。 上世纪 70 年代流行的方法名字里都带「结构化」,80 年代后期都带「对象」; 两次浪潮都带来了真见识,但原本出色的组织用了之后还是出色,原本糟糕的用了之后照样糟糕27。 每波浪持续 5~7 年,但不会凭空消失——下一浪吸收上一浪最好的部分(遗憾的是,「最好」往往被「最流行」顶替)28。
配套的两个实测数字,都是给「 miracle(奇迹)式宣传」准备的解毒剂: 当时全行业宣称用某工具能提升 50%~100% 的生产力,而行业的真实年增幅只有 3%~5%29; 企业买来的 CASE 工具,七成从未被使用过——主因是购买时的过度乐观,以及随后的失望30。
3.5 最后一条地基:这是你的责任
作者观察到一件让他不平的事:桥塌了,大家问「工程师哪里做错了」; 软件失败了,工程师却有一整套现成的借口——编译器、方法步骤、经理、工期31。 他的回应不留余地:在任何工程学科里,用最好的方法也可能产出糟糕的设计。要么做好,要么压根不做。32
这不是喊口号。作者在给中国读者的信里写过,他一生中唯一一次被开除,就是因为在「明知不可能的交付日期」 这类原则上不让步;他当时的职务是技术中心总监,开除他的是副总裁。他说回头看,这是他最不后悔的一次坚持33。
4. 作者的判断与证据,分开看
| 说法 | 谁的 | 证据强度 |
|---|---|---|
| 软件开发长期不可预测,因为人在环(流程里有人参与) | 作者引 Lehman12 | 论证,无实验数据 |
| 26 年里原则几乎全部存活 | 作者 2021 自评21 | 作者自报;译者独立抽查给出 95% 的数16 |
| 四大灾难源于违反原则 | 作者 2021 举例25 | 有公开事故调查佐证,但「违反哪条原则」是作者的诊断 |
| CASE 工具七成闲置 | 作者引调查30 | 书中未给调查规模,按「行业调查」接受 |
| 方法救不了你 | 作者引 Loy27 | 观察性结论(好的组织采用前后都好) |
5. 边界与局限
- 数据停在 1995(初版)+ 2021(复审)。 书里所有价格、百分比都以美元计价的当年行情; 作者 2021 年已把工具层全部改口为「问题跟踪、版本控制、虚拟机、项目管理、调试」 (版本控制:记录每一次代码改动及其历史的工具,第 11 章专讲)34。 读的时候,凡是「工具好不好用」的条目都要打折,凡是「人怎么做决定」的条目基本照旧。
- 原则不是规范。 它没有强制性、没有验收标准、彼此还可能冲突(§3.3)。想拿它当检查清单用, 还得自己定「我的项目里哪几条是硬的」。
- 作者不是中立观察者。 他自己创业、卖过需求管理工具(后来被 IBM 收购)35, 书中对「需求」「复用」的强调带着他的职业烙印。机制层面的论述可信,趋势判断要对比着听。
- 形式化方法的争议没有结论。 作者一边在 1995 年要求每个项目配一名熟手36, 一边在 2021 年承认 26 年没人真用过18——这条原则到底算「存活」还是「已死」,作者自己都没关上话头。
6. 可带走的
- 原则 > 技术 > 语言 > 工具:换下面三层,上面那层照用;
- 软件工程的原则永远到不了物理定律的精度——因为执行它的是人;别拿「定律」的标准要求它,也别拿「没有定律」当借口;
- 每隔几年亲手复核一遍自己信的原则,公开点名死条目——作者示范过,你也可以;
- 两条俗语都能是真的,所以两条原则可能打架:原则是检查清单,不是决策机;
- 「简单三步解决一切」的建议默认是错的;行业真实生产力年增 3%~5%,宣称翻倍的都是推销;
- 工具放大人:先把技术手工跑通,再谈自动化;工具优先配给最强的人;
- 软件失败后问一句「违反了哪条原则」——这一问是这本书全部用法的入口。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 四大事故(737 MAX/勒索/阿丽亚娜/火星) | 作者序 | text/08-fm.txt:13(搜「346」) · text/08-fm.txt:19(搜「牛顿」) |
| 桥梁规范 vs 软件责任 | 作者序 | text/08-fm.txt:21(搜「建筑规范」) · text/14-ch02.txt:379(搜「编译器」) |
| 原则/技术/语言/工具四层 | 第1章 引言 | text/13-ch01.txt:9(搜「集体智慧」) · text/13-ch01.txt:11(搜「按部就班」) · text/13-ch01.txt:17(搜「软件程序」) |
| 工具的四种角色 | 第1章 引言 | text/13-ch01.txt:19(搜「顾问」) · text/13-ch01.txt:23(搜「编译器」) |
| 1964 年的原则很傻、原则会演化 | 第1章 引言 | text/13-ch01.txt:27(搜「1964」) |
| 25 年后 95% 没过时(译者) | 第1章 引言 | text/13-ch01.txt:33(搜「95%」) |
| 软件工程为什么没有物理定律 | 前言 | text/10-fm.txt:7(搜「不可预测」) |
| 原则不独立、不保证兼容 | 前言 | text/10-fm.txt:5(搜「距离产生美」) |
| 回避流行趋势(3~10 年失宠) | 前言 | text/10-fm.txt:19(搜「失宠」) |
| 银弹、方法救不了你 | 第7章 管理原则 | text/19-ch07.txt:437(搜「结构化」) · text/19-ch07.txt:447(搜「3%～5%」) |
| 技术先于工具、工具放大人、CASE 闲置 | 第2章 一般原则 | text/14-ch02.txt:215(搜「木匠」) · text/14-ch02.txt:237(搜「平庸的小说家」) · text/14-ch02.txt:225(搜「从未被使用」) |
| 浪潮 5~7 年、别忽视技术 | 第2章 一般原则 | text/14-ch02.txt:309(搜「波浪」) |
| 简单解法是错的 | 第2章 一般原则 | text/14-ch02.txt:183(搜「10个简单步骤」) |
| 研究成果转化不了 | 第2章 一般原则 | text/14-ch02.txt:371(搜「紧密合作」) |
| 要承担责任 | 第2章 一般原则 | text/14-ch02.txt:381(搜「要么做好」) |
| 作者被开除的经历 | 给中国软件工程师的寄语 | text/03-fm-a-message-to-chinese-software-engineers.txt:25(搜「fired」) |
| 2021 工具层改口 | 作者序 | text/08-fm.txt:31(搜「版本控制」) |