跳到主要内容

通读笔记(按主题聚类,不按原书顺序)

通读完成 2026-08-27。正文 9 章(原则 1–201)+ 引言 + 作者序/前言(2021 版新增)。原书 1995 年初版,2021 年中译版附作者 26 年后的逐章复审——这是本书最独特的两层声音,拆解必须分开标。

主题簇 A:这本书是什么(原则 vs 技术/语言/工具;没有物理定律)​

  • 13-ch01.txt:7 软件产物非实体,物理定律不能成为软件工程的基础。
  • 13-ch01.txt:9 原则=工作准则,集体智慧;绝对真理或推论两种形态。
  • 13-ch01.txt:11,15,17 技术=按部就班流程;语言=基本元素+规则+语义;工具=软件程序(顾问/分析/自动化/辅助)。
  • 13-ch01.txt:27 原则随学科演化;1964 年的原则(短变量名、小程序)今天看很傻;三十年后今天的原则也一样。
  • 13-ch01.txt:31 译者注:英文原书出版 25 年后,超过 95% 的原则没过时。
  • 10-fm.txt:7 前言引 Lehman:软件开发由人管理和实现,长远不可预测;但软件展现规律性特征,所以原则可以被列出来。
  • 10-fm.txt:21 本书刻意回避流行趋势(流行 3–10 年失宠);不直接讲面向对象,讲封装。
  • 10-fm.txt:5 与 08-fm.txt:41 原则不相互独立;任意两条不 100% 兼容(「距离产生美」vs「眼不见心不烦」)。
  • 14-ch02.txt:211 P37 责任:桥塌了问工程师;软件失败时工程师怪编译器/方法/经理/时间。要么做好,要么不做。
  • 14-ch02.txt:115 P19 复杂问题都有「简单解法」的建议——Turski:那是错的。
  • 19-ch07.txt:483 P164 方法救不了你:结构化浪潮(70s–80s)、对象浪潮(80s–90s);好的组织采用前后都好。
  • 19-ch07.txt:499 P165 没有奇迹:行业生产力年增 3–5%;宣称 50–100% 增长是炒作。
  • 14-ch02.txt:179 P30 跟风小心(lemming);14-ch02.txt:183 P31 但别忽视技术(波浪 5–7 年)。
  • 14-ch02.txt:135 P22 技术先于工具(没规矩的木匠);139 P23 务实用工具(CASE 提效 10–20%,70% 的 CASE 工具从未被使用);143 P24 工具给优秀工程师;147 P25 CASE 昂贵($17,000 安装/$3,000 年费,译者注已过时)。
  • 14-ch02.txt:203 P36 研究再转化不可行(研究者缺实战;用语分歧)。
  • 08-fm.txt:53 作者 2021:CASE 一词不流行了,今天的工具=问题跟踪/版本控制/虚拟机/项目管理/调试。

主题簇 B:质量(1–7,142)​

  • 14-ch02.txt:7 P1 质量第一,没商量;Yourdon:加速测试/忽视 bug/未定先编码→说「不」。
  • 14-ch02.txt:15 P2 质量因人而异(优雅设计 vs 响应时间 vs 低成本 vs 满足需求);温伯格「政治困境」。
  • 14-ch02.txt:23 P3 效率与质量不可分:贝尔实验室——要求每千行 1–2 个 bug 时,人月 150–300 行。
  • 14-ch02.txt:31 P4 高质量可能:航天飞机软件 300 万行,每行高达 1000 美元,每万行错 <1;方法=客户参与/原型/简单设计/审查/最优秀的人。
  • 14-ch02.txt:39 P5 质量无法事后补(retrofit);一次性原型不能转产品的主要原因。
  • 14-ch02.txt:47 P6 低可靠性比低效率糟(效率可局部优化;可靠性难发现难隔离,可伤人)。
  • 19-ch07.txt:175 P142 想优化什么就优化什么:Weinberg/Schulman 五团队实验,同一需求,各被要求优化不同目标,除一个外都做到了。
  • 18-ch06.txt:87 P112 温伯格「无差错谬论」:大量错误证明软件无价值,零错误对价值什么也没说。

