前年閒的蛋疼的時候，看過天津衛視的一檔節目《非你莫屬》，就來一堆面試者，上面幾個壕，選人。記得有一期是給程序員做的，其中有一個程序員（好像是媛）傻不啦嘰的說，哎呀，我每次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了。