质量:人人都要,各说各话 — 在定义它之前,别谈追求它
这一章讲三件事: 为什么「质量第一」喊着容易做着难;质量和开发效率之间的兑换率是多少; 以及为什么不趁早谈质量、事后就再也没有机会。 全书剩余的 190 多条原则,做的都是同一件事:给「质量」这个词的不同侧面各修一条路。
1. 先看现象:质量会议开不出结果
项目例会上,「提高质量」通常全票通过。然后:
- 开发负责人说:质量是设计优雅、代码干净;
- 客户说:我要 的是响应快、不宕机;
- 老板说:质量是按期、不超预算;
- 市场说:质量是什么需求都满足。
四个都说的是「质量」,四个说的是四件事。更麻烦的是,它们互相冲突: 把代码写得极其优雅往往要拖工期,把响应时间压到极限往往要堆成本。 作者把这叫温伯格的「政治困境」:你优化任何一个人关心的质量时,通常就在损害另一个人关心的质量1。
这一章要解决的不是「怎么提高质量」,而是更前面的问题:先承认质量是个多义词,再逼项目把词义钉死。
2. 顶层全景:质量的兑换链
「质量第一」(原则1)
│ 但质量没有唯一定义(原则2)
▼
项目必须自选:优化谁眼里的质量?
│ 选完就付出了价签(原则3):效率下降
▼
极高质量买得起吗?──买得起(原则4):有实价
│
▼
但只有一条路:开发时就做对(原则5)
└─ 优先买哪种质量?(原则6):可靠性 > 效率
图说:本章六个原则排成一条单行道:先认账(多义词)→ 付价签(效率)
→ 看天花板(做得到)→ 记住唯一入口(开发时)→ 站位(可靠性优先)。
3. 核心原理
3.1 质量第一:什么意思,什么不意思
原则 1 的 原文态度极端:质量必须放在首位,没有可商量的余地。 作者承认,「即使质量没达标也按时交付」看起来是政治正确,但这是短视,「从中长期来看,这样做是自杀」2。
这条原则的可执行部分,是 Yourdon 给的三句「不」2。当有人说出下面的话,正确回答是说「不」:
| 场景 | 危险在哪 |
|---|---|
| 「测试压缩一周,先上线」 | 没跑过的缺陷直接到了用户手里 |
| 「剩这几个小 bug 就别管了」 | 「小」是谁判的?修 bug 越晚越贵(第 04 章给数字) |
| 「需求和设计还没定,就先写代码」 | 基础没打就开始盖楼(第 07 章专讲) |
3.2 质量的四张脸
同一份软件,四个相关方看到四种质量1:
| 谁在看 | 他说的「质量」是 |
|---|---|
| 开发者 | 设计优雅、代码干净 |
| 紧张环境里的客户 | 响应快、吞吐(单位时间里能干完的活)也大 |
| 成本敏感的项目 | 便宜 |
| 另一些客户 | 已知和未知的需 求全满足 |
这个表的含义不是「相对主义」,而是一条纪律:项目必须挑出优先级,并且向所有相关方明说1。 不挑,就等于把挑选权交给了嗓门最大的人。
3.3 主走查:五个团队,同一份需求,五种「质量」
「优化谁眼里的质量」不是一个哲学问题——它直接决定交付物长什么样。 书里引用了一个里程碑式的实验(Weinberg 与 Schulman):五个开发团队拿到完全相同的需求, 唯一的区别是每个团队被告知优化的东西不同:开发时间、程序大小、占用的数据空间、程序清晰度、用户友好度。 结果:除一个团队外,其他四个团队做出的程序,都恰好在自己被指定的那个属性上排第一3。
把这个实验走成一张具体的账(交付物的各项数字是为演示编的,量的规律来自原实验):
| 团队被要求优化 | 交付时长 | 代码量 | 内存占用 | 可读性打分 |
|---|---|---|---|---|
| 开发时间 | 6 周(最快) | 大 | 大 | 低 |
| 程序大小 | 12 周 | 最小 | 小 | 低 |
| 数据空间 | 11 周 | 小 | 最小 | 中 |
| 程序清晰度 | 10 周 | 中 | 中 | 最高 |
| 用户友好度 | 9 周 | 中 | 中 | 中 |
(时长与打分的具体数字为演示编的;实验的真实结论只有一句:告诉团队优化什么,团队就真的优化出了什么。)
倒过来读这张表,就是这条原则的管理用法:
- 你对团队说「工期、大小、可维护性、性能、友好度都重要」——结果是什么都得不到优化4;
- 你只点名一两个,其余明说「这次不重要」——被点名的就会真的变好。
3.4 质量和效率的兑换率:有实测数字
原则 3 说效率与质量密不可分,而且给了配对的数:
贝尔实验室实测,要求每千行代码 12 个缺陷(bug,指程序里会造成错误行为的毛病)时,
一个人的产出是每月 150300 行代码;一旦想再提速,缺陷密度就上升5。
先解释两个计量单位,后面全书都要用:
- 人月:1 个人干 1 个月的工作量,用来量「投入」;
- 代码行(KLOC 里的 K=千):用来量「产出」。两个都是粗糙的尺子,粗糙在哪,第 10 章专讲——这里先用。
这组数字的价值在于配对:「每千行 12 个缺陷」是当时相当严格的质量线,
对应「每月 150300 行」的产出线。它们是一枚硬币的两面——
想把产出线抬高而质量线不动,实测结果是质量线先破5。
3.5 极高质量买得起吗?买得起,看价签
原则 4 给了一个正面例子,数字完整,值得整段走一遍6:
IBM 为美国宇航局航天飞机开发的机载飞行软件:约 300 万行代码; 造价每行高达 1000 美元(参照:同一个书架上的另一组数——普通商业项目做不到这个价,它的参照物是下面的质量线); 发布后每万行代码发现的缺陷少于 1 个。
拿 3.4 节的数当参照物:贝尔实验室那条「严格」的质量线是每千行 12 个缺陷,
航天飞机软件是每万行不到 1 个——**好上 1020 倍**。价签也明确:每行 1000 美元,300 万行就是 30 亿美元量级
(乘法是我们做的,书里给了单价与行数)。
作者随后开列「怎么做到」的清单,恰好是后面各章的目录6:
| 方法 | 在哪一章细讲 |
|---|---|
| 让客户参与 | 第 03 章 |
| 原型设计(全面开发前验证需求) | 第 03 章 |
| 保持设计简单 | 第 06 章 |
| 审查代码 | 第 07 章 |
| 雇最优秀的人 | 第 09 章 |
3.6 唯一的入口在开发时;先买可靠性
质量没法事后补。 原则 5 的论证是一句反问:你全力做,高质量都不容易; 不全力做,凭什么指望改进的时候补回来?这也是「一次性原型不能转成产品」的主要原因—— 粗糙的东西改不成精致的东西,只能重做7。
要买质量,先买可靠性。 原则 6 给了排序的理由:效率低,通常还能定位到拖时间的部件, 单独重做它(书里预告了这个办法,第 12 章的性能剖析一节兑现);而可靠性差, 问题可能上线多年才暴露、难以隔离,极端情况会伤人8。
把这一节和 3.5 合起来,就是本书质量观的全图: 质量的极致买得起(但按行计价);它只有一个入 口(开发时);入口处先排座位(可靠性坐第一排)。
4. 作者的判断与证据
| 说法 | 谁的 | 证据 |
|---|---|---|
| 质量没达标也交付=自杀 | 作者(原则 1)2 | 论断;附 Yourdon 的三句「不」 |
| 质量多义且互斥 | 作者引温伯格1 | 观察;「政治困境」是温伯格的命名 |
| 五团队各赢所求 | 作者引实验3 | 有对照的实验(一个团队未达标,书里没说是哪个、差多少) |
| 质量线↔产出线配对 | 作者引贝尔实验室5 | 实测数据(样本范围书里未给) |
| 零缺陷不等于有价值 | 温伯格「无差错谬论」9 | 论断;书里用它反过来钉住需求侧(开发错系统,一切白费) |
判断(我们的,不是书里的): 把 3.3 的实验结论放到今天,它的现代版本是: 代码评审关注什么,提交就长什么样。 团队被要求「小步快跑」就真的一堆小提交, 被要求「测试覆盖」就真的多测试——这条规律的适用范围早就超出了当年的五个团队。 如果错,会错在: 如果团队的产出主要由个人能力而非被告知的目标决定(见第 09 章:工程师之间差 25 倍), 那么目标设定的作用就会被高估——稳妥的读法是:目标决定方向,能力决定幅度,两者都在起作用。
5. 边界与局限
- 数字是 1980 年代前后的。 贝尔实验室的产出线(每月 150~300 行)、航天飞机的价签(每行 1000 美元) 都属于大型机与汇编的年代;「代码行」这把尺子本身的问题第 10 章会拆。 配对的规律(质量线紧则产出线松)没有过时,具体的数不能直接套用。
- 「质量第一」没有给出仲裁机制。 作者说项目必须排优先级并明示各方(3.2 节), 但谁来拍板、冲突时听谁的,书里留给了管理者(第 09 章)。
- 「效率不重要了」是误读。 作者 2021 年复审时说「先正确再提速」这条可以少担心(硬件快了)10, 但被松掉的是微优化,不是 3.6 的排序:可靠性优先于效率的排序,他没有收回。
6. 可带走的
- 开质量会前先问一句:这次优化谁眼里的质量?——四个相关方四种答案,不点名就等于弃权;
- 「工期、质量、成本、功能都重要」等于什么都没说;只点名一两个,并且明说其余的代价;
- 质量线与产出线一起动:实测「每千行 1
2 个缺陷」对应「每月 150300 行」,提速先破质量线; - 极高质量买得到:航天飞机软件每万行缺陷不到 1 个,代价是每行 1000 美元——把「不可能」改成「报价」;
- 质量无法事后补:粗糙的原型改不成精致的产品,要精致就重做;
- 买质量先买可靠性:效率低有救,可靠性差会埋雷多年;
- 零缺陷对价值什么也没说:消除了所有缺陷,也救不了「开发的不是客户要的系统」。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 质量第一、三句「不」 | 第2章 一般原则 | text/14-ch02.txt:11(搜「自杀」) |
| 质量四张脸、政治困境 | 第2章 一般原则 | text/14-ch02.txt:19(搜「政治困境」) |
| 效率与质量配对数字 | 第2章 一般原则 | text/14-ch02.txt:27(搜「150～300」) |
| 航天飞机软件的价签与质量线 | 第2章 一般原则 | text/14-ch02.txt:35(搜「1000美元」) · text/14-ch02.txt:35(搜「300万 行」) |
| 质量无法事后补 | 第2章 一般原则 | text/14-ch02.txt:45(搜「一次性原型」) |
| 可靠性优先于效率 | 第2章 一般原则 | text/14-ch02.txt:53(搜「人员伤害」) |
| 五团队实验 | 第7章 管理原则 | text/19-ch07.txt:175(搜「五个软件开发团队」) |
| 都重要=都不优化 | 第7章 管理原则 | text/19-ch07.txt:177(搜「同等重要」) |
| 无差错谬论 | 第6章 测试原则 | text/18-ch06.txt:89(搜「无差错谬论」) |
| 「先正确再提速」2021 改口 | 作者序 | text/08-fm.txt:51(搜「94」) |