不记录，等于没读。
这里是我阅读《程序员修炼之道》这本书的记录。
软件缺陷以各种方式表现出来，从对需求的误解到编码错误。现在的计算机系统仍有局限性，能干你让它干 的事情，但不一定能干你想让它干的事情。本章介绍调试中涉及的问题，以及一些通用策略。
调试心理学
接受这样一个事实：调试只是在解决问题，并为此全力以赴 。不要费时费力地把责任推到罪魁祸首身上，在技术领域，我们把精力集中在解决问题上，而不是归咎于他人。
去解决问题，而不是责备。
调试心态
调试的首要法则是不要恐慌。开始调试之前，正确的心态非常重要。要冷静，不要受到最后期限、上级的关注等影响，仔细的观察，认真的思考。
如果你看到 BUG 的第一反应是"这不可能"，那你就大错特错了。因为很明显它会发生，而且已经发生了。此时，你必须重新评估你一直笃信的真理：你有什么东西不知道，或者理解错了。
要注意不要浮于表面，永远去发掘问题的根本原因。
从哪里开始
当你试图解决任何问题时，需要收集所有相关的数据。首先需要观察上更准确。
调试策略
手动修改 BUG 前，首先要能重现 BUG。如果你不能重现它，就不能确定究竟是否修复了 BUG。
首先，看一眼问题。很多开发者一看见红色的异常弹出框，就立马切去看代码，不要这样。在此之前，读一下出错信息。
把纸笔放在旁边会很有帮助，这样可以随时做笔记。特别是无意中发现一个线索，一番验证后发现不是这个问题时，如果之前没有记下从哪里开始的，可能会在找回源头上浪费很多时间。
使用 二分法 缩小问题的范围。比如一开始要是能确定是软件问题还是硬件问题，那么问题的可能性就能排除一半。
利用 调试器 观察程序当前的状态。
在程序设计的最开始，就考虑程序的 显见性 。优先编写能监视和显示内部状态的代码 ，用这些代码来充当我们的耳朵和眼睛，帮助我们回答那里有什么？发生了什么？
比如输出日志或跟踪信息。当时间本身就是一个影响因子时，比如并发进程、实时系统和基于事件的应用程序，跟踪都是不可或缺的。
跟踪消息应该采用规范一致的格式，因为有可能需要自动对其解析。
排除法：如果你只改变了一个东西，然后系统就不工作了，那么这个东西就最可能直接或间接的负有责任，不管看起来多么牵强。
如果你面对一个"让人吃惊"的错误时，必须接受之前的一个或多个假设是错误的。同时要牢记：不要只是假设，要证明。
在《程序员修炼之道 06：基础工具》这篇文章中，我提到过自2018年开始，我会在一个专门的笔记本上记录我遇到的 BUG，包括 BUG 的现象、调试的过程，问题的根源，从中得到的教训，如何避免等。到现在为止，已经记录了两大本的素材，因此我自己也有一些调试心得，总的来说，调试有 4 个步骤，分别是：
- 重现 BUG
当你发现一个 BUG 时应该怎么办？让它再次发生! - 观察现象
不要想，而要看。 - 提出假设
有时候觉得离奇，只是因为眼界不够。 - 验证假设
对于提出的每一个假设，用实验去证实或者证伪，然后记录下来。
任何的 BUG ，都可以通过这些步骤来解决！它就像一个巨大的推土机。虽然可能行动缓慢、工作起来枯燥乏味，但一路上无论遇到什么障碍，它都能铲平。关于这 4 个步骤的具体内容可以参考我的博文《随想005：调试的思考》，这里不再赘述。
每一份打赏，都是对创作者劳动的肯定与回报。 ！
