作為程序員，你有哪些最大限度降低bug率的辦法？

12-03

引用我之前的一個回答：怎麼讓自己寫的程序更靠譜？ - 知乎，直到今天，我的觀點仍然和之前一致。最笨、最實用的方法是不斷地驗證。

就跟一篇好文章是改出來的一樣，一款優秀的程序也是不斷迭代、完善優化出來的，並不能一氣呵成做得完美，即使你做了完善的程序設計、Code Review、Unit Test，並不能保證你的程序靠譜、bug少，最重要的還是要驗證，如果想讓bug少，就在提交測試前自己多驗證，包括自動化測試、手動跑用例等等。

舉個栗子：播放在線音樂，有很多case需要考慮，但這些case並不是一下子都能考慮到，即使你足夠神奇各種情況都考慮到了，你還得在各個case下驗證吧。

播放時的網路環境（wifi、4G、2G、弱網、認證網路，主要在於這些情景下的交互）；
播放時的操作（暫停、下一首，除了保證功能正常，還要考慮到頻繁切換、快速點擊的情況）；
播放時的打斷（來電話、響鬧鈴、清理後台、低電關機、強行關機）；
系統強相關（內存不足時、磁碟空間滿時）；
其它（線控、藍牙、是否有卡頓、功耗的問題等等）。

一款程序中有太多這樣的功能特性了，對於每個功能特性都需要考慮到各種情形，不然怎麼做到穩呢？

今天的軟體開發，確定開發前要調研驗證；開發過程中要持續迭代、小步快跑一個feature一個feature地驗證；發布時要先灰度再全量。其實都是在不斷地驗證，只有這樣，程序才會足夠穩定、bug少。

沒經過商業項目考驗的代碼一文不值。

寫證明。

把行為約束打在 type 里，所謂 Type driven 是也。

Code review + unit test + system test

Java：

1. 儘可能的少寫代碼（別打我），中間過程越多，證明你出錯的幾率越大，思維不要僵化，現在流行微服務，如果是一個簡單的微服務（rest），Controller直連Dao又有何不可？非要分三層、五層，太制式了。

2. 別動不動就各種Utils，這類Utils在commons包中幾乎都有，其他語言應該類似，除非你真的有很多年經驗你真的需要高性能。

3. 注釋寫清楚，避免兩個月後來維護出現新BUG，PS:注釋你得符合Java Doc規範該at什麼就at什麼，別亂七八糟瞎at，@Description、@Remark 這類神經病一樣的注釋註解除了證明你不會Java還能證明什麼？編譯的時候忘記關JavaDoc，一水兒的異常，正兒八經的警告和錯誤都被刷沒了。

看看人家的注釋，再看看你的。

4. 一般不提倡加班寫代碼，長期加班會導致Bug率直線上升，很多項目你會發現，加班與不加班耗費的天數幾乎相等；當然了，除非你靈光閃現，真的需要一氣呵成的代碼，PS:心情煩躁的時候不要寫核心代碼，哪怕磨洋工都行，如果你每天都心情煩躁，那就抓緊換工作，這地兒風水不好。

5. 測試用例，別連線上環境，在測試包下單獨建立resources和配置文件，掛著VPN連線上環境，還mvn install順帶著跑測試用例的事故屢禁不止，不過說實話我覺得你們大多數開發都不會認真去寫，不聊也罷。

6. 英語單詞，你可以機翻，但是千萬別寫錯別字，合同contract你翻譯成construct鬼知道你是幹什麼的，相反 physicalCalculation這個變數名，雖然比較抽象，但是結合業務，我知道你是理計而不是過磅（你們別特么問我為什麼舉著個栗子……我想靜一靜）。

7. 開源的東西，別聽別人瞎吹，優先用Apache，其次用Github星星高的，國內的，千萬要謹慎！

8. 警告這種東西，能消除掉的盡量消除掉，用IDEA會提示你很多警告，寫乾淨的代碼，做乾淨的人。

9. 過期的方法不要用，源代碼下載下來，源碼里的注釋會告訴你用什麼辦法替代，別百度了。

10. 上班之前洗把澡，保持頭腦清醒；編碼之前先洗手，這是對鍵盤最起碼的尊重。

======更新=====

當然，也是對滑鼠最起碼的尊重（摸摸我的愛鼠）。

我的經驗是，在很多項目里，最大的bug來自於產品經理/客戶/老闆。

這個bug就是：他們自己也說不清程序應該是什麼樣子的，但是等你寫出來以後，他們能挑出你成千上萬個bug。

然而你又能怎麼樣（攤手）

大道至簡，用最平實的心態來做日常coding，不耍花哨，不玩技巧，多寫注釋，注意排版。

