简短的激励性指南，用于调试可怕的生产问题。
您的任务是找到一个导致生产系统丑陋的错误。
您已经盯着键盘看了几个小时，对自己是否适合软件工程职业的疑问越来越多。 您已经绘制了一个完整的空白。
你觉得自己像个骗子， 冒名顶替者 。
放松一下 您不是冒充者-错误是。
多年以来，它一直很高兴地扮演着系统正常运行的一部分，但现在您走上正轨去寻找这种伪造，这种欺诈， 这种冒名顶替者 ，而且您不会屈服。
那你会从哪里开始？
重现该问题。
至少，您必须能够解决问题并自信地重现它。
一次又一次…
…然后再次。
没有实现这一非常简单的步骤，您将无法测试所引入的更改是否产生了任何形式的影响，也无法从系统中获得重要线索。 您甚至无法最终向其他人证明问题已解决。
在您可以控制的环境中重现该问题。
这样您可以重现该问题？ 这是一个好的开始。 但是，如果您只能在生产中重现问题，那么您将无法使用缩小问题根源的方法。
希望您所处的组织处于一个类似于生产的暂存，UAT，预生产或测试环境。
利用它来发挥自己的优势，并尝试在那里重现您的问题。 能够做到这一点将开辟出许多潜在的方法，您可以使用它们来获得更多的可见性和对问题的控制，而您却没有生产中的奢侈，或者至少没有如此迅速地实现奢侈。
以下是一些示例：
- 提高应用程序的日志记录级别
- 远程调试应用程序
- 能够在常规质量门外发布对应用程序代码的修改，以快速试用更改*
- 暂停或终止相邻进程以确定事件流
*-我认为，仅应在紧急情况下使用此方法，并且应始终清除所有混乱情况。
了解系统。
只要发现问题，就无法立即使用自己认为知道的系统来解决-您需要面对事实，您对系统的了解不如您想像的那样。
退后一步，尝试在较高层次上绘制系统。 在您正在研究的特定场景中，逐渐并持续地将注意力集中在最有可能成为罪魁祸首的部分上。
简化问题。
以您正在处理的问题为重点，而不是直接专注于解决问题，而应设法降低复杂性并减少可动部件的数量，从而牢记在心。
我们是脆弱，多肉的人， 其存储和处理信息的能力有限 。 使问题更易消化。
在生产系统中，通过简单且不可辩驳的测试，消除可能导致功能障碍的组件和行为。
最终，您将面临一个更小，更简单的问题，需要研究和理解—如果继续这样做， 最终将找到解决方案 。
错误不能自行消失！
…哦，请不要与这种常见的逻辑谬误相抵触：
我可以在20分钟前重现它，但我什么都没改变，但似乎已经消失了……也许永远消失了！
如果有人发现了一个错误，则您没有做任何更改，并且在某个时候您无法重现它， 它将再次发生。
隔离更改。
如果进行更改以验证理论或引入潜在的解决方法，则如果更改无效，则应立即回滚更改。
不要在无效更改的基础上添加一个更改。 您介绍的内容起初可能没有任何效果，但是如果添加更多更改，最终将导致更复杂，更麻烦的问题需要解决。
更糟糕的是，您可能会错误地将行为更改归因于您引入的无关更改。 不要做！ 使您的更改保持隔离状态，并测试每个更改。
橡皮鸭调试。
尽管有时可能会感觉很像，但对于您遇到的问题寻求帮助绝对不会感到羞耻。
练习橡皮鸭调试 -向另一个人解释您当前的问题的行为-甚至是无生命的物体，使您可以收集自己的想法并重新获得关注。
有时，您尚未解决问题的原因恰恰是因为您专注于该问题的时间过长，并且掉进了兔子洞。
记录所有您已经尝试过的内容。
在高风险的复杂场景中，很容易失去对解决问题已经做的事情的跟踪。 您可能最终不知不觉地回过头去踩了旧地。 只需记录您到目前为止和进行中的所有工作即可。
我已经尝试了所有方法，但仍然遇到问题！
你真的没有 可以做一些事情来突出问题的根源。
您可能太接近问题了，您可能永远无法自己想到解决方案。 但是您必须绝对接受可以做些什么来突出问题所在，因为您尚未找到问题，而您的工作就是找到问题。
不要放弃
了解新的调试技术。
调试不仅是设置断点并希望达到最佳效果。 有很多技术可以学习。 其中一种值得关注的技术（尽管还有 许多其他技术 ）是使用条件断点 ：
与断点一样，您可能会导致程序的执行停止—但对于条件断点，这仅在满足特定条件的情况下才会发生。
这确实可以帮助节省大量时间来追踪难以捉摸的错误，因为当程序冻结时，您知道它是在您认为重要的条件下发生的。
并非总是有解决问题的明确方法。
有时候你必须要有创造力...
最重要的是，请定期休息。
解决棘手的生产错误可能会很艰难，甚至会消耗很多精力。
散步，喝一杯，离开办公桌。 现在做。
有时，潜意识中的思维带动方向盘并进行一些脱机处理可能会有所作为，而您却会分散其他注意力。
如果幸运的话，您可能会在...
您已经解决了！…
但这还没有结束。
您确定解决了吗？
测试并重新测试您的修复程序。 恢复为原始配置，然后运行复制步骤。 确认错误存在。 应用所做的更改，然后再次运行复制步骤。 确认错误已消失。
再来一遍。
…您现在真的确定吗？
在经历了所有痛苦和磨难之后 ，您很容易忘记非常简单的确认步骤。 不要让自己更加心痛-在宣布问题已解决之前，对您的解决方案充满信心。
…哦，您现在绝对应该编写一些测试。
在生产环境中发现的错误仅意味着您的应用程序测试套件的一件事：它不够好，因为尚未尽早发现该错误。
现在利用这个机会编写一些测试以练习该代码区域，以便其他人不必再经历刚刚遭受的痛苦 。
…至少要等到出现其他错误为止 ！
希望您喜欢它，并且对您有所帮助。 如果您有任何反馈意见，我将不胜感激。
感谢您阅读????！
From: https://hackernoon.com/catch-me-if-you-can-a-guide-to-debugging-f4af08f6724d