前年闲的蛋疼的时候，看过天津卫视的一档节目《非你莫属》，就来一堆面试者，上面几个壕，选人。记得有一期是给程序员做的，其中有一个程序员（好像是媛）傻不啦叽的说，哎呀，我每次DEBUG找到程序BUG的时候，最开心了。然后一个BOSS，好呀，你好可爱啊，好喜欢写程序啊，来我这儿吧。
我觉得找个BUG有啥好开心的，这不是傻不啦叽是什么。但事实是我发现，很多人找BUG，或者说解决程序里缺陷的问题是十分欠缺的。
为什么解决这么简单的事情程序员会觉得这么难？而且以此为乐呢？而解决BUG，或者说DEBUG的本质是什么？
DEBUG：就是找到BUG，然后把它DE了，就是DEBUG。
DEBUG的第一步，也是最重要的一步就是找到BUG。而”找“不就是”find“，而”find“不就是”search“，”search“不就是”搜索“吗？所以DEBUG本质上就是搜索，搜索的目标就是你程序中的BUG。那么你DEBUG能力的强弱，DEBUG的速度、效率、准确度，完全取决于运行于你大脑中是否有明确的搜索算法，以及你当前搜索算法的好坏。
当你明确了，相信了，DEBUG的过程不过就是在你大脑里运行一个DEBUG算法的时候，事情就变得非常简单，照着你的算法做就好了。
举几个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？
很简单，自动化测试，通过写单元测试，集成测试，当我们出现问题的时候，这些测试可以有助于帮助我们缩小我们搜索的范围。当然，回归啊，乱七八糟的东西我也就不说了。
DEBUG，就是搜索BUG，让后把它DE了。