今天继续聊debug。通常情况下，我们的项目会用到很多第三方的产品（数据库、框架、中间件、SDK）。程序也运行下特定的环境下（操作系统、命令库、编译器）。当程序出问题的时候，这些第三方产品和环境出问题也是有可能的，但它不应该是第一个考虑的方向。
作者也特意讲到一个故事，说他们的程序有一次出了问题，然后一个高级工程师就坚信是Unix的select命令出了问题。大家从各方面劝都没有把他劝服。然后他花了几个星期的时间来写变通的方案，出于一些奇怪的原因，他的方案并没有起作用。
于是，他不得不静下心来阅读select的文档，然后发现了问题所在，几分钟之后问题就解决了。所以，之后作者就用“select”没有坏，来提醒自己，不要首先怀疑其他人的问题，先考虑自己的问题。
我也遇到过类似的问题，有一次在请求ebay接口的时候，它的accesstoken不到5分钟就失效了。但根据文档的说明，它的有效期应该有2个小时才对。但是，代码已经很久没有动过了，不大可能是代码的问题。于是，我们想当然地认为是ebay那边出了问题。
但后来发现，可能是数据库那台服务器中了病毒，accesstoken那个字段的值，没过几分钟就会自己多出几个字符，导致token失效。
后来，临时弄了一个数据库，使用这个新的数据库，问题就不再出现了。
虽然这一次确实也是第三方的产品（数据库）出现了问题，但说到底还是我们自己的问题，因为运维水平不够，导致服务器的安全等级太低。
所以，不要轻易地怀疑第三方的产品，特别是大范围公开的产品。如果出了问题，大概率是自己的使用不当。倘若真的是产品本身出了问题，我们大概率会收到通知，或看到新闻。不至于毫无音讯，毕竟是一个很多人使用的产品。
但，同时，不要轻易怀疑，不代表不用怀疑。一个运行了很多年，都没有出问题的代码，不代表它就不可能有bug。就像上面我的那个例子，正常情况谁也不会想到某个数据行会自己改变。这个问题的发现，也不是因为我对这件事，产生了怀疑。只不过是想对比一下，两次请求的token是不是一模一样。然后无意间发现的问题。
所以，不要假设某个东西一定没有问题。虽然怀疑所有地方，不是一件优先级很高的事情。但到了不得已的时候，也不得不怀疑一下。通过测试来证明它真的没问题，才是真的没问题。
不要假设，要证明。最后，如果你改变了一个地方，导致了程序出错。
不论你改的地方是什么，无论它和错误之间的关系显得多么的薄弱。无论这个理由显得多么地离谱。它都一定是你的第一怀疑对象。最后的最后，问题解决后，事情并没有完全结束。还有两件事要做。其一，想一想这个地方的错误，可能还会影响到哪里，一并解决了。不要偷懒，现在不解决，迟早也要解决的。到那个时候，可能会更麻烦。其二，思考一下，有没有什么办法可以防止它再次发生。至少，增加检测手段，当它再次发生的时候，你能够第一时间知道。
今天，就是debug这个话题的收官了，希望你也能有启发。字数：986
耗时：1小时20分
··················END··················