主题簇 C:需求为什么会错(7,10–13,15–17,20,38–44,50,130)​

  • 15-ch03.txt:7 需求工程=提出/研究问题 + 说明黑盒外部行为;产出需求规格说明。
  • 15-ch03.txt:19 P39 先定问题再写需求:电梯故事(高层楼电梯慢),六种解法(提速/新电梯/错峰/快递电梯/提租金/归位算法),成本风险差异巨大;方案变化比构建便宜。
  • 15-ch03.txt:27 P40 立即确定需求;三种徒劳希望;增量开发不是不做需求规格的借口。
  • 14-ch02.txt:51 P7 尽早交付:瀑布 99% 资源耗尽才第一次交付;原型法 5–20%。
  • 14-ch02.txt:71 P10 做好抛弃准备:Brooks;Royce 1970:第一个完整部署的系统往往是第二个造的;25% 资源给预发布版。
  • 14-ch02.txt:75,79,83 P11–13 一次性原型(快速粗糙,验关键未理解特性)vs 演进式原型(高质量,从已理解特性做起);一次性原型做快,一页纸需求。
  • 15-ch03.txt:43 P42 原型降低界面风险(故事板)。
  • 14-ch02.txt:91 P15 看到越多需要越多;文档按利于更改存储;配置管理要提前就位。
  • 14-ch02.txt:99 P16 开发中变化不可避免(Bersoff 第一定律)。
  • 14-ch02.txt:103 P17 能买不造:现成软件解 75% 问题;自造 10× 费用+100% 超支风险,最后还是 75%。
  • 14-ch02.txt:119 P20 记录假设:Lehman 约 10 行代码一个假设;直线加速器月相故事。
  • 15-ch03.txt:51 P43 记录需求为什么被引入(两秒响应例;记日期时间参与者)。
  • 15-ch03.txt:61 P44 识别子集(最小有用子集+最小增量;X 列表)。
  • 15-ch03.txt:115 P50 排优先级(橙汁 vs 生命维持;M/D/O 或 0–10)。
  • 19-ch07.txt:39 P130 客户优先级:可能 10% 必需功能按时,90% 延迟可忍。
  • 15-ch03.txt:11 P38 低质量需求→低质量估算(成本估算错误前 5 因全与需求有关)。

主题簇 D:把需求写清楚(28,32–35,41,45–49,51–60)​

  • 15-ch03.txt:35 P41 立即修需求错误:设计阶段 5×、编码 10×、单元测试 20×、交付 200×。
  • 15-ch03.txt:127 P52 每条需求单独编号(追踪的前提;R27;「应该」词匹配)。
  • 15-ch03.txt:133 P53 减少歧义:范根检查法/形式模型辅助重写/对开页。
  • 15-ch03.txt:149 P54 自然语言辅助增强而非替换;161 P55 先写自然语言再写形式模型(拨号音两版对比;先形式会描述模型而非系统)。
  • 15-ch03.txt:173 P56 需求规格保持可读(所有相关方)。
  • 15-ch03.txt:181 P57 明确规定可靠性:99.999% 无意义;三概念=需求失效/失败率/可用性(病人监护 vs 电话系统)。
  • 15-ch03.txt:191 P58 明确环境越界行为:空管 101 架飞机;前 3 个选项(报错/崩溃/忽略)不可接受但都「正确」。
  • 15-ch03.txt:205 P59 待定项自毁(开发经理 1995 年 12 月前解决)。
  • 15-ch03.txt:213 P60 需求存数据库(译者注:iCafe/TAPD/Jira)。
  • 15-ch03.txt:77 P46 需求阶段别做设计(FSM 警告注记)。
  • 15-ch03.txt:87,93 P47–48 用对方法+多视角(ER 图/状态机/Petri 网/决策表;OOA+FSM+决策树组合)。
  • 15-ch03.txt:101 P49 合理组织(电话交换:功能/通话方/视角层次)。
  • 14-ch02.txt:167 P28 形式化方法:每项目至少一人熟;先用自然语言;08-fm:61 作者 2021 自白:26 年里没有共事的工程师真用过形式化方法。
  • 14-ch02.txt:187–199 P32–35 文档标准/术语表/索引/同名同义(三类特殊命令例)。
  • 15-ch03.txt:121 P51 书写简洁(目标跟踪例)。

