原文http://www.pcbdesign007.com/pages/zone.cgi?a=76785

撞击，中止，未考虑到的例外，碰撞，弹出，大规模故障。

事实是这样：所有软件都会崩溃。无论哪个供应商制造的，或者是什么应用程序或行业，所有的软件都会崩溃。我应该知道——我是一个碰撞测试假人。

当然，转转你的眼睛——每次我看到软件崩溃的时候我同样做这件事。而且我还胜人一筹，因为我至少比你多看到100次。

当然，软件工程师憎恨崩溃测试假人，但是在我的墙上再撞一次证明了墙还存在。我还是对我的工作很在行。

现在，我们要花一些时间来检查崩溃的另一面：它为什么会发生，它如何穿过缝隙的，以及为什么最好告诉你的供应商，而不是独自抓狂。我在同一条船上，但是我也理解你的设计因为崩溃而延误的时候你的心情。这是一个没有输赢的情况，当它发生时我们最好都用头撞键盘。

让我们简单地看一看一个典型软件项目，以便我们更好地了解故障发生的原因。一个简单的程序，诸如高速编辑器是根据你的行动在给定时间内由超过100个相邻文件构成的。现在，当你谈论高层次原理图或布局应用要考虑复杂性。我们谈论成千上万的文件，和超过一百万行的代码——所有的互动是一张输入和输出的复杂的网。这就像那些你放入你的设计中的集成电路一样复杂。

使用这个比喻，想想你最近放入设计中的集成电路。如果你的公司有一个简单的产品，你可能只利用了芯片功能的一部分。照理说，大部分公司将会采用“简单”类别的芯片。但是当你为芯片的复杂性感到兴奋的时候，事情就变得不确定了，因为你把水平提升到了最高层次。你现在挑战的是该芯片最好最有经验的硬件工程师。

软件同样是这样。这并不能以我们的失败为借口，但只是为了帮助提升公平的竞争环境——正如你可能忘了在制作原型之前审查设计的一个部分。（我也冒昧地说，可能一旦我们的软件通过审批之后，除非你告诉我们，否则制程中抛出一个扳手我们都不知道，这很有可能。）

图1。一个用户报告的软件崩溃的生命周期。一旦把崩溃报告给供应商，有很大一组人都会涉及其中，他们的任务是：（1）固定的软件，使它不再崩溃；（2）确保最终的解决方案使用户能够成功地完成他的任务。

软件应用崩溃可能有很多原因导致。以下是我经常碰到的几个原因：

•在很少被访问的代码行中的一个简单的输入错误。

•未考虑到的例外，也就是说你陷入了根本没有处理这一情况的代码之中。

•正如我们喜欢说的，你已经不在“情理之中”了。例如，你一直复制和粘贴，自己混乱不堪以至程序出错。有时不会马上表现出来，但后来，当你尝试做一些真正愚蠢至极的事情时，它就会暴露出来，例如通过第三方发送部件部分编码或者从布局或电路图上批注。

•死循环，让你一直等下去，因为它正在试图找寻答案，但是又回到原点。即使软件代码也会有健康问题。

•崩溃测试假人去倒了杯咖啡，忘记了十项测试中的第五项，等你来发现她的未完成的工作。

•软件工程师去倒了杯咖啡，屏幕在他眼前一闪而过，他遗漏了最后几行的报错。

•产品经理认为，用户会用到的各种方式都已经记录在案，忽略你的创造力，你可能使用了从未被人想到过的方式。

当代码以任何方式改变，软件工程师通过自动诊断运行代码，希望能抓住明显错误，诸如输入错误和悬挂逻辑。

但是你知道拼写错误检测偶尔也会错过一个大错误使你尴尬。试着设身处地地为刚刚写好需要25个配套文件例程的软件工程师想想。不仅诊断需要接触所有这些文件，确保一切正常，那个工程师必须充分知悉代码将如何被使用，以便他能支持通过代码网络的一切路径。

一旦软件工程师认为他的代码准确无误，那么就会交付给质量保证测试员。再次强调，他们必须了解代码将如何被使用，必须挖掘客户复杂的测试案例，以便在所有可能的工作情况下测试代码。这些测试对于避免故障和可能存在的功能缺陷是最有帮助的。

然后，当这工程和质量保证都相信他们已经满足了要求，那么就会交付给产品经理做最后的审查。产品经理往往要查找如用户流量这样的问题，并作为检验，以确保了软件工程和质量保证都了解所有的需求。我们中的任何一个出错都会导致你经理过的崩溃。

这个过程也绝不是直线的。公司的每个部门每天都会沟通，我们一直努力为客户提供修补程序，以增强客户手中的软件。但是，无论有多少人参与其中，人的错误都不可避免地会发生。我们是一个有重点和紧密团结的小组，但不幸的是我们和其他人类一样会犯错，会分心。

从开发上期待完美会适得其反，因为“开发”这个词本身就表明一切都是在进行之中的。所以，当你的软件崩溃是，深呼吸，并尽可能地告知供应商有用的细节，这样才能帮你解决问题。

我知道你宁可生气，拍桌子，但我恳求你走高端路线，你对进化制程的贡献会为你的同行设计师和整个行业的工程师带来益处。