程序員的日常三件事：寫bug、改bug、背鍋。連程序員都自我調(diào)侃道，為什么每天都在加班?因?yàn)槲业难劾锍：琤ug。

那么如何寫出一個讓(坑)人(王)很(之)難(王)發(fā)現(xiàn)的bug呢?

1 -新手開發(fā)+新手測試=無敵巨坑

有一天凌晨，某組的程序員們被電話轟炸醒了。用戶紛紛投訴自己的業(yè)務(wù)數(shù)據(jù)離奇消失了!

大伙排查半天，原來是新來的小王埋的坑。他三個月前開發(fā)的定時任務(wù)出bug了!

那時剛來的小王刷刷地將代碼寫完后，手把手教新來的測試實(shí)習(xí)妹子怎樣測試這塊代碼，估計(jì)是妹子還沒搞清楚里面的邏輯時便稀里糊涂地將代碼上線了。

萬萬沒想到這bug隱藏這么久，由于錯誤的邏輯導(dǎo)致錯誤的數(shù)據(jù)，錯誤的數(shù)據(jù)導(dǎo)致任務(wù)死循環(huán)執(zhí)行，當(dāng)執(zhí)行的時間過長，到某個點(diǎn)時，系統(tǒng)如汽水開瓶般“砰”地崩了。

業(yè)務(wù)不熟導(dǎo)致邏輯理解有問題，是大部分新人都會存在的問題。此時***安排個有經(jīng)驗(yàn)的測試“調(diào)教”下，降低bug發(fā)生率。

2 -不考慮系統(tǒng)拓展性，怎么方便怎么寫

史上最出名的“千年蟲”bug令全世界恐慌，甚至傳出“世界末日”的謠言。

原因竟讓人啼笑皆非：當(dāng)時的程序員沒考慮到軟件會被使用至21世紀(jì)，為了節(jié)省內(nèi)存省略掉代表年份的前兩位數(shù)字”19”，或者默認(rèn)前兩位為”19”。

“千年蟲“千年一遇，可日常關(guān)于時間的低級bug經(jīng)常發(fā)生，而且通常等到一段時間后的某個特定時間點(diǎn)才暴露出來，讓人防不勝防。

例如正則只匹配了“16”，“17”年，等到18年零點(diǎn)到來問題才暴露。

關(guān)于時間的bug非常多，大到閏年、夏令時、節(jié)假日、時區(qū)等，小到時間格式，每年都會碰到不小心遺漏的時間bug，所以很多公司對時間的通用測試用例就有許多條。

除了時間問題，程序員如果只考慮本次需求或者單個系統(tǒng)時，常常將字段設(shè)置不正確，后續(xù)業(yè)務(wù)拓展或者和別的系統(tǒng)交互時發(fā)現(xiàn)字段不夠用，只能修改字段長度了。

3 -不考慮上下游系統(tǒng)，招呼不打便隨意改接口

曾遇到A系統(tǒng)上線后，大伙回歸A系統(tǒng)正常運(yùn)行后，正樂滋滋地松一口氣之際，本來好端端運(yùn)行的B系統(tǒng)突然壞了，B組人排查半天發(fā)現(xiàn)，原來是A提供的接口改了，B系統(tǒng)不兼容新接口。

大概程序員走過最長的路便是背鍋之路了。

2005 年 12 月 8 日瑞穗證券的交易員因手誤輸入錯的股價，2 分鐘后這人試圖通過交易軟件撤銷這筆賣單。可是連續(xù)輸入 3 次撤單指令，都被東證的交易系統(tǒng)拒絕了。這次事故造成400 億日元的損失。

后來查明是交易系統(tǒng)出 bug了，程序員在 2000 年某次程序修改時不小心埋進(jìn)去的。

所以很多公司會嚴(yán)格要求在程序修改后必須經(jīng)過嚴(yán)格的回歸測試，來驗(yàn)證對其他業(yè)務(wù)流程有沒有影響。 

4 -復(fù)制、粘貼，我閉著眼，有bug看不見，debug了沒?

已發(fā)布已驗(yàn)證的代碼，是安全可靠的，是可以拿來即用的，無需質(zhì)疑，不用浪費(fèi)時間去調(diào)試，這是程序員的慣性思維。

被記入史上bug王之一的阿麗亞娜5型自毀事件就是因代碼復(fù)用而導(dǎo)致的。1996年6月4日，阿麗亞娜5型運(yùn)載火箭發(fā)射點(diǎn)火后，由于bug，在發(fā)射39秒后火箭發(fā)生偏軌，最終被迫引爆自毀。

這件事情發(fā)生的原因是因?yàn)?型火箭是基于4型火箭開發(fā)的，發(fā)射系統(tǒng)的代碼程序員也直接照搬4型的。

該段代碼在4型火箭中被反復(fù)驗(yàn)證，但在5型卻沒有進(jìn)行驗(yàn)證。實(shí)際上4型的飛行條件和5型的飛行條件截然不同，最終導(dǎo)致事故發(fā)生，此次事故損失3.7億美元。

有測試工程師說，最害怕開發(fā)說這次沒啥改動，跟線上某功能差不多。這時候反而要細(xì)心驗(yàn)證代碼的正確性。

這是因?yàn)?ldquo;安全心理”作祟：程序員直覺已信任上線的代碼是正確的，便直接復(fù)制過來用，不會再花時間自測，因?yàn)檫@是“對的”，“毋庸置疑”的。

此時測試人員不可輕易聽信開發(fā)的話，更要嚴(yán)謹(jǐn)對待，畢竟程序員的三大謊言有：沒問題的；只改了兩行代碼；和線上一樣。 

程序員花30分鐘寫程序，花2小時改bug。bug，子子孫孫無窮盡也。所以在面對測試人員的質(zhì)疑時，程序員們一定要保持鎮(zhèn)定，該甩鍋時速速甩掉：這是歷史問題，我沒動過；剛剛在我這是好的，你環(huán)境配錯了；你重啟試試……

***一招是兩個字：我改!