11.4 与错误打交道

公司里的每个人都有一个客户”。

通常而言，这个所谓的客户，就是你的工作伙伴，你要将工作依次转交给他。而你必须首先把你的那个小循环（设计－编写－测试）做好，才能把它交付给你的工作伙伴——就好像你在销售商品一样。

当你把你的工作成果交付给你的客户／工作伙伴的时候，他／她就会立刻对它进行检测，并把其中的错误反馈给你，让你进行修改，让你知道你的这份工作完成的到底怎么样。从某种意义上来看，软件的这种自下向上的发展过程与罗德尼·布鲁克斯的那种包容结构本质上并无不同。每个小步骤都是一个小的代码模块，能确保自身的正常运行，在此基础上，人们叠加和测试更复杂的层级。

单靠这些小步骤并不能得到零缺陷的软件。“零缺陷”的目标隐含着一个关键的概念区分。所谓缺陷，是指被交付出去的错误；而在交付之前被修正的错误，不能算是缺陷。按新乡重夫的说法，“我们绝对不可能避免错误，但是我们可以避免错误成为缺陷”。因此，零缺陷设计的任务就是尽早发现错误，尽早改正错误。

不过，这是显而易见的事情。真正的改进在于尽早发现产生错误的原因，并尽早清除产生错误的原因。如果一个工人总是插错螺栓，那就设置一个防止插错螺栓的系统。犯错的是人，处理错误的则是系统。

日本人在防错领域的经典发明是一种称为Poka-Yoke的防错系统[16]——它可以使事情对人们所犯的错误具有“免疫力”。在装配线上设置一些巧妙而简单的装置就可以防止错误的发生。比如，在放螺栓的托盘上为每一个螺栓设定一个特别的孔位，这样，如果托盘上有螺栓剩下，操作人员就知道自己漏装了一个。在软件生产中，有一种防错设计是“拼写错误检查器”，它不允许程序员输入任何拼写错误的命令，甚至不允许他／她输入任何非法（非逻辑）命令。软件研发人员们有越来越多可供选择的非常精巧的“自动纠错程序”软件，用来检查正在编写中的程序，以防止典型错误的出现。

还有那些顶尖级的研发工具可以对程序的逻辑进行分析和评价——它会说，“嘿！这一步根本没意义！”，从而在逻辑错误一出现的时候就将其清除。有一本软件业的交易杂志最近列出了近百种检错和改错工具，沽价待售。

其中最精致的一种还可以像那些优质的拼写检查软件一样，为程序员提供合乎逻辑的改错选择。

另外一种非常重要的防错方法是对复杂软件进行模块化。1982年发表在IEEE的《软件工程交易》上的一个研究显示，在其他条件完全相同的状况下，代码总行数相同的程序拆分为子程序之后，错误数量是如何减少的。一个一万行的程序，如果是一整块，它有三百一十七个错误，如果把它拆分为三个子程序，那么总数还是一万行的程序，错误数则略有减少，为二百六十五个。每拆分一次所减少的错误量，大致符合一个线性方程，所以模块化虽然不能完全解决问题，但它却是一种有效的手段。

进一步来说，当程序小到某个阈限以下之后，就可以达到完全没有错误的状态。IBM为它们的IMS系列所写的代码，就是以模块化的方式编制的，其中有四分之三的模块达到了完全没有缺陷的状态。具体来说，就是在四百二十五个模块中，有三百个是完全没有错误的。

而在剩下的一百二十五个有错误的模块中，有超过一半的错误集中发生在仅仅三十一个模块上。从这个意义上说，程序编制的模块化，就是程序的“可靠化”。

在软件设计领域，现在最热的前沿就是所谓“面向对象”的软件。一个面向对象的程序（OOP）实际上就是一个相对去中心化的、模块式的程序。对于一个OOP来说，它的一个“碎片”，就是一个独立成立、保持自身完整性的单元；它可以和其他的OOP“碎片”整合在一起形成一个可分解的指令结构。“对象”限制了程序漏洞所能造成的损害。和那种传统程序不同，OOP有效地对功能实行了隔离，把每一个功能都限制在一个可掌控的单元内，这样一来，即使一个对象崩溃了，程序的其他部分也能够继续运转，而对于传统程序来说，一个地方出了问题，整个程序就会崩溃。程序员可以把这个坏掉的单元换掉，就好象我们可以给一个汽车换刹车片一样。软件的销售商可以购买或者销售各种事先编制好的“对象”库给其他的软件研发人员，后者则可以基于这些库里的对象快速地组装起大型软件，而不用再像以前那样重新一行一行地编写新的代码。而到了要为这种大型软件升级的时候，你所要做的就是升级旧的对象或者加入新的对象。

OOP中的“对象”，其实就像乐高（Lego）

积木玩具中的那些小块，但这些小块可能还带着非常微小的智能。一个对象可以类似于苹果电脑显示器上的一个文件夹图标，只不过这个图标知道自己是一个文件夹，而且可以对某个程序要求所有文件夹列出内容清单的请求作出响应。一个OOP也可以是一张税表，或者某个雇员在公司的数据库，或者某个电子邮件信息。对象知道自己能干什么不能干什么，同时也在和其他的对象横向交流。

面向对象的程序使软件具备了中等程度的分布式智能。它和其他分布式的存在一样，有一定的抗错性，能够（通过