主题簇 E:设计是选择(21,46,61–64,69–72,79,81–83)​

  • 16-ch04.txt:7 设计=定义架构+组件算法;产出设计规格说明。
  • 16-ch04.txt:11 P61 需求→设计转换不容易;彻底设计占开发总成本 30–40%。
  • 16-ch04.txt:27 P63 评估备选方案(吞吐/响应/可变更/可移植/互操作/安全/可用);要多种架构就多用几种设计方法。
  • 16-ch04.txt:35 P64 没有文档的设计不是设计(建筑师/小说家比喻)。
  • 16-ch04.txt:19 P62 设计追溯至需求:二维表(行=组件,列=需求;空行=无用组件,空列=未满足需求);依赖唯一编号。
  • 16-ch04.txt:243 P81 设计是多维的(房子:立面/平面/电气/管道;软件:打包/依赖层次/调用关系/进程组织)。
  • 16-ch04.txt:79 P69 缩小智力距离(Dijkstra;现实结构非唯一——Siddiqi)。
  • 16-ch04.txt:93 P70 知识可控(分层+多视角;每层外部视角)。
  • 16-ch04.txt:103 P71 概念一致(有限设计形式;看起来一个人做的;概念一致>自我满足)。
  • 16-ch04.txt:115 P72 概念错误比语法错误严重(各阶段关键问题;发现愚蠢错误愉悦、概念错误自觉无能)。
  • 16-ch04.txt:257 P82 优秀设计出自优秀设计师(简洁简单优雅快速可维护易实现;灵感洞察)。
  • 16-ch04.txt:269 P83 理解应用场景(压力行为/输入频率/响应时间/天气)。
  • 14-ch02.txt:127 P21 不同阶段不同语言(电气工程师:方框图/电路图/逻辑图/时序图;Ada 用于需求设计代码?)。
  • 16-ch04.txt:215 P79 高效算法(算法分析区分快慢;作者 2021:硬件变快,这条越来越不重要)。

主题簇 F:为变化而设计(65–68,73–78,80,84–86,66)​

  • 16-ch04.txt:43 P65 封装/信息隐藏(隐藏数据结构/算法/设计决策/接口;隔离错误;OO=隐藏属性与方法)。
  • 16-ch04.txt:51 P66 别重复造轮子(电子工程师查集成电路目录;软件业把复用叫「复用」而不叫「工程」)。
  • 16-ch04.txt:59 P67 保持简单(KISS;Miller 7±2;Hoare:简单到明显没有缺陷 vs 复杂到没有明显的缺陷)。
  • 16-ch04.txt:69 P68 避免大量特殊案例(特例多=算法不合适,重想)。
  • 16-ch04.txt:127 P73 耦合与内聚(Constantine/Yourdon;低耦合高内聚;作者 2021:如今被复用/框架取代)。
  • 16-ch04.txt:139 P74 为变化而设计(模块化/可移植/可塑性/最小智力距离/知识可控/概念一致)。
  • 16-ch04.txt:155 P75 为维护而设计(硬件:制造是大头;软件:维护是大头;架构选择对可维护性影响>算法>代码)。
  • 16-ch04.txt:165 P76 为出错而设计(不省略 case;预想不可能情况;故障树分析;作者 2021:P76/P84 可能是最重要的两条)。
  • 16-ch04.txt:179,201 P77 通用性 vs P78 灵活性(通用:不改就能用,更难设计更慢;灵活:易改,更快)。
  • 16-ch04.txt:227 P80 模块规格只给用户需要的(排除算法与内部数据结构,否则级联效应)。
  • 16-ch04.txt:283 P84 不用大投资也能复用(废物利用 salvaging:问「谁做过 X」)。
  • 16-ch04.txt:293 P85 「错进错出」不正确(非法输入→可理解的报错/错误码;防多米诺)。
  • 16-ch04.txt:301 P86 冗余实现可靠性(硬件并行/冷备,成本 2×稍多,可靠性指数升;软件 N 版本:开发成本翻倍;另见 08-fm:77–81 自行车装运故事→版本控制应记每辆车的零件清单)。

