正常情況下：bug不是人們有意寫的，bug其實是程式設計師犯的錯誤。

首先，我們把bug分類，不同的型別的Bug，不同的處理方式。儘量照顧到了，Bug就會少很多。

1.特殊需求。

2.邏輯性Bug。

比如數值轉換錯誤，演算法錯誤，計算結果不對等等。這塊就是考驗開發人員自身功力，特別是理解需求和耐心以及細緻了。全看個人了。繞不過去，提升自身能力為上。

3.框架和框架應用Bug有些框架本身自帶bug，被程式碼觸發之後，是修正還是繞過去，完全看具體的情況了。框架應用bug，因為對框架的某些技術細節不熟悉，胡亂用框架程式碼導致的bug。或者程式碼需求已經超出框架設計初衷了。要麼仔細學習文件，要麼繞行。

4.外部環境變化引入的Bug

舉個例子來說：網路伺服器的開發，一般的開發環境都是高網速的區域網中，實際部署之後，可能會遇到極低網速連線情況。可能會引發在高速網路開發環境中無法發現的Bug。資料庫連線也是同樣的問題，高負荷生產資料庫和低負荷的開發伺服器的不同，會帶來一些bug這樣的不可預料的偶發Bug，只能是記錄好關鍵日誌，以備後查。

下面說說如何避免BUG:

詳細和無歧義的需求規格和業務邏輯合理的架構和模組清晰明確的模組間介面分而治之，降低複雜性不要複製程式碼，儘可能抽取共用的部分，重複的程式碼在修改時容易造成不一致當代碼有自解釋性，使用識別符號清洗標明變數和方法的含義，少用字面量，只有一次呼叫的程式碼段也值得抽取成函式為程式碼書寫註釋，函式或方法要詳述介面的引數和返回值，什麼是未定義的行為。單行註釋或多或少，但在特殊的處理處一定要寫註釋，不僅要介紹怎麼幹，特別要介紹為什麼這麼幹處理邊界條件，處理非法的引數，考慮到各種邏輯分支編寫易讀的程式碼，不過度使用技巧，難以理解的程式碼很可能在修改中出錯編寫容易維護的程式碼，使用面向物件方法和依賴注入，隔離可變性消除副作用，使用不可變資料（如函數語言程式設計，以Java為例，使用final修飾不可變變數）Fail-fast，使用assert來處理各種進入條件，退出條件等正確使用異常處理，捕捉能夠處理的異常不使用goto語句，儘可能減少switch語句，以多型取代switch限制函式的長度和圈複雜度單元測試，測試用例的數量應該和函式的圈複雜度相符，度量並提高測試覆蓋率進行程式碼走查或評審，多一雙眼睛可能發現潛在的問題.

希望對你有所幫助！請關注點贊，謝謝！