請支持原文作者 :碼農翻身
碼農寫代碼的最高境界就是：一次寫成， 沒有bug。

這個境界我是達不到的， 但是我能達到這個層次： 多次寫成， 沒有bug。

或者更準確的說法是：我已經(jīng)在寫代碼階段把bug都消滅了，測試團隊運行完測試用例以后，發(fā)現(xiàn)的Bug數(shù)為零。

其實沒有bug也不準確，因為測試階段沒有發(fā)現(xiàn)Bug 并不代表上線以后也沒有Bug， 但至少證明這是一段高質量的代碼。

可能有人要跳出來了：這不可能，肯定是你的功能太簡單了。 實際上我最近寫的這段代碼應該是屬于中等復雜度的：

需要從一個消息隊列中獲得不同類型的XML消息， 對消息進行解析，更新數(shù)據(jù)庫，獲取數(shù)據(jù)庫中符合條件的用戶， 發(fā)送郵件。

一個比較好的地方是：沒有界面 ！ 其實我個人不喜歡寫Web界面的，覺得很繁雜 :-)

那零Bug代碼是怎么寫出來的呢？ 我想了想，主要有這些關鍵點：
1
透徹理解需求
很多人看到需求以后， 想都不想立刻就開始編碼，這是有問題的。

作為碼農，雖然不是需求分析人員， 也要考慮下為什么要有這個需求 ， 這個需求有哪些主干路徑， 有哪些分支路徑 ， 在腦子里要形成一個圖譜。

把自己假想成用戶，換位思考下，看看用戶會如何使用這個功能， 通常你都會發(fā)現(xiàn)一些意想不到的情況。
2
良好的設計
把功能劃分成接口良好的模塊，讓每個模塊各司其職，又能依靠良好的接口有效合作， 能極大的減少Bug的產生。

這考驗就是基本功了 ， 沒有速成大法， 只有自己慢慢苦練。

注意：我這里說的設計不一定是文檔 ，有可能只是在你的腦子里。
3
處理好邊界條件
據(jù)說80%的Bug是在“邊界”發(fā)生的，這些邊界條件包括：
輸入數(shù)據(jù)不合法
數(shù)組越界
調用的方法拋出異常
文件不存在
文件權限不夠
調用其他系統(tǒng)接口時數(shù)據(jù)未能正常返回
打不開數(shù)據(jù)庫連接
數(shù)據(jù)庫表在初始情況下沒有值
運行時間過長導致超時
......
我經(jīng)常發(fā)現(xiàn)， 大量的代碼被用來處理邊界條件， 有時候甚至比業(yè)務代碼都要多。
4
充分的測試：不放過一行代碼
這是我最想說的，測試不僅僅是測試人員的事情 ， 也是開發(fā)人員的事情。

一定要保證每一行代碼都被你執(zhí)行過，不留任何死角。

這一點非常重要， 要么你是通過寫自動化測試覆蓋到的，要么是手工執(zhí)行測試覆蓋到的。
千萬不能是你覺得代碼簡單，不會出問題，就不管了。
5
考慮代碼修改對別的模塊的影響
很少代碼是完全獨立的，總是或多或少和別人扯上關系， 修改這樣的代碼就要小心了， 這也是個主要的Bug發(fā)生地。

一定要考慮代碼的修改對別人的影響， 并且做回歸測試。

零Bug代碼會帶來巨大的好處，開發(fā)完成，進入功能測試或者驗收測試階段以后， 成本會很低， 測試會很快， 因為基本上都是一次通過，沒有bug 就不需要修改代碼，返工的成本就不存在。

寫出零Bug代碼，或者接近于零Bug代碼應該是每個碼農的追求，其實也不太難，只要用心， 有著對需求的透徹理解，清晰的思路，良好的設計和編碼，以及非常充分的測試，基本上就差不多了。