主题簇 G:代码写给人看(18,35,87–106)​

  • 17-ch05.txt:89 P92 程序首先写给人看(最贵资源=人力;效率不互斥)。
  • 17-ch05.txt:17 P87 别耍技巧(Macro「愚蠢地使用高智商」;三理由含职业安全感)。
  • 17-ch05.txt:33 P88 全局变量(-16.3 艘船;封装替代;参数过多→重新设计)。
  • 17-ch05.txt:59 P90 副作用(潜伏最深最难排查)。
  • 17-ch05.txt:71 P91 有意义的命名:优秀程序员敲码只占 10–15% 时间;N_FLT=N_FLT+1 需注释 32 键 vs NEXT_FLIGHT=PREVIOUS_FLIGHT+1 无需注释 29 键。
  • 17-ch05.txt:99 P93 最优数据结构(算法与数据结构一起考虑;试 2–3 组合;封装)。
  • 17-ch05.txt:109 P94 先正确再快(作者 2021:现代工程师不必再担心)。
  • 17-ch05.txt:123,129 P95–96 注释先于代码/文档先于编码(作者 2021:96 仍是最爱,同事认为他疯了;每条注释只对应一行代码=描述过细)。
  • 17-ch05.txt:139 P97 手动运行每个组件(30 分钟 vs 3–4 人天;6 组件×30 分钟的账)。
  • 17-ch05.txt:147 P98 代码审查(Fagan 1976;发现全部错误的 82%;耗 15% 资源;净省 25–30%;测试时间省 50–90%)。
  • 17-ch05.txt:181 P101 嵌套不超三层。
  • 17-ch05.txt:189–209 P102–104 语言:按目标选;语言不是借口;语言知识没那么重要(优秀程序员用什么语言都优秀)。
  • 17-ch05.txt:237 P106 别太早编码(地基;Lehman 反向:也别太晚)。
  • 17-ch05.txt:163,173 P99–100 非结构化语言可用/结构化≠好(必要非充分)。
  • 14-ch02.txt:107 P18 手册越薄越好(在线帮助也算)。
  • 17-ch05.txt:45 P89 自上而下可读;223 P105 格式化(错误缩进比不一致更糟)。

主题簇 H:测试的三个悖论(29,107–126)​

  • 18-ch06.txt:7–21 测试定义:单元/集成/系统测试+测试计划+测试装置。
  • 18-ch06.txt:25 P107 测试追溯需求(二进制表;空行=无目的测试,空列=漏测;测试优先级=需求优先级最大值)。
  • 18-ch06.txt:39 P108 提前做测试计划(需求基线前评审可测性)。
  • 18-ch06.txt:47,63 P109–110 别测自己的软件/别写自己的测试计划(想发现 bug 的态度;相同错误假设)。
  • 18-ch06.txt:79 P111 测试只揭示缺陷存在(Dijkstra;证明正确性要完全不同的方法)。
  • 18-ch06.txt:101 P113 成功的测试发现错误(验血类比;按发现错误的可能性选测试;按善不善于发现错误考核测试组)。
  • 18-ch06.txt:111 P114 一半错误在 15% 模块(80% 在 50%;Okimoto/Weinberg:80% 在 2%;常错模块重写)。
  • 18-ch06.txt:121 P115 黑盒+白盒(求和程序里埋 213 后门例;黑盒除偶然外测不到,白盒要求路径覆盖能抓到)。
  • 18-ch06.txt:135 P116 测试用例含期望结果(否则潜意识判对;更坏:把对的判错)。
  • 18-ch06.txt:145 P117 测非法输入(0–100 排序:负数/全等/非整数/字符/空记录)。
  • 18-ch06.txt:153 P118 压力测试(测 x,还要测 x+1、x+2——呼应 58)。
  • 18-ch06.txt:163 P119 大爆炸不适用(2+2+2 月,剩 1 月,50% 完成单元测试→落后 5 个月;大集成 0.001% 机会,再拖 6 个月)。
  • 18-ch06.txt:175 P120 McCabe(圈数法 e−n+2p;曲奇刀类比;作者 2021:已无用,「对不起,汤姆」)。
  • 18-ch06.txt:193 P121 完成度度量(每周新错误率;bebugging 埋已知 bug;「用例通过率」是无效指标)。
  • 18-ch06.txt:211 P122 覆盖率(语句/分支/路径;别自欺)。
  • 18-ch06.txt:225 P123 单元测试前别集成(接口错误 vs 未测组件错误难分;脚手架/桩)。
  • 18-ch06.txt:249,263 P125–126 分析错误原因/对人不对错(技术原因+管理原因;告诉所有人)。
  • 14-ch02.txt:175 P29 荣辱与共(日本;被指出错误应感激;广而告之两好处)。

