大纲:201-principles-software-development
书型裁决:这是一本 201 条原则的汇编,不是叙事书。拆解的出路是重组——把 201 条按主题聚成 12 条决策主线,每条主线讲透原则背后的因果;原则名当例子用,不逐条罗列。原书 9 个正文章(原则 1–201)+ 引言,按新主线重新归置;导航章(目录/索引/推荐序)不读不引,作者序/前言因承载 2021 版作者复审,引。
主线:软件工程没有定律,只有从事故里换来的原则 → 这些原则沿着一条链互相咬合:先弄清质量是什么(02)→ 需求为什么会错、怎么写清楚(03/04)→ 设计怎么在变化里选(05/06)→ 代码的成本账(07)→ 测试能证明什么(08)→ 人怎么被组织(09)→ 未来怎么被预测(10)→ 变化怎么被控制(11)→ 长期演化会发生什么(12)。
章节(12 章)
01-no-laws.md没有定律,只有原则- 进来时以为:软件工程要么像物理学一样有定律,要么全凭个人经验 → 出去时知道:原则=跨技术/语言/工具都成立的、从集体经验提炼的工作准则;它因「软件开发由人执行」而永远到不了物理定律的精度,会过时、会互相冲突,遵守与否是工程师个人的责任
02-quality.md质量:人人都要,各说各话- 进来时以为:质量是一个大家都懂、可以共同追求的单一目标 → 出去时知道:质量在开发者/客户/老板眼里是四种不同的东西且互相冲突,必须先排优先级;质量与效率此消彼长(有配对数字),高质量做得到但极贵(航天飞机的账),而且无法事后补上
03-requirements-why.md需求为什么会错:问题先于方案- 进来时以为:需求错了是因为客户没说清楚 → 出去时知道:需求错首先因为「问题是什么」没找准(电梯故事的六种解法);真实需求只有等人摸到东西才浮现,所以要尽早交付、准备抛弃第一个系统、能买不造、把每条假设写下来(月相故事)
04-requirements-write.md写需求:和歧义的战争- 进来时以为:需求聊清楚、写下来就完事 → 出去时知道:书面需求是一场与歧义的战争:同一个错误越晚修越贵(5×/10×/20×/200×),每条需求要能单独编号被追溯,自然语言与形式模型是互补不是二选一,连「99.999% 可靠」这种话都必须先定义成三种含义之一,还要替环境越界的时刻预先写好行为
05-design-choice.md设计是选择:从外部行为到内部结构- 进来时以为:设计是把需求「翻译」成代码结构 → 出去时知道:从外部行为到内部结构没有唯一正解,设计=列出多种架构、逐一按目标权衡后选择;选择必须能被追回(组件×需求矩阵走查);概念一致、概念错误这两个「软」指标比语法对错更要命
06-design-for-change.md为不可躲的变化而设计- 进来时以为:好的设计是一次到位的设计 → 出去时知道:变化是常态,设计只能选「未来哪种改动最便宜」:信息隐藏、低耦合高内聚、模块规格只露必需;每个封装决定都是对未来改动方向的下注,冗余能买可靠性但要付双倍开发费
07-code-for-people.md代码是写给人看的- 进来时以为:代码主要写给机器执行,可读性是奢侈 → 出去时知道:最贵的资源是人,代码第一读者是下一个改它的人;这有 成本账:好命名省 3 次按键还省一行注释、手动执行 30 分钟抵 3–4 人天、审查花 15% 资源省 25–30% 总成本
08-testing-paradoxes.md测试:冲着坏消息去- 进来时以为:测试通过=软件没问题 → 出去时知道:三个悖论——测试只能证明缺陷存在不能证明不存在;成功的测试是发现错误的测试;零错误对软件价值什么也没说;错误高度聚集(一半错误在 15% 模块),赶工跳过单元测试的大集成反而更慢(5 个月的账)
09-people-not-resources.md人不是资源- 进来时以为:加人、加班、换工具总能换回进度 → 出去时知道:人和时间不可互换(布鲁克斯定律的算术),工程师之间差 25 倍效率 10 倍质量,激励因人而异(加薪不如一台更快的电脑),安静办公室与相互信任比任何工具都更能改变产出
10-estimation-risk.md估算、排期与风险:预测为什么总是失败- 进来时以为:估算不准是经理无能或程序员偷懒 → 出去时知道:估算是对概率分布的猜测(抛 100 次硬币),被数学下限(2.15×人月数立方根)卡死,度量口径(代码行/功能点)各有致命漏洞;不切实际的死线先杀士气再杀质量;唯一出路是把风险量化成「敞口」提前排计划
11-change-control.md给「改」立规矩:变更控制与产品保证- 进来时以为:改自己的代码是开发者的自由 → 出去时知道:软件一生都在被改,谁有权改、怎么改、改完怎么记,是配置管理的全部:命名+版本、基线、变更请求、控制委员会、审计轨迹;产品保证(配置管理/质量保证/验证确认)不是奢侈品而是分权制衡,必须独立于项目压力
12-maintenance-truth.md维护的真相:软件在腐败, 除非你管住变化- 进来时以为:维护是开发完成后的收尾杂活 → 出去时知道:软件有熵——持续变化让它持续变复杂变脆弱(雷曼四定律);维护本身引入 20–50% 新错误;治症状不治病、顺手修、「这次改动很简单」是三大腐蚀源;把每次发布的变化量控制平稳,才能活得久
自查记录
- 两两比对「出去时知道」:02(质量是什么)≠08(测试能证明什么);03(问题没找准)≠04(写不清楚);05(怎么选)≠06(怎么抗变化);09(人)≠10(数);06(设计期留余地)≠11(变更期的流程控制)≠12(长期演化的后果)——无重复。
- 原书覆盖核对:原则 1–201 全部落位;引言→01;一般原则散布 01/02/03/04/07/09/10/11;需求 38–60→03/04;设计 61–86→05/06;编码 87–106→07;测试 107–126→08;管理 127–172→02/03/09/10;产品保证 173–184→11;演变 185–201→12。作者序 2021 复审随各章「边界与局限」散布。