13.1 第4、5、6章所意味的煞费苦心、详尽体系结构工作不但使产品更加易于使用，而且使开发更容易进行以及bug更不容易产生。
13.2 V.A.Vyssotsky提出，“许许多多的失败完全源于那些产品未精确定义的地方。”
13.3 在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性。开发人员自己不会完成这项工作。（Vyssotsky）
13.4 “十年内[1965～1975]，Wirth的自顶向下进行设计[逐步细化]将会是最重要的新型形式化软件开发方法。”
13.5 Wirth主张在每个步骤中，尽可能使用级别较高的表达方法。
13.6 好的自顶向下设计从四个方面避免了bug。
13.7 有时必须回退，推翻顶层设计，重新开始。
13.8 结构化编程中，程序的控制结构仅由支配代码块（相对于任意的跳转）的给定集合所组成。这种方法出色地避免了bug，是一种正确的思考方式。
13.9 Gold结果显示了，在交互式调试过程中，第一次交互取得的工作进展是后续交互的三倍。这实际上获益于在调试开始之前仔细地调试计划。[我认为在1995年依然如此。]
13.10 我发现对良好终端系统的正确使用，往往要求每两小时的终端会话对应于两小时的桌面工作：1小时会话后的清理和文档工作；1小时为下一次计划变更和测试。
13.11 系统调试（相对于单元测试）花费的时间会比预料的更长。
13.12 系统调试的困难程度证明了需要一种完备系统化和可计划的方法。
13.13 系统调试仅仅应该在所有部件能够运作之后开始。（这既不同于为了查出接口bug所采取 “合在一起尝试” 的方法；也不同于在所有构件单元的bug已知，但未修复的情况下，即开始系统调试的做法。）[对于多个团队尤其如此。]
13.14 开发大量的辅助调试平台（scaffolding 脚手架）和测试代码是很值得的，代
码量甚至可能会有测试对象的一半。
13.15 必须有人对变更进行控制和文档化，团队成员应使用开发库的各种受控拷贝来工作。
13.16 系统测试期间，一次只添加一个构件。
13.17 Lehman和Belady出示了证据，变更的阶段（量子）要么很大，间隔很宽；要么小和频繁。后者很容易变得不稳定。[Microsoft的一个团队使用了非常小的阶段（量子）。结果是每天晚上需要重新编译生成增长中的系统。]
