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

這個(gè)境界我是達(dá)不到的， 但是我能達(dá)到這個(gè)層次： 多次寫成， 沒有bug。

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

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

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

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

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

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

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

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

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

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

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

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

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

零Bug代碼會帶來巨大的好處，開發(fā)完成，進(jìn)入功能測試或者驗(yàn)收測試階段以后， 成本會很低， 測試會很快， 因?yàn)榛旧隙际且淮瓮ㄟ^，沒有bug 就不需要修改代碼，返工的成本就不存在。

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