一、概述
愛因斯坦曾經說過：「如果給我乙個小時解答一道決定我生死的問題，我會花55分鐘來弄清楚這道題到底是在問什麼。一旦清楚了它在問什麼，剩下的5分鐘足夠解答這個問題。」
雖然我們軟體開發過程不會面臨生死的抉擇，但是卻直接影響著使用者的使用感受，決定著產品的走向。所以程式設計師如何減少開發中的 bug，既反映了**質量，也反映了個人綜合能力。
那麼我們該如何有效的減少開發中的 bug 呢？
我覺得應該從兩方面說起：業務層和**層。
二、業務層
軟體開發過程我們就不細說了，直接來看最重要的幾個節點：
1.需求討論階段
一定要明確需求，測試，開發，產品三方務必達成一致。前期如果存在沒有明確的問題，那麼後期就會造成無效返工和不必要的爭執，這在日常開發尤為常見。
所以，軟體開發前期，我們都會進行「評審，反講，評估」三個階段。
2.開發完成階段
開發完成後，程式設計師首先要完成「自測」，也就是軟體開發中的「冒煙測試」，確保主流程無誤。否則，在開發工程師提交**後，測試工程師步履維艱，無法有效開展測試，會造成極大的資源浪費。
更規範的流程需要測試工程師在需求明確之後寫出「測試用例」，開發工程師在完成開發後，自行對照「測試用例」完成初步驗證，之後就可以**提測了。
這麼做的好處就是既保證了「高質量的**交付」，同時減少了測試工程師的工作量，我們何樂而不為呢？
3.提測
自測和提測有什麼區別呢，從軟體開發過程來看，其實開發工程師和測試工程師其實完成了不同階段的測試：
開發工程師「白盒測試」：
是指實際執行被測程式，通過程式的源**進行測試而不使用使用者介面。這種型別的測試需要從**句法發現內部**在演算法、溢位、路徑和條件等方面的缺點或者錯誤，進而加以修正。
白盒測試需要從**句法發現內部**在演算法，溢位，路徑，條件等等中的缺點或者錯誤，進而加以修正。
測試工程師實際進行的是「黑盒測試」。那麼什麼是「黑盒測試」呢？
黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程式看作乙個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，在程式介面進行測試。
它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入資料而產生正確的輸出資訊。黑盒測試著眼於程式外部結構，不考慮內部邏輯結構，主要針對軟體介面和軟體功能進行測試。
黑盒測試是以使用者的角度，從輸入資料與輸出資料的對應關係出發進行測試的。
很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。黑盒測試法注重於測試軟體的功能需求，主要試圖發現下列幾類錯誤。
三、**層
**層面，我們需要從以下幾方面來說起：
1.eslint 規避低階語法問題
這個顯而易見，編寫**過程發現問題，避免因為簡單語法，如：漏寫了逗號，變數名寫錯，大小寫問題等
2.邊界處理
做好容錯，必要的判空，還有就是**邊界問題。多想一想如果陣列不存在，我們如何處理？如果陣列越界，我們如何修復？如果資料缺失，我們如何使頁面不崩潰？
3.單元測試
如果時間允許，我們可以做好單元測試，每次編譯**，或者提測前啟動指令碼，確定測試指令碼都覆蓋到了核心**，盡可能減少**出錯率。
4.積累
為什麼說要積累，其實道理很簡單。隨著開發經驗的增長，你可能會碰到很多問題，那麼如果細心積累，其實很多錯誤在不知不覺中就被處理了。反之，你會不斷的掉入同乙個坑里，在進坑與出坑中迷失自我。那麼我們如何積累呢？
首先，碰到自己不會的問題，如果第一時間沒有解決，通過查詢或者請教別人解決了，那麼一定要用小本本記下來，最好使用雲筆記。好處不言自明。
其次，要積累自己的函式庫，我們經常用到的一些方法，不妨自己做乙個封裝，不斷沉澱。也許有一天，你會發現，自己不知不知覺中寫出了乙個 lodash 函式庫。
最後，你可以積累優秀的**片段，嗯，「我們不生產**，只是優秀**的搬運工」。
5.學習
一句話，沒有什麼比學習優秀開源**更有趣的事情了。閱讀優秀原始碼，學習作者思想，站在巨人肩膀上，你才能走的更遠！
做好上面這些，相信你一定會是一位出色的工程師。
四、總結
對於這類開放問題仁者見仁，智者見智，我相信每個人都會有自己的看法，也會有自己一套獨特的方法。不管黑貓白貓，能抓住老鼠的就是好貓。對於程式設計師來說，能減少 bug 的方法就是好方法。
程式設計師群體流傳一句話：不寫**就有沒有 bug。
我們不能因為怕犯錯誤而減少寫**，更應該知難而上，越挫越勇。要知道日常開發中 「bug 是不可避免的，只能減少」。
當然，這不應該成為我們寫出 bug 推脫的理由。不斷超越，方是永恆。
程式設計師如何減少BUG
最近乙個專案出了大量的bug，很是慚愧，有沒有可以盡量規避bug的良方呢？可能沒有，但總有儘量減少bug出現機率的方 吧 我個人覺得在企業應用開發中，bug大致可以分為如下三類 一 程式本身語義上的bug。執行時bug。比如np之類的。二 需求理解方面的差異導致的bug。簡單說，就是程式本身語義沒有...
使用測試列表幫助程式設計師有效減少BUG
當乙個程式設計師寫完 以後，這樣說其實很空泛，怎樣規模的 呢，暫且認為是乙個將要交付的系統功能的 並初步測試通過後不要急於提交，應該先自己 review 一遍，其目的在於檢查 中能夠通過肉眼而非 debug 就可以發現的問題。比如 l定義的變數是不是都用上了，定義了但沒有使用的變數顯然影響其他人的閱...
程式設計師如何描述清楚線上bug
乙個管理後台的bug，把操作記錄中的操作員姓名，寫成了該操作員的id。原因是修改了乙個返回操作人姓名的函式，返回了操作人的id。但是還有其他地方也用這個函式，導致其他地方把姓名字段填寫成了操作員的id。該bug汙染了一條修改記錄，操作員手動刪除就好了。回滾 後恢復。本質是修改了函式的返回值，卻沒有檢...