主题簇 I:人不是资源(127–141,143,151,171,172)​

  • 19-ch07.txt:11 P127 好管理>好技术(初创成功靠管理与营销;没有普适风格:几分钟内独裁者↔共识领导)。
  • 19-ch07.txt:27 P128 恰当的方法(技术/管理/政治问题各用各的方法)。
  • 19-ch07.txt:31 P129 别信你读到的一切(93% 提升可能是例外)。
  • 19-ch07.txt:49 P131 人是关键(COCOMO:最优者 4×;4 倍薪水可打平;「y 也够好且便宜」→别信;雇明星)。
  • 19-ch07.txt:67 P132 几个好手>很多生手(Reifer;Lehman 警告:好手会走,别走极端)。
  • 19-ch07.txt:77,89 P133–134 倾听/信任(走动管理;复述;下午 2 点走周末补)。
  • 19-ch07.txt:99 P135 期望优秀(Bennis 两组实验;表率;失败者转岗或离开)。
  • 19-ch07.txt:121 P137 端茶送水(午夜送比萨)。
  • 19-ch07.txt:131 P138 人的激励不同(加薪故事:「我真正需要的是一台更快的电脑」)。
  • 19-ch07.txt:143 P139 办公室保持安静(DeMarco/Lister;开放办公「便利干扰与噪声」)。
  • 19-ch07.txt:153 P140 人和时间不可互换(72 人 1 个月?;10 人 3 月延 3 月→加 10 人更延;布鲁克斯定律)。
  • 19-ch07.txt:169 P141 工程师差异巨大(效率 25×,质量 10×)。
  • 19-ch07.txt:189 P143 隐蔽收集数据(自动;不合作的数据无意义)。
  • 19-ch07.txt:277 P151 团队效率(篮球队;个人 2× 企业反而降)。
  • 19-ch07.txt:595 P171 泰坦尼克效应(登山者/绳索;徒步者/水)。
  • 19-ch07.txt:611 P172 项目事后剖析(3–4 天;延迟 10 天开始集成测试应告诉客户;「早在知道最基本需求前就开始设计」)。
  • 19-ch07.txt:113,121 P136 沟通技巧;P137。

