程式設計師在工作中耗時較長的就是閱讀（自己寫的或者別人寫的）程式碼，如果用心肯定是能學到東西的。寫的好的可以借鑑，留心一下，下次處理類似的情況就有了參考。

有bug的地方不妨多想想看為什麼這裡出了問題，是單純的因為粗心？還是因為某個函式的用法沒有搞明白，還是沒有完全理解功能需求等等……等到自己寫程式碼實現某個功能的時候，多注意這些問題，這不就提升了嘛！

修復每個bug後都要問這3個問題

其實每一個bug都是底層程序的一個不良表現。

你必須處理這些症狀，但如果你僅僅是處理這些外在症狀，你就會有永遠解決不完的問題。

你應該找到產生bug的程序，並且修復這個程序。當你確定究竟發生了什麼和發生這些的原因時，也許你就會明白產生bug的基礎程序不是隨機的，而是可控的。

在問這三個問題前，你需要克服面對bug的這種天生的抗拒，仔細分析bug。檢視程式碼並解釋出錯的原因，從能觀察到的現象開始，向後分析，不斷地問為什麼，直到你可以找到產生bug的模式。

“它溢位了，因為下標J越界了。” “為什麼？” “J 是 10，但陣列最大下標為 9。” “為什麼？” “J 是一個字串長度，陣列的起始下標是 0，所以字串長度為 1 的最後一個字元的索引是 0。”

找到bug後，查詢其他意外情況。檢查程式出錯時主要的程式變數的值，是否可以解釋這些值。

“為什麼 name 是 null？” “為什麼它總是輸出錯誤資訊呢？”

記錄下你做了哪些操作，發生了哪些變化。你需要知道究竟發生了什麼，這樣做就意味著你時刻有一把標尺和歷史記錄。

修復每個bug後都要問問自己下面這3個問題：

其他地方也會出現這個錯誤嗎？

這個bug後面隱藏著什麼其它的bug ？

我應該做些什麼防止類似bug的產生呢？

PS：有必要建立一些系統方法和自動化工具，用於編譯、構建和測試，它們可以減少長時間的除錯和查明具體事實的過程。

養成這樣一種習慣：每當你發現一個bug時，問自己這三個問題，甚至你不必等到有 bug時才使用這三個問題。

日積月累，你的技術水平自然會提高！

程式設計師在工作中耗時較長的就是閱讀（自己寫的或者別人寫的）程式碼，如果用心肯定是能學到東西的。寫的好的可以借鑑，留心一下，下次處理類似的情況就有了參考。

有bug的地方不妨多想想看為什麼這裡出了問題，是單純的因為粗心？還是因為某個函式的用法沒有搞明白，還是沒有完全理解功能需求等等……等到自己寫程式碼實現某個功能的時候，多注意這些問題，這不就提升了嘛！

修復每個bug後都要問這3個問題

其實每一個bug都是底層程序的一個不良表現。

你必須處理這些症狀，但如果你僅僅是處理這些外在症狀，你就會有永遠解決不完的問題。

你應該找到產生bug的程序，並且修復這個程序。當你確定究竟發生了什麼和發生這些的原因時，也許你就會明白產生bug的基礎程序不是隨機的，而是可控的。

在問這三個問題前，你需要克服面對bug的這種天生的抗拒，仔細分析bug。檢視程式碼並解釋出錯的原因，從能觀察到的現象開始，向後分析，不斷地問為什麼，直到你可以找到產生bug的模式。

“它溢位了，因為下標J越界了。” “為什麼？” “J 是 10，但陣列最大下標為 9。” “為什麼？” “J 是一個字串長度，陣列的起始下標是 0，所以字串長度為 1 的最後一個字元的索引是 0。”

找到bug後，查詢其他意外情況。檢查程式出錯時主要的程式變數的值，是否可以解釋這些值。

“為什麼 name 是 null？” “為什麼它總是輸出錯誤資訊呢？”

記錄下你做了哪些操作，發生了哪些變化。你需要知道究竟發生了什麼，這樣做就意味著你時刻有一把標尺和歷史記錄。

修復每個bug後都要問問自己下面這3個問題：

其他地方也會出現這個錯誤嗎？

這個bug後面隱藏著什麼其它的bug ？

我應該做些什麼防止類似bug的產生呢？

PS：有必要建立一些系統方法和自動化工具，用於編譯、構建和測試，它們可以減少長時間的除錯和查明具體事實的過程。

養成這樣一種習慣：每當你發現一個bug時，問自己這三個問題，甚至你不必等到有 bug時才使用這三個問題。

日積月累，你的技術水平自然會提高！