bug對於我們開發者來說， 應該不陌生， 雖然我們經歷的大部分bug有的被其他人修復了並且在互聯網分享出來了， 這時候我們通過Stackoverflow、Baidu、Google等搜尋引擎找到答案了。
但是我們在工作中也可能會遇到一些疑難的bug， 這裡bug我們在搜素引擎上找不到解決方案， 可能好幾天都不得其解。 譬如我們bug無法重現， 這兩天我就遇到了一個客戶回饋的bug， 因Bug重新不了， 定位不到問題， 遲遲沒有解決而搞得人焦頭爛額。
簡單描述這個bug：
同一款類型手機， 系統版本高點的手機正常， 其他手機也沒有重現。 單獨客戶的那款類型的手機出現問題。
剛開始懷疑是該類型手機的自身的應用鎖功能導致的， 後來客戶回饋不是， 只有我們這個應用會， 在他那款手機其他的應用程式不會出現類似問題。
最後重現問題的方法。 因為之前給過客戶兩個不同安裝包， 雖然是兩個不同安裝包， 但兩個包改動不大。
於是乎， 試著卸載手頭的手機的最新應用程式， 先安裝舊的安裝包， 再安裝新的安裝包， 神奇的bug重現了。
兩天解決一個bug引起的真實感想
2通過解決這個bug,讓我明白了， 對於用戶回饋的bug， 我們開發者要儘量從自身找問題， 冷靜分析問題。
實在不知如何下手， 請求隊友們幫忙， 別人的一句無意的話， 可能能幫助你解決問題， 盡可能少的否認問題的存在。
程式師那些事
換一種思路， 可能就豁然開朗了
回歸問題場景,事件順序
事件是否可以以一種不同的順序到達？譬如我這個bug重現不了， 我就是按照這個方法來重現的， 按照用戶的用戶行為去重現問題。 先安裝舊的安裝包， 再安裝新的安裝包。
重視使用者提供的日誌
調試某個bug花很長時間時， 常常是由於我做了錯誤的假設。 使用者提供的日誌很重要， 看一次定位不到問題， 沒有頭緒的情況下， 多看幾次， 剛開始我以為出現這個bug， 是使用者對我們這個應用程式燒寫不全導致。
相信用戶
不要認為用戶是傻逼， 因為如果你這樣認為的話，
有時候對於用戶提供報告問題時， 我們的本能反應很可能是“這不可能。 用戶肯定是哪裡弄錯了。 ”
通過這個bug， 我已學會了擯棄這樣的反應。 結果往往證明， 用戶報告的正是實際發生的問題。 所以從現在起， 我對用戶報告的問題信以為真。
近期代碼的變化
要注意近期代碼的改動， 我們通過代碼管理工具都能清楚的看到， 每處代碼的改動的都不要輕易否認。
複現， 找到穩定複現的辦法
抽特徵， 對BUG發生的條件進行抽取
減特徵， 替換掉一部分發生的外部條件， 看BUG是否發生
流程分析， 對BUG對應的流程進行徹底的分析，
作為一名軟體發展人員， 經常避免不了的就是發現各種BUG， 既然BUG是避免不了的， 那麼， 作為一個程式師， 如何減少我們寫的代碼bug。
1、養成一種好習慣， 注釋
曾有網友倜儻：程式師喜歡兩件事：
喜歡說別人程式不寫注釋；
喜歡自己在程式中不加注釋。
注釋的目的不是為了解釋代碼做什麼——可以讀取代碼!注釋目的是為了解釋當你寫代碼的時候是如何思考的。
在寫完代碼的後面兩三個月， 可能我們已經不記得上述任何問題的答案， 所以， 要寫下來。 這是無價的， 為我們後面解決bug提供了重要的線索。
認真記錄bug
2、測試優先
我們可以編寫測試的代碼以確保其他代碼可正常工作。
3、程式是寫給別人看的，平時要多注意代碼規範。
比如變數命名，方法命名等。
4、不拋棄，不放棄
如今軟體日新月異地變化和發展。人的精力畢竟有限，我們不可能掌握所有。事實上，當我們準備放棄的那一刻，我們依然沒有資格說我們已經懂得夠多。只有不斷學習，不斷拓寬你的視野，才能提高我們的競爭力。防守是最好的進攻。
認真記錄bug
2、測試優先
我們可以編寫測試的代碼以確保其他代碼可正常工作。
3、程式是寫給別人看的，平時要多注意代碼規範。
比如變數命名，方法命名等。
4、不拋棄，不放棄
如今軟體日新月異地變化和發展。人的精力畢竟有限，我們不可能掌握所有。事實上，當我們準備放棄的那一刻，我們依然沒有資格說我們已經懂得夠多。只有不斷學習，不斷拓寬你的視野，才能提高我們的競爭力。防守是最好的進攻。