Bug的嚴重程度如何評定？程序員該如何減少Bug？

Bug 是程序員最不愿意用面對，但又經常出現的一個 “詭異生物“。學會了分析它的嚴重程度，做好分類，在工作中也會輕松很多。

那么，你知道bug該如何分類嗎？

依據bug影響程度分級

1級：致命

●由于程序引起的非法死機，退出，數據丟失，主要功能完全喪失，系統懸掛等錯誤

●操作或使用某一功能時，導致程序異常退出，或其余功能無法使用，或造成經常性死機和重啟

●正常的用戶操作，導致系統崩潰

2級：嚴重

●嚴重影響系統要求或基本功能的實現，且沒有辦法避免沖突

●主要功能喪失，導致嚴重的問題，或致命的錯誤聲明

●配置項設計錯誤，無法正常配置，或配置后測試中出現預配置相關的錯誤

3級：一般性錯誤

●次要功能喪失，不太嚴重，可通過變通手段解決.

●部署文檔錯誤，導致部署失敗

●業務流程對應的功能未實現，但是有對應替代方法解決，不影響實際使用

4級：建議性

●從使用者角度，提出的建議性意見

●用戶界面不太友好

●對齊方式，包括文字對齊，頁面排列項一致

依據開發工作態度分級

低級（低級bug）

●功能不可用

●bug指出修復后，其他頁面出現同樣的bug

●漏傳文件

●上線了一些緩存或者配置文件

●緩存問題：忘記清線上緩存，導致數據異?；蚓彺孀⑨屛慈サ?/p>

●開發遺漏需求

●出現調試代碼

●存在sql注入或xss攻擊

中級（普遍型的bug）

●除開low與high類型的bug，其他bug都歸屬這類

高級（不常見bug）

●由于系統不一致造成的bug

●系統崩潰：并發測試情況下的內存溢出、崩潰

●數據庫異常

●對方接口問題

那么，該如何減少代碼的bug呢?小編在此分享幾個技巧：

別對警告視而不見

相信不少的程序員會使用IDEA，使用它敲代碼，有時候會出現警告，那么這時你對警告就不能視而不見了。

編程習慣

種瓜得瓜種豆得豆，好的編程習慣可以大大降低bug數量。譬如有if必須寫else，即使else是個空語句 。

別熬夜寫代碼

對于程序員而言，千萬別熬夜寫代碼。一些程序員在晚上11點，仍然在敲代碼。雖然你自己覺得頭腦其實很清醒，但是第二天自測，或者QA測試的時候你有可能就會發現問題很多。

我們一般不提倡長期加班寫代碼，因為那樣會導致bug率直線上升。

驗證

在提交測試前要多驗證，其中包括自動化測試、手動跑用例等。千萬別怕麻煩，不然你會麻煩一輩子。

仔細的設計

在程序員編寫代碼之前，必須對代碼的整個結構以及邏輯結構胸有成竹。

避免干擾

有部分的程序員敲代碼的時候，經常會一邊聽音樂一邊敲代碼，這樣效率不僅僅低，而且也更容易產生bug。

注釋

寫注釋！寫注釋！寫注釋！重要的事情說三遍。

因為前期的注釋有利于后續開發的時候容易減少bug。

很多公司將bug量作為評估一個程序員晉升的重要參考指標，高質量的代碼對程序員在職業道路上的晉升起到不可忽視的作用。因為，bug量的多少能直接反映你開發的代碼的質量，也直接影響版本發布的時間周期。所以，開發完成后千萬不要忘記復查你的代碼，減少bug量。