程序員的日常三件事：寫bug、改bug、背鍋。連程序員都自我調(diào)侃道，為什么每天都在加班？因?yàn)槲业难劾锍：琤ug。
那么如何寫出一個(gè)讓（坑）人(王)很(之)難(王)發(fā)現(xiàn)的bug呢？
一、新手開發(fā)+新手測(cè)試=無敵巨坑
有一天凌晨，微信群里炸開了！用戶紛紛表示自己的業(yè)務(wù)數(shù)據(jù)離奇消失了！
大伙排查半天，原來是新來的小王埋的坑。他三個(gè)月前開發(fā)的定時(shí)任務(wù)出bug了！
那時(shí)剛來的小王刷刷地將代碼寫完后，手把手教新來的測(cè)試實(shí)習(xí)妹子怎樣測(cè)試這塊代碼，估計(jì)是妹子還沒搞清楚里面的邏輯時(shí)便稀里糊涂地將代碼上線了。
萬萬沒想到這bug隱藏這么久，由于錯(cuò)誤的邏輯導(dǎo)致錯(cuò)誤的數(shù)據(jù)，錯(cuò)誤的數(shù)據(jù)導(dǎo)致任務(wù)死循環(huán)執(zhí)行，當(dāng)執(zhí)行的時(shí)間過長(zhǎng)，到某個(gè)點(diǎn)時(shí)，系統(tǒng)如汽水開瓶般“砰”地崩了。
業(yè)務(wù)不熟導(dǎo)致邏輯理解有問題，是大部分新人都會(huì)存在的問題。此時(shí)最好安排個(gè)有經(jīng)驗(yàn)的測(cè)試“調(diào)教”下，降低bug發(fā)生率。
二、不考慮系統(tǒng)拓展性，怎么方便怎么寫！
史上最出名的“千年蟲”bug令全世界恐慌，甚至傳出“世界末日”的謠言。原因竟讓人啼笑皆非：當(dāng)時(shí)的程序員沒考慮到軟件會(huì)被使用至21世紀(jì)，為了節(jié)省內(nèi)存省略掉代表年份的前兩位數(shù)字”19”，或者默認(rèn)前兩位為”19”。
“千年蟲“千年一遇，可日常關(guān)于時(shí)間的低級(jí)bug經(jīng)常發(fā)生，而且通常等到一段時(shí)間后的某個(gè)特定時(shí)間點(diǎn)才暴露出來，讓人防不勝防。
例如正則只匹配了“16”，“17”年，等到18年零點(diǎn)到來問題才暴露。關(guān)于時(shí)間的bug非常多，大到閏年、夏令時(shí)、節(jié)假日、時(shí)區(qū)等，小到時(shí)間格式，每年都會(huì)碰到不小心遺漏的時(shí)間bug，所以很多公司對(duì)時(shí)間的通用測(cè)試用例就有許多條。
除了時(shí)間，程序員如果只考慮本次需求或者單個(gè)系統(tǒng)時(shí)，常常將字段設(shè)置不正確，后續(xù)業(yè)務(wù)拓展或者和別的系統(tǒng)交互時(shí)發(fā)現(xiàn)字段不夠用，只能修改字段長(zhǎng)度了。
三、不考慮上下游系統(tǒng)，招呼不打便隨意改接口
曾遇到A系統(tǒng)上線后，大伙回歸A系統(tǒng)正常運(yùn)行后，正樂滋滋地松一口氣之際，本來好端端運(yùn)行的B系統(tǒng)突然壞了，B組人吭哧吭哧地排查半天發(fā)現(xiàn)，原來是A提供的接口改了，B系統(tǒng)不兼容新接口。
大概程序員走過最長(zhǎng)的路便是背鍋之路了。
2005 年 12 月 8 日瑞穗證券的交易員因手誤輸入錯(cuò)的股價(jià)，2 分鐘后這人試圖通過交易軟件撤銷這筆賣單?？墒沁B續(xù)輸入 3 次撤單指令，都被東證的交易系統(tǒng)拒絕了。這次事故造成400 億日元的損失。
后來查明是交易系統(tǒng)出 bug了，程序員在 2000 年某次程序修改時(shí)不小心埋進(jìn)去的。
所以很多公司會(huì)嚴(yán)格要求在程序修改后必須經(jīng)過嚴(yán)格的回歸測(cè)試，來驗(yàn)證對(duì)其他業(yè)務(wù)流程有沒有影響。
四、復(fù)制、粘貼，我閉著眼，有bug看不見，debug了沒？
已發(fā)布已驗(yàn)證的代碼，是安全可靠的，是可以拿來即用的，無需質(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型火箭開發(fā)的，發(fā)射系統(tǒng)的代碼程序員也直接照搬4型的。該段代碼在4型火箭中被反復(fù)驗(yàn)證，但在5型卻沒有進(jìn)行驗(yàn)證。實(shí)際上4型的飛行條件和5型的飛行條件截然不同，最終導(dǎo)致事故發(fā)生，此次事故損失3.7億美元。
有測(cè)試工程師說，最害怕開發(fā)說這次沒啥改動(dòng)，跟線上某功能差不多。這時(shí)候反而要細(xì)心驗(yàn)證代碼的正確性。
這是因?yàn)椤鞍踩睦怼弊魉睿撼绦騿T直覺已信任上線的代碼是正確的，便直接復(fù)制過來用，不會(huì)再花時(shí)間自測(cè)，因?yàn)檫@是“對(duì)的”，“毋庸置疑”的。
據(jù)說每個(gè)不同角色看見bug的反應(yīng)是：
程序員花30分鐘寫程序，花2小時(shí)改bug。bug，子子孫孫無窮盡也。所以在面對(duì)測(cè)試人員的質(zhì)疑時(shí)，程序員們一定要保持鎮(zhèn)定，該甩鍋時(shí)速速甩掉：這是歷史問題，我沒動(dòng)過；剛剛在我這是好的，你環(huán)境配錯(cuò)了；你重啟試試……
最后一招是兩個(gè)字：我改！