主题簇 J:估算与排期为什么不准(38,144–168)​

  • 19-ch07.txt:199 P144 每行成本没用(高级语言:总成本降、每行成本升;Capers Jones 制造类比:固定成本由更少元件分摊)。
  • 19-ch07.txt:209 P145 没有完美的效率度量(SLOC:同功能小的更好;FP 量问题复杂度;「崩溃毁灭全人类」vs「两个孩子轻微不便」;只用来确认直觉)。
  • 19-ch07.txt:223 P146 剪裁成本估算模型(COCOMO 第 29 章)。
  • 19-ch07.txt:231 P147 别设不切实际的死线(士气/信任/离职;问题在于预先计划差)。
  • 19-ch07.txt:241 P148 避免不可能区域:交付时间 ≥ 2.15 × 人月数立方根(99% 已完成项目遵守)。
  • 19-ch07.txt:317 P154 精确估算≠万无一失(你/假设/概率;抛硬币 100 次→50 次)。
  • 19-ch07.txt:305 P153 相信排期(排期信心比排期现实更决定成败;让工程师制定或参与权衡)。
  • 19-ch07.txt:331 P155 定期重估(落后项目很少恢复;设计延 1 月→交付至少延 1 月;挤压测试时间;两种坏结局)。
  • 19-ch07.txt:345 P156 轻微低估不总是坏(努力赶工;提前则松懈;严重低估→士气崩)。
  • 19-ch07.txt:407 P160 驻波(「未来几周康复」;项目一天一天落后)。
  • 19-ch07.txt:263 P150 收集生产力数据(今天不收,明天无法剪裁;少量好数据>大量差数据)。
  • 19-ch07.txt:253 P149 先了解再评估(什么算维护?全替代算开发吗?删 95% 旧功能算什么?)。
  • 19-ch07.txt:291 P152 LOC/PM 与语言无关?(500 行 Ada ≠ 500 行汇编;影响可维护性)。
  • 19-ch07.txt:515,527 P166 进度含义(低于预算 25%≠好消息)/P167 按差异管理(「各项按计划进行,除了……」)。
  • 19-ch07.txt:541 P168 别榨干硬件(90%→成本 2×;95%→3×;作者 2021:多数应用不再成问题)。
  • 19-ch07.txt:359 P157 分配合适资源。
  • 19-ch07.txt:371,389 P158 详细计划(PERT/甘特/里程碑/标准/人员;柴郡猫)/P159 及时更新(过时计划比没计划糟;风险/警告信号/应急计划)。
  • 19-ch07.txt:465 P163 合适的流程模型(瀑布/原型/增量/螺旋/操作原型;按文化/风险意愿/领域/易变性/理解程度)。

主题簇 K:风险与预测(161,162,169,170,30–31,129,36)​

  • 19-ch07.txt:423 P161 十大风险(Boehm:人员短缺/不切实际排期/不理解需求/糟糕界面/镀金/需求变更失控/缺可复用组件/外部任务不达标/响应时间差/超越计算机技术)。
  • 19-ch07.txt:445 P162 预先了解风险:风险敞口=破坏程度×概率;决策树。
  • 19-ch07.txt:557,577 P169 对硬件乐观/P170 对软件悲观(1984 年 13 家航空公司预测:1988 年 50% 开发仍在哑终端——错;Ada 46%/复用 54%/1994 年 70% 知识系统辅助——全错)。

主题簇 L:变更控制与产品保证(15,16,173–184)​

  • 20-ch08.txt:7 产品保证=配置管理/质量保证/验证确认/测试,分权制衡。
  • 20-ch08.txt:21 P173 不是奢侈品(后三样常被当奢侈品砍;按项目定制)。
  • 20-ch08.txt:31 P174 尽早建立 SCM(不只记录工具;SCMP 计划;看板;基线受控)。
  • 20-ch08.txt:51 P175 适应过程(FAA 七层控制看板 vs 一次性原型不需要)。
  • 20-ch08.txt:63 P176 独立于项目管理(排期压力下绕过控制的诱惑)。
  • 20-ch08.txt:73 P177 轮换人员(把产品保证当流放地 vs 每个优秀工程师 2–3 年投 6 个月,作为奖励)。
  • 20-ch08.txt:87 P178 一切中间产物命名+版本+日期(部件列表)。
  • 20-ch08.txt:103 P179 控制基线(顺手修未报告 bug/加新特性不容忍;CR→CCB)。
  • 20-ch08.txt:119 P180 保存一切(Ehrlich「明智修补的首要原则是保存所有的零件」;回滚)。
  • 20-ch08.txt:131 P181 跟踪每个变更(三问题;审计追踪:请求/审批/变更/交叉引用)。
  • 20-ch08.txt:145 P182 别绕过变更控制(客户直连开发者=灾难;「控制」≠「阻止」)。
  • 20-ch08.txt:159 P183 变更请求分级排期(CCB)。
  • 20-ch08.txt:173 P184 大项目用 V&V(电话游戏:确认问前一个孩子,验证问第一个孩子——注意:与 IEEE 常用定义对调,拆解中要点破)。

