建站
咨詢
售后
建站咨詢
新聞中心
沒有錯誤的程序是一則謬論，世間難尋。假設(shè)存在著一個沒有任何錯誤的程序，那么這個世界將會不復(fù)存在。
----《編程之禪》第四篇（金）第二節(jié)
hello world是人類已知的最早的絕無bug的程序，但我們在日常開發(fā)中，需求不可能簡單到像hello world一樣，經(jīng)常是coding五分鐘，debug2小時。在討論如何減少bug之前我們討論下哪些場景下容易產(chǎn)生bug。
1、bug產(chǎn)生原因：
a、需求本來就有問題而產(chǎn)生的代碼缺陷。這類問題源頭是需求或產(chǎn)品這一塊沒有分析清楚，這個鍋產(chǎn)品背，但是作為開發(fā)者有必要參與到需求分析這個環(huán)節(jié)中。
b、代碼實現(xiàn)和需求相差很大的缺陷。這類問題也是比較常見的，開發(fā)人員的思維與需求或產(chǎn)品人員的思維還是有很大差距的。
c、很復(fù)雜的需求代碼實現(xiàn)在某些邏輯上有缺陷。這類問題有可能是開發(fā)人員不想實現(xiàn)完全，也有可能需求過于復(fù)雜，在系統(tǒng)設(shè)計階段就沒有分析出所有情況。
d、需求變動后對原有業(yè)務(wù)代碼進行重構(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é)的幾點心得，歡迎補充
?詳細和無歧義的需求規(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ù)，永遠不要相信數(shù)據(jù)的可靠性，考慮到各種邏輯分支
? 限制函數(shù)的長度， 編寫易讀易維護的代碼，不過度使用技巧，難以理解的代碼很可能在修改中出錯
? 使用assert ，正確使用異常處理，捕捉能夠處理的異常
萬一真的出現(xiàn)了bug也別慌，善用《甩鍋大法》， 代碼沒錯接口的錯，接口沒錯SDK的錯，SDK沒錯編譯器的錯， 編譯器沒錯虛擬機錯， 虛擬機沒錯操作系統(tǒng)錯， 操作系統(tǒng)沒錯，硬件錯了，硬件沒錯還有電磁干擾，總之不要自己背鍋哈哈哈，兄得接住這口鍋??！
***我個人認為寫出沒有bug的程序要在需求不不變的情況下。之所以產(chǎn)品不斷的維護有bug是因為后續(xù)的需求變更在前期的軟件設(shè)計中是無法考慮的。由于需求變化，但是又不可能每次變更需求都要重新設(shè)計架構(gòu)和軟件，導(dǎo)致軟件也在bug發(fā)現(xiàn)和消除中循環(huán)著來度過軟件的生命周期，直到軟件下線，所以我們只能不斷積累開發(fā)經(jīng)驗，培養(yǎng)思維的嚴密性，養(yǎng)成良好的開發(fā)習(xí)慣，來減少bug。
網(wǎng)站名稱：避坑指南：程序猿如何避免線上Bug
鏈接地址：http://www.dlmjj.cn/article/dpesjgg.html