江湖傳言，你調試時需要有三倍於編碼的功力才能順利找到bug，所以如果你寫代碼時發揮了100%的功力寫出了天外飛仙般的神之一手，那假如不幸這程序有bug，你需要你現在300%的功力才能調試得了。

1.動手之前多想想怎麼規劃如何實現留出能想到的可能需要擴展增加的地方

2.編寫的時候，盡量找好時間最好是一段連續的時間誰也不想寫一半被拉去開會。這個其實你也決定不了現在都是上班開會下班編碼

3.編寫習慣決定了bug多少。有if必須寫else，哪怕else是個空語句。指針使用前先判空，資料庫，文件，網路傳輸請try catch 。你可以確信你的代碼無誤，但是你保證不了資料庫不掛磁碟不滿文件鎖不衝突或者機房修空調的不把你的伺服器當空調拉走

4.關鍵位置日誌全覆蓋，找錯容易，特別是多個系統間交互，請求和接收的數據都記下來，多人合作，沒有的代碼請不要注釋掉就不管了。

5.測試是最無聊的，我個人就很討厭測試，但是這也是最重要的，單元測試一個一個函數測試盡量把所有語句分支執行一遍

然後你就會發現測試妹子不找你了你也在單的路上越走越遠

每一行代碼都走心，就可以了

寫 C/C++ 的時候腦中謹記 Rust 思想（逃……

bug 率是衡量程序的一個比較後期的指標，它是一系列指標的果而非因。哪些因素是因呢？軟體工程里有一個著名的說法，解決一個軟體問題的成本，在設計階段是一美元，在代碼編寫階段是十美元，在測試階段是一百美元，在運營中是一千美元（這個說法比較老，如今差距可能沒有這麼大）。而所謂的 bug率是至少是在測試階段的指標，它是好設計和好編碼的結果。

什麼樣的設計是好設計，什麼樣的代碼是好代碼。這是軟體工程和計算機科學研究了多年的問題，短短几句話是說不清楚的。同時，根據軟體的用途的不同，不同軟體的所謂「好」與「壞」也有不同的標準。總體說來，目前比較一致的看法是，在設計上，堅持「高聚合，低耦合」，多做模塊化設計但也不做過度複雜的設計；在代碼編寫上，我覺得最重要的是思路清晰，邏輯簡潔而不過分簡單。

拋開這些比較正式的說法，我個人認為，要寫好代碼，最重要的還是找到自己的編程風格。這裡的編程風格不是指代碼縮進變數命名之類的風格，而是遇到問題時候的思考風格。對要解決的問題如何劃分決定了所謂的模塊化設計，如何從已有的經驗中找到解決開發需求的演算法決定了所謂的代碼質量。人的思維是有定勢的，如何訓練好自己的思維定勢，不僅能兼容更多的解決方案，更能簡潔的解決問題，是值得認真考慮的問題。

降低單個模塊的複雜度是避免bug的最根本辦法。

多設計一會

慢點寫，多測試

水平不夠就少寫代碼，多調用經過考驗的庫吧，這樣bug最少。庫盡量用開源的。

在腦子清醒的時候寫代碼

感覺很適合做面試題呀！

最現實的答案大概就是：不加班，保持清醒狀態寫代碼。咖啡不會讓你注意力更集中，只會讓你自以為清醒。

寫代碼前寫文檔，設計好類型和介面。
寫文檔前了解環境，設計適應不了環境等代碼寫了一半才發現就被動了。臨時補丁往往引入新bug。
嚴格控制需求，一口吃不成胖子。
有類型系統的語言一定要少用原始類型，多用自定義類型，這樣編譯器才能幫上忙。
類型系統太弱的語言手動進行類型注釋，多做assert。
有條件多用函數式編程。
有條件多用狀態機模型。
畫出核心狀態轉換圖再寫狀態機代碼。
有用時一定要抽象，沒有用時一定不要抽象。
減少測試代價，能自動測試的一點寫代碼來測試。
不要過早優化，有O(log n)方法的一定先用O(n)的實現，只要介面保持隨時可以無縫替換即可。
不要做太多假設，儘可能寫通用代碼，再reduce到特定情況。

要充分利用已有的代碼和經驗，每個大公司都有相當多的代碼和文檔，要好好看看再動手。

不要自己去踩每個坑，盡量在github和stackoverflow上找已有的代碼和tips。

慢寫多測，也是很重要的。

盡量避免設計精巧的架構，設計的時候精巧到讓自己感動，不出一月就會氣得自己罵娘。
傻大粗笨才是王道

難道不是穿女裝和與小黃鴨說話？@胡澤聰（逃

很簡單：不寫就不會出bug

具體執行：把一些聽起來就很二逼的idea消滅在策劃說出嘴的那一刻