Bug猜想（二）

想到一则故事：

魏文王问扁鹊曰：「子昆弟三人其孰最善为医？」扁鹊曰：「长兄最善，中兄次之，扁鹊最为下。」魏文侯曰：「可得闻邪？」扁鹊曰：「长兄於病视神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於闾。若扁鹊者，鑱血脉，投毒药，副肌肤，闲而名出闻於诸侯。」

Bug也是一种病，要怎么办呢？

感冒虽小，但是还可以分为外感风寒、外感风热、外感暑湿三种。不是说感冒了，吃个感冒胶囊就一定能好的。对症下药，才能药到病除。当然下错了药，感冒这样的小病也许也能好，毕竟不吃药都有可能会好的。改Bug，我感觉就像治病一样，得改对地方。不过有一点是不一样的：Bug不改，就是永远的痛，它不会自己好的。偶尔会听到有的Bug有时出现，然后又没了，让人“开心”。我相信，没了并不是好了，只是召唤它的条件还不够，还差一颗龙珠。

三等“医师”：Bug出现了！找到Bug在哪里了！修复。找Bug是头等大事。

刚刚开始学习编程的时候，各种错误，就去学习了调试。崩溃的时候调试最简单了，看下哪里崩溃了就好了，可能是空指针、数组越界、变量没有赋初值等等。后来写算法的时候，发现调试没有那么简单。写个排序算法，排序结果是错误的，这时候的就要“逐语句”调试。“逐语句”的前提是你要了解每一步，你要知道每一步运行下去哪里会被影响到，现在的结果是不是预期的，如果不是又是哪里造成的。不了解，做不到这些，我觉得应该很难找到Bug。像医生一样了解我们的“病人”，才能治好病。

去了上一家公司发现“调试”也不是万能的，因为有时候你没有机会调试。项目涉及的东西比较多，不但是多个系统之间相互协作的，而且还因为安全性的原因，运行的条件比较多，在开发的机器上面根本运行不起来。终于发现了log的重要性。

我认为Log本质上和调试时一样的，都可以让我们看到系统运行到某一步时候的各种状态。不同的是Log是系统运行时的数据、状态有选择的记录下来。有选择就会变得有困难。多系统之间的相互协作、模块间的相互调用、硬件的使用、加载配置等等。。。。。。When、Where、What都可以体现出一个人的实力。好的Log可以一目了然告我我们系统发生了什么，哪里出错了。在上一家公司，前面也说了系统比较复杂，发现了一个Bug，辛辛苦苦半天结果发现是其它系统的原因，仅仅这样还不够，还要给出证明才行，谁叫我们是第三方公司呢。这时候Log的作用就来了，出了Bug，看下日志，是不是我们自己的问题，如果是别人的问题，还可以提供个证明什么的。

找到根源，再干掉他！