设计和维护好的软件就像一场与复杂性永无止境的斗争。任何足够大的应用程序的代码路径和组件都会迅速成长为令人眼花缭乱的组合爆炸，这绝非易事。当部署在Heroku和AWS等平台上时，单服务器Web应用程序成为分布式系统。现代浏览器模糊了客户端和服务器之间的界限。当简单的程序在多个CPU内核上运行时，它们就变成了复杂的协调问题。虽然测试驱动开发等实践和SOLID原则等指南可以帮助我们对问题建模并简化解决方案，但大多数软件应用程序都是复杂的系统，其中各个组件以意想不到的方式交互和组合。当软件系统中出现意外情况时，可能会产生严重的后果。幸运的是，软件开发人员可以利用另一个更古老的学科来处理复杂系统的关注、维护和调试：医学。鉴别诊断是医生用来将一系列症状与其可能原因相匹配的系统方法。良好的鉴别诊断包括以下4个步骤：列出所有观察到的症状。列出可能的原因。按优先顺序排列这些原因。测试按优先顺序进行以排除原因。虽然以上4个步骤是为医生整理的，但我们也可以像医生一样思考，以一种强有力的方式发现并消除软件缺陷。将诊断过程分解为单一目的的步骤可确保每个步骤都得到应有的关注。优先顺序是确保重点检查和务实干预。然后测试并排除假设以确保调试的严谨性。白板是个好东西当错误发生时，我们中的大多数人甚至都没有想过就立即调查最可能的原因。通过向后跟踪和一点背景知识，人性倾向于机会主义。但一个好的诊断从列出的症状开始，而不是原因。写下所有可以观察到的症状，不管是异常处理，还是错误代码，哪怕只是异常行为。可以使用文本编辑器或白板，但是，在诊断过程中的每个步骤做笔记很重要。将观察结果与假设分开有助于确保您不会排除或忽视潜在原因。大多数情况下，列出更多症状会缩小可能性，避免您浪费时间测试不正确的假设。写下症状列表后，您就可以开始思考原因了。斑马和马“当你听到蹄声时，你应该在寻找一匹马，而不是斑马。“代码错误在应用程序中比在Web框架中更容易出现，并且在Web框架中比在操作系统中更容易发现错误。当然，让其他人审查代码想法是个好主意，但事实是，大多数bug都非常无聊，所以在开始考虑推进到更复杂的问题之前，先给出最简单的解释。然后再一次，就像相同的症状可能完全不同一样，所以我们应该写下所有我们能想到的相关原因。就像我们过去直接用“什么”来描述症状，后来用“如何”来区分它们一样，头脑风暴法的目的是用“有多大可能”来区分“如何”.捕获任何合理的点以进行备用分析。最重要的是，无害。鉴别诊断不同于其他演绎方法，因为医生必须不断评估风险并权衡对患者的影响。对生活的影响。当然，如果我们的产品出现bug，虽然不会像医生的生命责任那么严重，但是停止维修是要付出实实在在的痛苦代价的。就像危及生命的疾病事件需要立即干预一样，严重的错误可能需要简单粗暴的修复，例如回滚和重启。在考虑权衡和判断决定是启动测试假设还是立即干预之前，对假设进行优先排序。像病人一样准备图表医院记录和其他背景信息都有图表，您的软件系统可能也需要图表。从日志和错误报告系统中收集信息来说明您的分析。至于系统指标和跟踪错误，您不妨将它们视为明智的预防药物。如果您的患者尚未处于严重危险之中，则从假设推论开始。从你定义的优先***假设开始，并一一证明它们是错误的。尽管支持证据有时可能会帮助您找到错误所在，但失败的测试会推动演绎过程。乍一看似乎有悖常理，但假设检验排除策略是追溯错误原因的最快方法。在许多情况下，一些简单的测试可以同时消除几个假设。当然，有时您必须执行更多测试才能反驳假设。实验室工作并不像医学界那样不可接受，如果愿意，您可以随时克隆软件应用程序并进行可怕的人体实验。如果你有足够的信息来触发你想要诊断的错误，它可以在一个受控的环境中被复制，比如一台有***数据库备份的计算机。暂存服务器。当您消除原因、收集新数据并改进假设时，错误真正原因的线索将变得更加清晰。清楚地思考复杂的系统需要细心和专注。使用结构化的诊断过程来指导检查可以节省时间和减少挫败感。最重要的是，它很有用。下次遇到bug，不妨试着把键盘放在一边，一步步把步骤写在白板上，像医生一样调试。翻译链接：http://www.codeceo.com/article/debug-like-doctor.html英文原文：Debuglikeadoctor译者：码农-王国峰
