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

----《編程之禪》第四篇（金）第二節(jié)

[[223718]]

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

[[223719]]

1、bug產(chǎn)生原因：

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

b、代碼實(shí)現(xiàn)和需求相差很大的缺陷。這類問題也是比較常見的，開發(fā)人員的思維與需求或產(chǎn)品人員的思維還是有很大差距的。

c、很復(fù)雜的需求代碼實(shí)現(xiàn)在某些邏輯上有缺陷。這類問題有可能是開發(fā)人員不想實(shí)現(xiàn)完全，也有可能需求過于復(fù)雜，在系統(tǒng)設(shè)計階段就沒有分析出所有情況。

d、需求變動后對原有業(yè)務(wù)代碼進(jìn)行重構(gòu)，對原有業(yè)務(wù)不熟悉不了解

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

f、系統(tǒng)架構(gòu)上的缺陷。這類問題一般很少，出現(xiàn)的話是大面積的。

g、對框架特性、數(shù)據(jù)結(jié)構(gòu)、語言不熟悉，導(dǎo)致出現(xiàn)缺陷。

h、外部原因，操作系統(tǒng)或數(shù)據(jù)源。

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

•詳細(xì)和無歧義的需求規(guī)格和業(yè)務(wù)邏輯

•合理的架構(gòu)和模塊

•清晰明確的模塊間接口

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

•不要輕易重構(gòu)代碼，每次重構(gòu)，盡量做到所重構(gòu)的業(yè)務(wù)都在本次QA測試用例的覆蓋范圍內(nèi)

•盡量在理解同事業(yè)務(wù)代碼的情況下，更改組內(nèi)成員的業(yè)務(wù)代碼

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

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

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

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

[[223720]]

***我個人認(rèn)為寫出沒有bug的程序要在需求不不變的情況下。之所以產(chǎn)品不斷的維護(hù)有bug是因?yàn)楹罄m(xù)的需求變更在前期的軟件設(shè)計中是無法考慮的。由于需求變化，但是又不可能每次變更需求都要重新設(shè)計架構(gòu)和軟件，導(dǎo)致軟件也在bug發(fā)現(xiàn)和消除中循環(huán)著來度過軟件的生命周期，直到軟件下線，所以我們只能不斷積累開發(fā)經(jīng)驗(yàn)，培養(yǎng)思維的嚴(yán)密性，養(yǎng)成良好的開發(fā)習(xí)慣，來減少bug。