最近開發一個對於公司來說具有重要戰略意義的app項目，我底下帶了Android, iOS, 前端開發，後臺開發的技術團隊。項目進度很緊，人手不夠，不斷的小腳步迭代，快速前進。
衆所周知，對於軟件行業，只要是開發工作，永遠都避免不了有bug的存在，有bug並不可怕，就怕你在代碼的海洋中毫無方向的摸索，那簡直就是噩夢！而我在帶團隊的過程中，常常發現屬下經常面對稍微困難一點的bug時都無所適從，不知道從哪裏下手，有的時候，問題居然就是出在少了一個括號，符號，逗號等等，而找我debug的時候卻已經struggle了大半天了，非常傷腦筋，並且這種bug往往還不容易被發現。每次這個時候都會來找我，基本上無論多麼複雜的bug，到我這裏都能快速得到解決，枯木逢春！這並不是我運氣好，而是在長達15年的軟件開發經驗過程中，我早已摸索了一套debug問題的方法論，只要按照這個步驟來，基本上就能快速定位問題具體出現在代碼的哪一行，讓bug原形畢露！因此，在遇到bug的時候，基本上能從容不迫。
我意識到，團隊成員幾乎沒有一套方法來解決bug，而是完全憑着感覺在debug，這樣運氣的成分就非常大，不能從容不迫的解決問題，因此每次遇到bug的時候都心裏沒底，並且找到我的時候往往已經浪費了大量時間，在項目進度很緊的情況下，這是很揪心的一件事。所以，我專門針對整個團隊做了一次如何debug問題的技術培訓，經驗證，下屬後來很少再來“打擾”我了。
由於遇到bug一個常態，所以能夠快速發現和fix bug是一個非常重要的工作技能，因爲它不僅能提高你的工作效率，而且，將來媽媽再也不用擔心我碰到“bug”了不是。因此，對於所有軟件從業者來說，能夠掌握這樣一種方法是非常有意義的。這裏，我就拋磚引玉，和大家分享一下，如果有什麼好的意見，也請大家給我留言。
必要前提：
1. 你必須對你的代碼工作/業務流程很熟悉，這個很容易理解，否則就成爲無源之本。
2. bug必須能夠重現，否則只能靠猜。所以在debug之前，必須確認這個bug能夠通過某個步驟，每次都能夠exactly發生。
好了，有了以上2個前提，下面在說說如何一步步debug：
1. 根據場景，你一定知道在代碼都經過了哪些主分支。那麼首先在大概出現問題上下游的主分支入口處(第一行代碼處)加上log。
2. 重現bug，看log在哪2句之間出現了bug。
3. 在這2個log之間的分支處添加log，繼續重現bug，週而復始，很快就能夠把bug出現的地方夾逼到某一行。
4. 這個時候可以通過設置斷點，重run代碼，然後在此行附近觀察變量的值是否符合預期，一般來說，會迅速找到問題所在，比如某個變量的值不對。這個時候一個線索就找到了，然後就可以逆流而上，看爲什麼不對，這個可以看這個值是什麼時候賦值的，爲什麼賦值不對，一步步逼近原因的真相。
5. 找出root cause，fix bug，然後一定再重新run一次，測試bug是否已經fix！
基本上，根據步驟1-5都能夠解決90%的bug。但是世事無絕對，凡事都有例外，就像真假美猴王裏的六耳獼猴，在無界之外。比如OOM內存泄露，閃退等問題，是不能用常規手段來發現問題的，只能通過統計學的方法，和經驗來發現，比如MAT分析，sysTrace, timeTrace等專業分析工具。當然前提也是必須能夠不斷重現，然後
找出root cause，fix bug，測試！
如果還是不能解決的話，這個時候就要用到工作中的soft skill了：
1. 上網搜尋找類似問題，反編譯模仿等。
2. 尋求其他人的幫助
3. 最後一步，舉旗，不要把球抱在自己懷中
這樣，通過不斷的escalate，把問題充分暴露出來，而不至於一個bug讓你停滯不前，耗費大量的時間。
當然以上方法和你自身的技術水平是相關的，水平高的能夠快速定位，而水平一般的可能會用更多的時間。但是，總而言之，它能夠讓你固定的套路，以不變應萬變，一步步逼近事情的真相！再多說一句，任何技術上的問題，都應該以量化的辦法來解決，千萬不要憑感覺，猜，靠經驗等等。只有用數據說話，纔是最科學的解決辦法。因爲，我發現有些5年以上工作經驗的開發者，依然會靠一些經驗來解決問題，但是問他怎麼解決的時候拿不出數據，只能說憑感覺，經驗，這些都是不專業的態度和精神。
希望對大家有用。