一轉眼，半年過去了，半年前，還是一個連http請求，handler怎么用都不太會的標準菜鳥（當然，現在也是菜鳥）。

才來公司的時候，老大交給我一個老項目讓我改bug。那一改就是3個月，三個月的時間，邊開發新功能，變修復原有bug。說實話，一來就是一個class有上千行代碼，一個包幾十個類的項目，看著都頭疼。連出現bug的位置都要找半天。具體哪些bug，已經不太記得了，只是把一些經驗性的東西，總結出來分享。

改bug的幾個階段（場景），我來聊聊吧（也是自己改bug的階段，每個階段改的方式，方向可能都有 不同）：

第一個階段：最基礎的階段，看日志。這種，就是那種錯誤明顯的，直接點日志，跳到對應位置那種。比如空指針，改的方法就是看哪個值為空了，再看看這個類，什么時候賦值了呀什么的。修改難度，應該算最小的。

第二個階段（場景）：也有日志，但是，你點擊日志跳到對應位置，發現（臥槽，這代碼不是我寫的，是Android自己寫的），然后，就糾結，這tm什么問題呀，都不是我寫的，怎么搞呀。經過一番思來想去之后，決定，百度一下吧，把這段錯誤信息放到網上一查，誒，有結果了。然后按照網上說的那樣，改改改，行了。

第三個階段（場景）：還是有日志，但是，沒有可以點擊的日志，全是一啪啦英文，靠，這什么鬼，完全沒思路呀。然后，又是糾結，沉思，最后實在沒辦法了，讀日志吧，一句句讀，最后終于讀懂什么意思了，然后，又把錯誤內容加上自己的理解百度一下，再不行就在it群里面問，最后，也解決了。

第四個階段（場景）：我×，沒有報錯，沒有蹦，沒有日志，這tm怎么就跟我想的不一樣呀。這個時候，只能去讀代碼了，看自己這個模塊的代碼是哪些，哪一步是應該顯示我那個正確結果的，然后，一步一步往上推，看數據從哪里來，走了哪些步奏，看view哪里創建，又在哪里顯示。然后打斷點，單步調試，最后發現，原來是這一步沒有傳值（或者取值錯了什么的）。

第五個階段（場景）：這類場景比較復雜了，這類場景就是，我一個類很大（幾千行代碼那種），然后，引用了10幾個類（可能更多）。在這個類里面某句話出了問題，或是怎么樣。這種情況千萬不要，一上去，就改，因為，很有可能（反正，我是百分之百）會這個bug改了，又出現新的bug了。這種情況最正確的做法是，先把這部分內容讀懂，弄明白是干什么的，最好是能重構一下。讓整體結構和思路變清晰，然后，再去找問題的根源。

第六個階段（我現在的階段）：基本問題，秒改，復雜問題，先重構再改。

ok，最后總結一些經驗性的話吧，遇到問題的幾個處理步奏：1找現場，還原現場。2向上溯源，向下延伸。3累積

第一點：找現場，還原現場。說的是。先找到這個問題，這個場景，出現的地方（包，類，代碼塊），其實就和警察辦案一樣，先到案發現場找線索，因為案發之后一定會留下蛛絲馬跡。然后，就是還原現場，就是把這個問題復現，就想警察會還原案發現場一樣，幫助推理，和理清線索。

第二點：向上溯源，向下延伸：找到現場之后，分析這個問題，數據源是哪里，傳來的數據是什么，向下延伸，是指，考慮這個對象，對他后續的對象（比如誰引用了他）有什么影響。簡單來說，就是。向上溯源，是為了解決當前這個問題，向下延伸，是規避制造新的bug。也可以換一種說法，叫依賴。相信搞java的同學對這個詞理解應該會很深。

第三點：累積，其實就是累積經驗，我現在之所以能秒改一些問題，就是因為，曾經一天要改10幾個bug，改了3個月。見都見了很多bug了，看著就不陌生了，就好辦了。所以，遇到bug，不要著急，改一個，就進步一點。

還有千萬不要以為改bug，不如寫項目。這么說吧，我改的bug，比我寫的項目還多（真是多虧了之前的哥們，給我留了那么多bug，別讓我遇到，遇到打死）。改著改著，就發現，這樣寫容易產生bug，該怎樣怎樣寫，才能避免bug。比如一個eventbus，容易忘記反注冊。后來，就寫了一個生命周期框架，讓activity自己去管理，我不管了。比如一些規則驗證不寫容易出現奇葩bug，然后就寫了一個規則驗證的api，用著很爽。也是多虧了之前累積的bug，這次我寫的項目，大家都加班了，就我幾乎沒加班，然后寫出來之后，基本上沒什么bug，測試也通過主流程，只是改一些小細節了。所以才有這時間寫這篇文章。

最后分享一點，作為一個程序員（雖然我現在，已經在漸漸負責框架，架構方面的設計），編碼才是硬本事，寫出來的代碼bug越少，代碼越少，性能越高，擴展性越好才是能證明你的水平。別一來就是xx模式，xx架構，xx框架的。