此章是从全局视角出发，讲了不少防控bug、debug方面的思路，但由于对debug的应对上已经有些年代了，我认为不太适用于当下，故不赘述。
bug 防控
- 强调了4、5、6章所讨论的获取概念完整性，可以大大降低bug数量
- 自顶向下的设计。
- 结构化编程。
这里主要关注一下第二点；
自顶向下的设计
将程序开发划分成 体系结构设计 、 设计实现 和 物理编码实现 ，每个步骤可以使用自顶向下的方法很好地实现。
将设计看成一系列精化步骤。
- 开始是勾画出能得到主要结果的，但比较粗略的任务定义和大概的解决方案。
- 然后，对该定义和方案进行细致的检查，以判断结果与期望之间的差距。
- 同时，将上述步骤的解决方案，，在更细的步骤中进行分解，每一项任务定义的精化变成了解决方案中算法的精化，后者还可能伴随着数据表达方式的精化。
- 在这个过程中，当识别出解决方案或者数据的模块时，对这些模块的进一步细化可以和其他的工作独立，而模块的大小程度决定了程序的适用性和可变化的程度。( 模块化 )
Wirth 主张在每个步骤中，尽可能使用级别较高的表达方法来表现概念和隐藏细节，除非有必要进行进一步的细化。
好的自顶向下设计从几个方面避免了 bug。
- 首先，清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。
- 其次，模块分割和模块独立性避免了系统级的 bug。
- 另外，细节的隐藏使结构上的缺陷更加容易识别。
- 第四，设计在每个精化步骤的层次上是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上。
最后好好品一品这段话
当遇到一些意想不到的问题时，按部就班的流程并不意味着步骤不能反过来，直到推翻顶层设计，重新开始整个过程。
实际上，这种情况经常发生。 至少，它让我们更加清楚在什么时候和为什么抛弃了某个臃肿的设计，并重新开始。
一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了很多表面装饰般的补丁。自顶向下的方法减少了这样的企图。
剩下的几乎都是单元测试以及和环境相关的内容，以现在软件迭代的速度来看：给核心功能编写测试用例；以及使用docker来统一dev、test、prod这些不同的环境可能会更加适用，只是我并未涉猎这些方面，故不赘述。