程式設計師在編寫程式時往往由於邏輯不嚴密，演算法沒有最佳化，或要實現的邏輯太複雜，導致軟體或系統崩潰或出現異想不到的結果。解決這些Bug一般有這幾種方法：1.檢視程式碼，找出問題所在;2.依靠日誌檔案，找出問題所在;3.用DeBug除錯工具定位問題點;4.請高手幫忙。

我們的學員說：

開始是先自己找資料，國內的話就百度、CSDN，或者翻牆去谷歌，一般來說自己花半小時左右都沒解決的話，我就會問老師。

（文章：成都大資料開發培訓，提高班學員真實學習經驗分享

https://www.toutiao.com/i6603573520406413827/）

同理，程式設計師遇到技術難題，

如果網上找方法也不能自行解決，那就問技術大牛咯。

1.重現觸發步驟，如果重現不了的，要確定出現的範圍。

2.根據出現步驟或者範圍嘗試定位問題程式碼的大致範圍。

3.在程式碼裡設定斷點或者列印各種資訊輔助判斷，這一步是縮小問題程式碼範圍，實現精準定位。

4.判斷是資料錯誤還是程式碼錯誤。

5.程式碼問題透過一步步跟蹤，查詢問題所在

6.如果無法確定問題，這個時候可以百度問題程式碼。

切記，不論什麼問題不要一開始就是百度，那樣也許解決會快很多，但是自己不會有成長。

跟大夥分享一個壓箱底的故事吧。

你打開了銀行的網頁，輸入賬號和密碼，結果你看到的是另一個人的帳戶。開發的網站上線一年多之後就出了這樣的問題。使用者用相機照了一張照片發到了公司。十萬火急，公司第一時間關閉了網站，緊接著全員出動，挨個給使用者打電話，通知他們網站出故障了。而我也立即開始著手調查該使用者的使用記錄，確認他的每一步操作。經分析這名使用者非常老實，發現問題後，沒有任何多餘的操作，直接就退出去了。公司感激不盡，給了他一大筆封口費。

我的任務是找出上線一年多的時間裡出現過的所有類似問題。這可是一個體力活，我得檢視一年多的時間裡攢下來的以百萬計數的日誌。寫指令碼，做統計，分析資料，加班加點忙得不亦樂乎。總算是論據充分的證明了在這一年多以來只出了這一次錯誤。BUG的原因也找到了是因為有一處記憶體洩漏造成的。事情似乎圓滿解決了。

但接下來卻遇到了一個頭痛的問題，公司領導要求我提供能證明網站不會再出現類似問題的證據。否則，不準重新上線。為了證明幾十萬行程式碼中一處記憶體洩漏都沒有。我反覆檢查程式碼，連續測試，能用的手段都用了。其實，我也知道這些都不能證明問題已經解決，只盼能用苦勞打動領導放我一馬。可是領導真的是鐵石心腸，儘管我已是疲憊不堪他卻不為所動。

我已是走投無路，欲哭無淚。一個前輩悄悄地走過來詭異地衝著我笑了。我以為他是幸災樂禍的。一時悲憤交加，正要發作。他卻神秘兮兮地壓低聲音對我說，”檢錯報警”。我詫異地看了他半天才反應過來，他是來救我的。

前輩的辦法很簡單，寫一個外部程式，監視使用者的每一次操作，一旦發現錯誤，立刻關閉網站，開啟警報。為了烘托效果，我設計了一個很誇張的外接報警燈。演示的時候，黃色的大燈發出刺眼的閃光還伴有尖利的警笛。領導果然很滿意。還賞了我一臺膝上型電腦和上網絡卡，要我24小時待機，隨時準備應對突發狀況。

後來呢，沒有後來了，因為那盞燈從來沒有亮起。