主题簇 M:维护的真相(185–201)​

  • 21-ch09.txt:19 P185 软件持续变化(Lehman 持续变化定律;直到重写更划算)。
  • 21-ch09.txt:33 P186 熵增加(持续变化→更复杂更无序;可靠性与可维护性下滑)。
  • 21-ch09.txt:47 P187 没坏别修(读代码时发现疑似 bug→记录提交 CR,别顺手修)。
  • 21-ch09.txt:65 P188 治问题不治症状(传输值总=2×期望;发送前÷2 肮脏;接收端÷2 更糟;两个互相抵消的错误=未来不可维护;正解:查为什么翻倍)。
  • 21-ch09.txt:83 P189 先变更需求(SRS 先改先批准)。
  • 21-ch09.txt:99 P190 发布前错误多→发布后错误也多(别花钱填坑,废弃替换)。
  • 21-ch09.txt:113 P191 程序越老越难维护(每次改动需修改的组件比例上升;结构恶化)。
  • 21-ch09.txt:131 P192 语言影响可维护性(APL/BASIC/LISP 快开发难维护;Ada/Pascal 反之;Eiffel 强制高内聚低耦合)。
  • 21-ch09.txt:149 P193 有时重新开始更好(重建/翻新/逆向工程难;「维护者真的会用你补的设计文档吗?」)。
  • 21-ch09.txt:163 P194 先翻新最差的(800 行模块占 30% 改正性维护成本)。
  • 21-ch09.txt:177 P195 维护引入比开发更多的错误(20–50% 的改动引入新错误)。
  • 21-ch09.txt:197 P196 每次变更后回归测试(改正性/适应性/完善性维护;验证旧功能还正常)。
  • 21-ch09.txt:213 P197 「变更容易」的信念使变更更易出错(Weinberg 自我失效模型;放松警惕)。
  • 21-ch09.txt:233 P198 非结构化代码机械结构化≠更好(同样糟;从头重设计)。
  • 21-ch09.txt:249 P199 优化前先性能分析(80/20;热点)。
  • 21-ch09.txt:265 P200 保持熟悉(Lehman 熟悉守恒:版本间变化量高于平均→质量差/可靠性差/超支;心理熟悉度随时间衰减;结论:保持发布间改动量稳定)。
  • 21-ch09.txt:287 P201 系统的存在促进演变(完美需求也会变:系统进入环境就改变环境,引发新问题)。

作者序(2021)逐章自白——「哪些还绝对正确、哪些我怀疑了」专列​

  • 08-fm.txt:19–25 四个灾难:737 MAX MCAS 单点故障(346 死,测试不彻底);勒索软件;阿丽亚娜 5 溢出;火星气候轨道器磅/牛顿单位沟通错误。
  • 08-fm.txt:29 桥塌→建筑规范;软件失败→组织没遵守某条原则。
  • 08-fm.txt:61 形式化方法:26 年没有一个共事工程师真用过(但他们本质会形式化思考)。
  • 08-fm.txt:65 创业环境:MVP 序列+问题跟踪工具里用自然语言维护需求(优先级/目标版本/状态/注解)=P60 精神。
  • 08-fm.txt:73 耦合内聚被复用取代;框架鼓励弱耦合强内聚,「不再需要考虑它」。
  • 08-fm.txt:77 P76/P84 可能是最重要的;「不再称之为重用,简称软件开发」。
  • 08-fm.txt:85 P94 不用再担心;P96 仍是最爱(同事认为他疯了)。
  • 08-fm.txt:93 P120 McCabe 已无用(「对不起,汤姆」);P124 现代工具自动化。
  • 08-fm.txt:101 管理侧:129/131/132/133/134/135/137/138/140/142/147「不相信这些就别当经理」。
  • 08-fm.txt:109 自行车托运故事→版本控制应记每个组件版本与组合(应成新原则);176/177 不再那么重要。
  • 03-fm:25 给中国工程师的信:被开除过一次,因为坚持原则(明知不可能的交付日期/未充分测试/违反道德);「你不会为此失眠,因为你知道自己做了对的事」。

切分预案(12 章)​

A→01;B→02;C→03;D→04;E→05;F→06;G→07;H→08;I→09;J+K→10(估算与风险);L→11;M→12。 第 10 章若太肥,把风险(161/162/169/170)挪进 09 或 11。