程序員的日常三件事：寫bug、改bug、背鍋。連程序員都自我調侃道，為什么每天都在加班?因為我的眼里常含bug。

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

1 -新手開發+新手測試=無敵巨坑

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

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

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

萬萬沒想到這bug隱藏這么久，由于錯誤的邏輯導致錯誤的數據，錯誤的數據導致任務死循環執行，當執行的時間過長，到某個點時，系統如汽水開瓶般“砰”地崩了。

業務不熟導致邏輯理解有問題，是大部分新人都會存在的問題。此時***安排個有經驗的測試“調教”下，降低bug發生率。

2 -不考慮系統拓展性，怎么方便怎么寫

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

原因竟讓人啼笑皆非：當時的程序員沒考慮到軟件會被使用至21世紀，為了節省內存省略掉代表年份的前兩位數字”19”，或者默認前兩位為”19”。

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

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

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

除了時間問題，程序員如果只考慮本次需求或者單個系統時，常常將字段設置不正確，后續業務拓展或者和別的系統交互時發現字段不夠用，只能修改字段長度了。

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

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

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

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

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

所以很多公司會嚴格要求在程序修改后必須經過嚴格的回歸測試，來驗證對其他業務流程有沒有影響。 

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

已發布已驗證的代碼，是安全可靠的，是可以拿來即用的，無需質疑，不用浪費時間去調試，這是程序員的慣性思維。

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

這件事情發生的原因是因為5型火箭是基于4型火箭開發的，發射系統的代碼程序員也直接照搬4型的。

該段代碼在4型火箭中被反復驗證，但在5型卻沒有進行驗證。實際上4型的飛行條件和5型的飛行條件截然不同，最終導致事故發生，此次事故損失3.7億美元。

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

這是因為“安全心理”作祟：程序員直覺已信任上線的代碼是正確的，便直接復制過來用，不會再花時間自測，因為這是“對的”，“毋庸置疑”的。

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

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

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