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

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

1 -新手開(kāi)發(fā)+新手測(cè)試=無(wú)敵巨坑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大概程序員走過(guò)最長(zhǎng)的路便是背鍋之路了。

2005 年 12 月 8 日瑞穗證券的交易員因手誤輸入錯(cuò)的股價(jià)，2 分鐘后這人試圖通過(guò)交易軟件撤銷(xiāo)這筆賣(mài)單?？墒沁B續(xù)輸入 3 次撤單指令，都被東證的交易系統(tǒng)拒絕了。這次事故造成400 億日元的損失。

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

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

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

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

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

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

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

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

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

此時(shí)測(cè)試人員不可輕易聽(tīng)信開(kāi)發(fā)的話(huà)，更要嚴(yán)謹(jǐn)對(duì)待，畢竟程序員的三大謊言有：沒(méi)問(wèn)題的；只改了兩行代碼；和線上一樣。 

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

***一招是兩個(gè)字：我改!