前年闲的蛋疼的时候，看过天津卫视的一档节目《非你莫属》，就来一堆面试者，上面几个壕。选人。记得有一期是给程序猿做的。当中有一个程序猿（好像是媛）傻不啦叽的说，哎呀，我每次DEBUG找到程序BUG的时候。最开心了。然后一个BOSS。好呀，你好可爱啊，好喜欢敲代码啊，来我这儿吧。
我认为找个BUG有啥好开心的，这不是傻不啦叽是什么。
但事实是我发现，非常多人找BUG，或者说解决程序里缺陷的问题是十分欠缺的。
为什么解决这么简单的事情程序猿会认为这么难？并且以此为乐呢？而解决BUG。或者说DEBUG的本质是什么？
DEBUG：就是找到BUG，然后把它DE了，就是DEBUG。
DEBUG的第一步，也是最重要的一步就是找到BUG。而”找“不就是”find“，而”find“不就是”search“。”search“不就是”搜索“吗？所以DEBUG本质上就是搜索，搜索的目标就是你程序中的BUG。那么你DEBUG能力的强弱，DEBUG的速度、效率、精确度。全然取决于执行于你大脑中是否有明白的搜索算法，以及你当前搜索算法的好坏。
当你明白了，相信了，DEBUG的过程只是就是在你大脑里执行一个DEBUG算法的时候，事情就变得很easy。照着你的算法做就好了。
举几个DEBUG中常见的情况：
1. 曾经和人pair写代码，解决程序里bug的时候。发现有不少人debug时喜欢。这个文件看一看，那个文件看一看。东一下。西一下。这个就是在大脑里全然没有一个明白的搜索bug的算法。
这样的情况，搞了好久，可能最后还是能解决，但仅仅能说是”笨蠢萌“。
2. 和第一个样例恰恰相反。还有还有一种方式是，我就呆呆的在那儿较劲。憋，憋，憋，憋不住了。呀。不知道哪儿有问题。这也是不正确的。
2. 在遗留系统中。某些文件，某些类的代码上千行，这个时候，出现了bug，要解决问题。有人就一行一行的看，一行一行的加断点。
最后，经过好长时间以后，最终攻克了。当然也挺好的。可是。这个过程是什么？你做的事情事实上本质上就是算法复杂度为O(N)的查找算法。这样的方法比”笨蠢萌“好一点，属于”呆萌“的阶段。由于，众所周知，仅仅要使用了二分查找。算法复杂度就能到O(logN)，所以，假设你的代码是1000行。你在第500行加一个断点。看看第500行的时候有没有问题，假设有。那么就在0~500行之间找，假设没有，就在500~1000之间找。以此类推。这样。1000行的代码。理论上你的效率能够提升100倍（当然实际上没有那么夸张）。在以前的一个遗留项目里。以前有一个bug，一对pair找了两三天没照出来，我花了1~2个小时，就准确定位了问题（构建的时间比較长）。
这就是效率的提升，本质上，仅仅是採用了更好的搜索算法而已。Nothing New。
3. 有人抱怨，debug速度慢，是由于对于一些基础的东西没有了解。
比方说，对于一个新的第三方库不熟悉等等，假设熟悉了，就能够非常快的解决这个问题，完毕debug。那么，这个场景说明了什么。说明的是当你採用了启示式算法进行搜索，而你的启示式算法的启示函数，事实上就是你对于过往的基础知识的熟悉程度。
你越熟悉。你被启示的就越快，就越能更快的找到问题。你不熟悉，就仅仅能更慢。
最理想情况下，你对全部的事情了如指掌，你能够O(1)的时间发现问题。可是。即使知识不熟悉。不能全然的阻止你去发现问题，由于你至少能够O(logN)嘛。
上面举的样例，可以说明，debug和搜索算法的关系。所以，再啰嗦总结一下，我觉得正确的debug的方式就是明白你的bug搜索算法。估算它的效率。而且运行它。
好了，我们是不是每次都要採用O(logN)的方式debug呢？我们能不能做的更好呢？
我自己是很讨厌，以及歧视，以及厌恶，以及不屑，以及恶心断点debug的方式呢，断点debug的方式在大多数时候是让程序猿变得更笨的好方法。尽管在有些时候，也不得不手工debug。
那。how to play？
非常easy，自己主动化測试，通过写单元測试。集成測试，当我们出现故障的时候，这些測试能够有助于帮助我们缩小我们搜索的范围。当然。回归啊，乱七八糟的东西我也就不说了。
DEBUG，就是搜索BUG，让后把它DE了。
