作者說，找bug的第一件事，就是確定程序被正確地編譯，正確地運行。
把編譯警告等級調得越高越好。因為沒有必要在計算機可以幫我們找到問題的地方浪費時間。
我也確實遇到過類似的情況，代碼怎麼看，怎麼沒問題，但是就是運行報錯，結果重新編譯一遍，就什麼事情就沒有了。
所以，不妨把重新編譯當作debug的第一步。
第二步，就是要仔細觀察。因為報錯信息有的時候，並不是那麼地準確，在這一行報錯，可能是其他地方出了問題，也是常有的事。
所以，很多時候，也會被報錯給誤導，耽誤很多時間。
特別是當報錯來自第三方，比如第三方的服務，或者用戶報告的錯誤。那相關的信息就更少了。
作者有特別提到，如果是用戶提供的bug，有可能的話，一定要向用戶了解他具體的操作。
用戶一用就錯，我們怎麼測都測不出來。這樣的事情，我也是遇到過的。
通常源自兩種原因，其一，用戶的操作有問題，漏了關鍵步驟，或者填入了錯誤的數據。
其二，用戶測出了很隱蔽的bug，但我們自己知道我們的程序邏輯，會傾向於正確地使用程序，所以很難測出用戶遇到的問題。
我之前在教同學python的時候，也遇到過，他說他得到的結果總是不對，但是按照我說的，不大可能出現他遇到的問題。
於是，我給他發了一個錄屏軟體，讓他把操作錄下來，發給我，結果發現，他輸錯了命令，但不自知。
像這種情況，如果能夠讓用戶提供具體的操作步驟，就可以大大地降低解決bug的時間。
最後，在正式找bug之前，還有最後一件事要做，那就是復現bug。
只有穩定復現的bug才好處理。所以，要想辦法，讓bug穩定地復現。它只要能出現一次，就肯定能再出現第二次，找到它。
作者有特意提到一點，就是想辦法讓bug的復現自動化。
有的時候，bug出現在第15步，但是前面的14步，你每次測試的時候，都要手動來一遍，想想都是一件令人崩潰的事情。
所以，想辦法讓bug復現自動化，可以提供效率，也可以安撫情緒。
今天就先聊這些正式dubug之前的內容吧。
字數：677
耗時：1小時20分
··················END··················