共计 2118 个字符，预计需要花费 6 分钟才能阅读完成。
原文链接: https://www.simplethread.com/your-software-can-learn-a-lot-fr…
为良好失败设计
回顾一下你最初一次应用 ATM，很有可能，你左近就有一台，你应用 ATM 机的次数，你本人都数不清。
你从 ATM 接管到过数目不对的钱嘛？我猜的答案肯定是没有过，只管 ATM 机每年存取数百万的钱。只管解决像发放正确数量现金这样的简单工作，ATM 机的可靠性证实了设计的独创性。ATM 机是如何实现高牢靠的。可能你会感到十分诧异，答案是相当简略的。ATM 机采纳了一个比较简单的机制，从一叠钞票中一张一张的抽出，而后在通过时验证他们的厚度。如果抽取的钞票比预期的要厚，很可能是因为多张钞票粘在了一起，取款就会被回绝并留下来供人工查看，这个零碎并不完满，它为良好失败所设计。
那么这与软件设计有什么关系呢?
ATM 给咱们提供了好多贵重的教训:
- 执行工作
- 验证工作
- 验证工作执行失败，进行和再次尝试，
这种设计的美好之处在于其简洁性，ATM 机不是通过创立简单的机制来确保百分之百的可靠性，而是被设计为优雅的解决故障。这是软件开发者须要用心记下来的一节课。为了构建牢靠的零碎，上面一些步骤需遵循。
被许多开发者所忘记的准则
为了建设高牢靠的零碎，你须要:
- 执行繁多、可验证的工作
- 验证工作的执行后果
- 如果验证失败，就撤销可撤销的操作，告诉相干人员。
上面设设计软件中，也须要防止一些做法:
下图是软件设计中须要遵循的实际
- 在验证之前不要做多个操作: 放弃简略, 验证每个步骤。
- 防止为了清理删除一些货色: 相同，隔离有问题的文件能够保留状态信息，这会帮忙咱们解决问题。
- 不要主动去修复问题: 除非你对问题确信无疑，否则编写错误处理代码可能会引发意料之外的问题。
- 失败的时候要有日志记录或状态隔离: 当呈现谬误时，收集数据，并将其搁置在已知的谬误地位。
- 不要在共享地位执行操作: 如何可能呈现故障，在一个长期区域先执行操作。
简略，验证，无效的失败解决
简而言之，软件设计哲学该当和 ATM 设计相似，崇尚简略，确保验证，无效的解决失败。软件的牢靠并不需要借助简单，他须要领有良好的故障解决能力。让咱们持续从物理工程外面汲取灵感，在软件设计中记录这个无效的教训。
上面是文章的评论
- 读者 Nicholas Piasecki 的评论:
如果技术人员调换了 10 美元和 20 美元 墨盒，那么 ATM 机就会给出谬误的金额，这揭示了一个令人丧气的事实，就是总有出错空间。因为我遇到过一次这样的状况，我立即走入了左近的一家分行，退出了丧气人群的队伍，他们都不太高兴，设想一下，被扣掉 80 美元，但只拿到了 40 美元。(有些机器曾经通过只有 20 美元来解决这个问题)
但这依然是一个不错的倡议，就像红绿灯一样，如果工夫谬误导致两个相同方向的的红绿灯都呈现了绿灯，那么保险丝会被熔断，导致所有的信号灯都进入到闪动的“黄灯 / 红灯模式”。很多软件都能够采纳相似的保险丝技术。他放弃了持续运行，直到有人来查看我为止。然而可怜的是，这种故障爱护在软件中意味着“解体”而不是降级。
尤其是故障很少产生时，你能够间接点重试，而不是编写很少应用的异样代码。
- 读者 mat roberts 的评论:
我已经在 ATM 机外面取出谬误的金额，只有一次，那是一个硬件问题 – 纸币又旧又皱，不晓得是什么起因，在机器外面被卡住了。
作者回复 Nicholas Piasecki:
这就是互联网，我晓得我一发这篇文章就能收到 1000 条从 ATM 机外面取到谬误金额的评论。
Jonathan Pryor 的评论:
总结这篇文章就是放弃简略，放弃简略，放弃简略，放弃简略。哦，还是放弃简略(因为放弃简略而容易验证)，这也是咱们为什么要有开发者准则，不要捕捉异样(Exception 异样的基类)，除非前面跟着软件的退出，因为它不简略而且无奈确定具体捕捉的是什么异样(比方 OutOfMemoryException)，程序是否平安的继续执行。
放弃简略、愚昧，如果咱们认为很厉害，咱们曾经失败了，咱们须要时刻揭示本人咱们并不聪明，这样做，咱们将确保咱们的软件能够被普通人所了解，这对咱们都有益处，因为咱们都是凡人。
读者 Al Tenhundfeld 的评论:
这与 Erlang 的“让其失败”准则有些相似，只管不完全相同。指标是尽量避免失败复杂化你的设计。
我没有应用 Erlang 工作过，但据我理解，Erlang 在解决故障的时候应用了一种乏味的繁多职责办法，你不会在你的畛域实现外面混淆大量的谬误弥补代码。相同，你有监督过程来察看你的实现过程，并决定在失败的时候做些什么？这样做对嘛？
另外，这也让我想起了测试驱动开发取得的很多有价值办法中的一个。当我实际 TDD 的时候，我发现更偏向于思考代码应该如何失败。而且，我常常可能从新设计 API，使其不对谬误进行弥补，而是不容许谬误状态的存在。
作者对 Al Tenhundfeld 的回复:
你说的很乏味，因为整个文章都变成了关于软件故障的内容。我批准，在大多数状况下，用错误处理来净化你的代码只是一种节约。通常状况下，更好的做法是花工夫记录日志，这样当谬误产生的时候，你就晓得产生了什么，并且可能通过修复软件进行弥补，而不是让软件经验繁琐的操作来尝试自我修复。
