沒有錯誤的程序是一則謬論，世間難尋。假設存在著一個沒有任何錯誤的程序，那么這個世界將會不復存在。

----《編程之禪》第四篇（金）第二節

[[223718]]

hello world是人類已知的最早的絕無bug的程序，但我們在日常開發中，需求不可能簡單到像hello world一樣，經常是coding五分鐘，debug2小時。在討論如何減少bug之前我們討論下哪些場景下容易產生bug。

[[223719]]

1、bug產生原因：

a、需求本來就有問題而產生的代碼缺陷。這類問題源頭是需求或產品這一塊沒有分析清楚，這個鍋產品背，但是作為開發者有必要參與到需求分析這個環節中。

b、代碼實現和需求相差很大的缺陷。這類問題也是比較常見的，開發人員的思維與需求或產品人員的思維還是有很大差距的。

c、很復雜的需求代碼實現在某些邏輯上有缺陷。這類問題有可能是開發人員不想實現完全，也有可能需求過于復雜，在系統設計階段就沒有分析出所有情況。

d、需求變動后對原有業務代碼進行重構，對原有業務不熟悉不了解

e、粗心導致的缺陷，比如條件判斷寫反，人孰能無過。

f、系統架構上的缺陷。這類問題一般很少，出現的話是大面積的。

g、對框架特性、數據結構、語言不熟悉，導致出現缺陷。

h、外部原因，操作系統或數據源。

那么如何避免產生bug呢，尤其是iOS，提交AppStore審核周期并不短，是否還記得那些慘痛的線上bug經歷，半夜起來改bug，提交后審核好幾天，所以有必要總結下如何避免bug，下面是我總結的幾點心得，歡迎補充

•詳細和無歧義的需求規格和業務邏輯

•合理的架構和模塊

•清晰明確的模塊間接口

•不要復制代碼，盡可能抽取共用的部分，重復的代碼在修改時容易造成不一致

•不要輕易重構代碼，每次重構，盡量做到所重構的業務都在本次QA測試用例的覆蓋范圍內

•盡量在理解同事業務代碼的情況下，更改組內成員的業務代碼

•處理邊界條件，處理非法的參數，永遠不要相信數據的可靠性，考慮到各種邏輯分支

• 限制函數的長度， 編寫易讀易維護的代碼，不過度使用技巧，難以理解的代碼很可能在修改中出錯

• 使用assert ，正確使用異常處理，捕捉能夠處理的異常

萬一真的出現了bug也別慌，善用《甩鍋大法》， 代碼沒錯接口的錯，接口沒錯SDK的錯，SDK沒錯編譯器的錯， 編譯器沒錯虛擬機錯， 虛擬機沒錯操作系統錯， 操作系統沒錯，硬件錯了，硬件沒錯還有電磁干擾，總之不要自己背鍋哈哈哈，兄得接住這口鍋！！

[[223720]]

***我個人認為寫出沒有bug的程序要在需求不不變的情況下。之所以產品不斷的維護有bug是因為后續的需求變更在前期的軟件設計中是無法考慮的。由于需求變化，但是又不可能每次變更需求都要重新設計架構和軟件，導致軟件也在bug發現和消除中循環著來度過軟件的生命周期，直到軟件下線，所以我們只能不斷積累開發經驗，培養思維的嚴密性，養成良好的開發習慣，來減少bug。