代碼和bug如影隨形，每一個應用程序都有bug。從理論上講，因為測試無法覆蓋所有情形，所以存在bug的可能性一直有。
水平再高的工程師，也無法一次寫出沒有bug的代碼，更不能一次性修復所有bug，這和不能一步登天是一個道理。
從另一個角度講，程序中的bug有不同的種類，原因也各不相同，甚至可以劃分為三六九等。可以這么說，"不同水平"的bug，一定程度上反映了軟件工程師的專業水平。
1， 文案bug
這類bug大多可以避免，原因多是因為粗心、沒有認真檢查，或者多次反復修改文案造成。
2， 代碼級別的bug
代碼中常見bug很多，比如變量引用錯誤、計算公式錯誤，還有常見的異常處理等錯誤。
這類問題容易修復，并且能夠通過代碼檢查、功能測試等方式減少甚至避免。
初級工程師寫代碼時常犯這類錯誤，隨著水平提高和經驗積累，代碼質量逐步提升，bug也就隨之減少。
3， 邏輯錯誤
實現業務邏輯時，如果代碼和業務需求不一致，比如計算每月的最后一天，如果使用30天或者31天，都會引起錯誤，因為每月天數不固定。
那么應該如何避免這類bug，又不至于將代碼變得過于復雜呢？經常使用一些數學算法、公共代碼庫或者第三方開發包等。比如上個例子，可以使用下個月的1日減去一天，得到本月最后一天。
這類bug經常由于測試覆蓋不到而較難發現，比較好的方式通常采用單元測試，覆蓋足夠的業務場景，從而保證代碼邏輯符合預期。
4， 調用模塊錯誤
開發應用系統時，經常調用一些功能模塊，比如Python開發時使用的urllib，還有自己開發的應用服務，比如訂單配送管理。
應用上線后，業務逐漸豐富完善，系統功能越來越復雜，常常進行模塊服務劃分，然后通過接口調用協作。
不同模塊的接口、數據、版本不一致時，會產生一些bug，不僅難于發現，而且較難修復。這類問題常常需要配合單元測試、自動化測試，并在修復后回歸測試。
為了提高工作效率，自動化測試工具配合構建服務器，在每次代碼提交時或者每天定時構建時，自動觸發任務，確保測試用例覆蓋業務場景。
5， 系統集成bug
2020年4月22日，發生了令人不可思議的中行原油寶穿透事件。原油寶交易系統在提交價格時，對負數價格進行驗證，判定無效，所以也就禁止了進一步提交操作。從單個系統看，這樣做是沒有問題的。
但是還有CME的WTI原油期貨交易系統，它是允許負數價格的，這就悲劇了。
4月20日，因為疫情惡化，美國原油期貨合約結算價格暴跌，報出了-37.63美元/桶的歷史性負數，下跌306%，引爆全球市場。根據中行4月22日公告，旗下理財產品原油寶將按照-37.63美元/桶的官方結算價定價。
這意味著投資者所有本金都將蕩然無存，還要倒欠銀行錢。
多個系統間的bug需要通過完整的用例設計來避免，比如中行原油寶，測試要覆蓋到交易所系統的完整用例。
