請(qǐng)支持原文作者 :碼農(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消息凭峡， 對(duì)消息進(jìn)行解析，更新數(shù)據(jù)庫决记，獲取數(shù)據(jù)庫中符合條件的用戶摧冀， 發(fā)送郵件。
一個(gè)比較好的地方是：沒有界面 系宫！ 其實(shí)我個(gè)人不喜歡寫Web界面的索昂，覺得很繁雜 :-)
那零Bug代碼是怎么寫出來的呢？ 我想了想扩借，主要有這些關(guān)鍵點(diǎn)：
1
透徹理解需求
很多人看到需求以后椒惨， 想都不想立刻就開始編碼，這是有問題的潮罪。
作為碼農(nóng)康谆，雖然不是需求分析人員领斥， 也要考慮下為什么要有這個(gè)需求 ， 這個(gè)需求有哪些主干路徑沃暗， 有哪些分支路徑 月洛， 在腦子里要形成一個(gè)圖譜。
把自己假想成用戶孽锥，換位思考下嚼黔，看看用戶會(huì)如何使用這個(gè)功能， 通常你都會(huì)發(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)非常重要闰渔， 要么你是通過寫自動(dòng)化測試覆蓋到的，要么是手工執(zhí)行測試覆蓋到的铐望。
千萬不能是你覺得代碼簡單冈涧，不會(huì)出問題，就不管了正蛙。
5
考慮代碼修改對(duì)別的模塊的影響
很少代碼是完全獨(dú)立的督弓，總是或多或少和別人扯上關(guān)系， 修改這樣的代碼就要小心了乒验， 這也是個(gè)主要的Bug發(fā)生地愚隧。
一定要考慮代碼的修改對(duì)別人的影響， 并且做回歸測試锻全。
零Bug代碼會(huì)帶來巨大的好處奸攻，開發(fā)完成蒜危，進(jìn)入功能測試或者驗(yàn)收測試階段以后， 成本會(huì)很低睹耐， 測試會(huì)很快辐赞， 因?yàn)榛旧隙际且淮瓮ㄟ^，沒有bug 就不需要修改代碼硝训，返工的成本就不存在响委。
寫出零Bug代碼，或者接近于零Bug代碼應(yīng)該是每個(gè)碼農(nóng)的追求窖梁，其實(shí)也不太難赘风，只要用心， 有著對(duì)需求的透徹理解纵刘，清晰的思路邀窃，良好的設(shè)計(jì)和編碼，以及非常充分的測試假哎，基本上就差不多了瞬捕。
