1947年9月9日，美國(guó)海軍準(zhǔn)將 Grace Hopper 在哈佛學(xué)院計(jì)算機(jī)實(shí)驗(yàn)室里使用 Mark II 和 Mark III 計(jì)算機(jī)進(jìn)行研究工作。她的團(tuán)隊(duì)跟蹤到 Mark II 上的一個(gè)錯(cuò)誤，操作人員發(fā)現(xiàn)是由于一只飛蛾鉆到了 Mark II 的繼電器里導(dǎo)致的。團(tuán)隊(duì)清除了這只飛蛾，一切恢復(fù)正常。當(dāng)時(shí)的工作人員記錄了這樣一句日志：" First actual case of bug being found. "  這次著名的事件，猶如潘多拉打開(kāi)了魔盒，從此，程序員的世界里，bug 滿天飛。

世界上第一個(gè) bug

在我所擔(dān)任過(guò)的角色中，有一個(gè)崗位叫做 Development Manager，通常簡(jiǎn)稱 DM. 記得在一次基于一款平臺(tái)的二次開(kāi)發(fā)項(xiàng)目中，因?yàn)?bug 實(shí)在太多，我們幾乎拿出了一整個(gè)里程碑的周期來(lái) debug，于是我這個(gè)DM有了新的解釋：Debug Man.

　　沒(méi)有人喜歡 bug，bug 意味著錯(cuò)誤、不確定性、加班、交付風(fēng)險(xiǎn)，等等…… 負(fù)面的詞語(yǔ)怎么堆砌都不冗余。隨便找個(gè)有過(guò)一、兩個(gè)項(xiàng)目經(jīng)驗(yàn)的開(kāi)發(fā)者，問(wèn)問(wèn)他 debug 的回憶，那氣氛就跟上墳一樣。

　　對(duì)于 bug，開(kāi)發(fā)者的神經(jīng)往往也很敏感。有個(gè)段子很有趣 —— 說(shuō)的是“應(yīng)該如何向程序員反饋一個(gè) bug ” ——

　　你不能直接跟他說(shuō)：“這里不對(duì)啊，是不是你程序有 bug ??？”，要這么說(shuō)的話，會(huì)直接被懟回來(lái)：“你丫的自己不會(huì)用吧！”。

　　你可以換個(gè)說(shuō)法：“咦，這里好像不對(duì)，是我操作錯(cuò)了嗎？”，這時(shí)程序員心里就一咯噔：“Shit.. 不會(huì)是我代碼有 bug 吧？”

　　從業(yè)多年，發(fā)現(xiàn)有個(gè)現(xiàn)象還蠻有趣的：有時(shí)候，當(dāng)某個(gè) bug 被發(fā)現(xiàn)時(shí)，犯下這個(gè)錯(cuò)誤的始作俑者會(huì)開(kāi)玩笑地為自己解脫：“誰(shuí)沒(méi)寫(xiě)過(guò) bug 啊，Windows 還有 bug 呢?！?這句托詞我也用過(guò)，感覺(jué)挺好用的，就好比：梅西都能罰丟點(diǎn)球，我空門(mén)沒(méi)進(jìn)，也是可以理解的嘛。

　　但其實(shí)吧…… 這邏輯經(jīng)不起推敲的。

　　Windows 操作系統(tǒng)，一款長(zhǎng)達(dá)30多年，裝機(jī)量估計(jì)都超過(guò)了地球人口數(shù)量的巨型工程，復(fù)雜度基本只能靠猜。以微軟公布的資料來(lái)看：

　　Windows 95 代碼量約 1500 萬(wàn)行
　　Windows XP 代碼量約 4500 萬(wàn)行
　　Windows Vista 代碼量約 5000 萬(wàn)行
　　Windows 7 代碼量 5000+ 萬(wàn)行

　　以 Windows 7 為例，超5000萬(wàn)的代碼量，23個(gè)小組，共1000多人的開(kāi)發(fā)團(tuán)隊(duì)。如此規(guī)模下產(chǎn)生的bug，和一個(gè)在辦公室里上了1天班，寫(xiě)了200行代碼，就鬧出一堆bug，搞得項(xiàng)目亂七八糟的，能同日而語(yǔ)嗎？最后再輕描淡寫(xiě)地來(lái)句 “微軟也有 bug ”，不害臊？

　　所以我后來(lái)不用這句了，如此開(kāi)脫，水平太low。其替代方案容我稍后再講。

為了對(duì)抗 bug，人們發(fā)明了各種各樣的工具和手段，上至方法論，下至生產(chǎn)工具。越來(lái)越先進(jìn)的 IDE, 復(fù)雜的代碼審查制度，從單元測(cè)試到集成聯(lián)調(diào)，再配上 beta 版，試用，公測(cè)，等等。凡此種種，其目標(biāo)無(wú)一不是消滅 bug ?？蛇@些琳瑯滿目的解決方案的存在，反倒證明了一個(gè)悲?。?strong style="margin:0px;padding:0px;">人類(lèi)，實(shí)在是太容易犯錯(cuò)了。

　　如果說(shuō)凡事都有正反兩面的意義，那么 bug 的正能量就是硬生生造就了大量就業(yè)機(jī)會(huì)，進(jìn)而維護(hù)了社會(huì)穩(wěn)定。

　　那么，為什么我們總是無(wú)法避免 bug 的產(chǎn)生？我們能不能杜絕 bug ？

　　答案當(dāng)然是不可能了。因?yàn)槟菢右粊?lái)，程序員的日子豈不是太舒服了？不符合苦逼的定位。而且，我們所處的這個(gè)世界，但凡越是高呼要消滅的東西，越是會(huì)普遍地存在。就像蒼蠅、蚊蟲(chóng)、污染、犯罪、戰(zhàn)爭(zhēng)，不一而足。

　　按照常識(shí)，經(jīng)驗(yàn)越豐富的老手寫(xiě)出來(lái)的代碼，一次通過(guò)的幾率更高，比如他們思考得會(huì)更周全，對(duì)異常的判斷和處理更老練，邊界條件把握得更精確，等等。所以我們可能會(huì)幻想：是不是只要我們足夠仔細(xì)，并努力磨練技藝，通過(guò)讓一部分碼農(nóng)先老練起來(lái)，然后實(shí)現(xiàn)共同老練，最終就可以達(dá)到全世界開(kāi)發(fā)者聯(lián)合起來(lái)消滅bug的大解放了？

　　很遺憾，這只是一個(gè)治標(biāo)不治本的思路，因?yàn)閎ug是有階級(jí)的。老手們的bug相對(duì)少，只是低級(jí)錯(cuò)誤少，他們也會(huì)遇到bug，而他們的bug，往往都是一眼蒙逼的難度系數(shù)N.x的難題，不發(fā)生在代碼層面，大多在業(yè)務(wù)層面，甚至需求設(shè)計(jì)層面，或者直接是一些不可抗拒因素（做過(guò)政府項(xiàng)目嗎？）?？傊?，萌新有萌新們的秀逗，大叔有大叔們的短路，老桿也會(huì)有自己的滑鐵盧。

　　bug 這個(gè)概念的起源，就預(yù)示著它的不可避免性。世界上第一個(gè) bug 是一只飛蛾，這劇本，誰(shuí)能料到？某種意義上說(shuō)，bug 就是不可預(yù)見(jiàn)的錯(cuò)誤，能被預(yù)估并且提前做好準(zhǔn)備的，那叫 exception， try catch 是他們的朋友。

　　對(duì)于為什么會(huì)產(chǎn)生 bug 的原因，著名的荷蘭計(jì)算機(jī)科學(xué)家 Edsger W. Dijkstra 有過(guò)一句經(jīng)典名言：

　　If debugging is the process of removing software bugs, 

      then programming must be the process of putting them in.

　　這就是上文提到的那句托詞 “ Windows 也有 bug. ” 的替代方案。:)

　　設(shè)想一下，當(dāng)你從無(wú)到有的寫(xiě)下一句句代碼時(shí)，中間的任意一個(gè)時(shí)刻，你的程序都是運(yùn)行不起來(lái)的，至少也是達(dá)不到目標(biāo)效果的。從效用上完全等效于充滿 bug 的一堆代碼。你可能會(huì)辯解，程序還沒(méi)寫(xiě)完呢，只是功能還沒(méi)實(shí)現(xiàn)，并沒(méi)有 bug 。事實(shí)上，換位思考一下，缺失某個(gè)功能和包含一個(gè)有故障的功能，對(duì)于用戶而言，都是無(wú)用的。一個(gè)處于開(kāi)發(fā)階段尚沒(méi)寫(xiě)完的代碼和開(kāi)發(fā)結(jié)束但寫(xiě)得有缺陷的代碼，是一回事。

　　由此可以引申出了一個(gè)著名的命題： 

　　Thats not a bug, its a feature request.　

　　有時(shí)候，我們很難分清楚一個(gè)問(wèn)題到底屬于 bug 還是 feature request . 文中作者拋出了一個(gè)案例：用 Visual Studio 構(gòu)建一個(gè) Windows GUI 程序時(shí)沒(méi)有采用系統(tǒng)默認(rèn)字體。這個(gè)算不算一個(gè) bug 呢？

　　不好說(shuō)。畢竟，隨著軟件應(yīng)用越來(lái)越普及、越來(lái)越追求所謂人性化的趨勢(shì)，傳統(tǒng)意義上的只要程序能運(yùn)行就不算 bug 的觀點(diǎn)，也在慢慢發(fā)生改變。對(duì)于一個(gè)強(qiáng)迫癌用戶來(lái)說(shuō)，UI 上有缺陷，那基本上整個(gè)軟件就不能用了。事實(shí)上，在當(dāng)今各類(lèi) app 競(jìng)爭(zhēng)白熱化、同質(zhì)化的時(shí)代，用戶體驗(yàn)上的問(wèn)題，往往是致命的。以前大家沒(méi)得選，所以沒(méi)那么挑剔，只要程序能干活就行了。如今的計(jì)算機(jī)用戶已經(jīng)被寵壞了，在這樣的時(shí)代下，bug 早已悄悄地泛化了。

所以，到底如何才能寫(xiě)出沒(méi)有 bug 的代碼呢？

　　答案: 不寫(xiě)代碼。

　　一個(gè)悲觀又絕望卻正確的唯一解。

　　試著在這絕望里挖掘一點(diǎn)希望吧。這個(gè)答案隱含了一個(gè)方法論: 盡可能少寫(xiě)代碼。因?yàn)?Dijkstra 大師已經(jīng)說(shuō)得很清楚了，編程就是制造 bug 的過(guò)程。那么，代碼寫(xiě)的越少，犯錯(cuò)的幾率就越小，這個(gè)道理顯而易見(jiàn)。維護(hù)一段300行的代碼，我們很容易有信心；接手一段3000行的代碼，什么反應(yīng)就看各人素質(zhì)了。

　　現(xiàn)代的開(kāi)發(fā)方式也都包含有這個(gè)思路，從 IDE 的智能提示，代碼補(bǔ)全功能，到每門(mén)語(yǔ)言都會(huì)有的各種“21天從入門(mén)到精通”的開(kāi)發(fā)框架，以及很多實(shí)戰(zhàn)層面的約定俗成，都是在幫助開(kāi)發(fā)者減少不必要的編碼?？蚣芑⒁?guī)范化思維能降低出錯(cuò)的可能性。

　　事實(shí)上，就連編程語(yǔ)言本身的歷史發(fā)展都是按照這個(gè)思路在進(jìn)行。從底層的匯編語(yǔ)言，到C/C++，再到Java/C#/Python……等各種高級(jí)語(yǔ)言，語(yǔ)言演化的目的之一就是為了把程序員從臟活、累活的工作中解放出來(lái)。

　　“不要重復(fù)造輪子”的精神，一方面是在指導(dǎo)我們提高效率，不要重復(fù)勞動(dòng)成本，另一方面也是減少重復(fù)犯錯(cuò)的幾率。

　　當(dāng)代 Web 開(kāi)發(fā)中的各種包管理概念正深刻地踐行著這條精神，以至于在2016年3月爆發(fā)了著名的 NPM & left-pad 事件: 一段區(qū)區(qū)11行的字符串填充函數(shù)模塊，被全世界依賴，結(jié)果作者 Azer 下架模塊包的那一天，全球前端大崩潰。受波及的產(chǎn)品和團(tuán)隊(duì)中，甚至包含著名的 React ！

　　這個(gè)事件讓人們開(kāi)始反思：我們是不是忘了該如何編程了？ 一個(gè)功能簡(jiǎn)單到人人都會(huì)寫(xiě)的函數(shù)，卻都不約而同地選擇引入，而不是自己實(shí)現(xiàn)。最終，過(guò)猶不及。 

　　寫(xiě)代碼，真的很難。

　NO CODE , NO BUG .

可是，如果真的只能不寫(xiě)代碼了，那么本身就已經(jīng)沒(méi)有女朋友的程序員們，現(xiàn)在連代碼也沒(méi)有了，這還讓不讓人活了？

　　不能這樣把程序員們給逼死了，要講人權(quán)。

　　有時(shí)候，當(dāng)答案實(shí)在不可接受的時(shí)候，我們就該思考是不是問(wèn)題問(wèn)錯(cuò)了。

　　所以，換個(gè)角度，為什么要追求無(wú) bug 呢？也許我們根本就沒(méi)必要害怕 bug.

　　有 bug 的地方就有麻煩，有麻煩就有解決麻煩的需要，客戶就是給那些能解決麻煩事的人支付報(bào)酬的。只處理簡(jiǎn)單的問(wèn)題，是沒(méi)有價(jià)值的，市場(chǎng)只認(rèn)可那些面對(duì)困難能提供解決方案的人。簡(jiǎn)單來(lái)講，想賺錢(qián)，就別怕麻煩。

　　對(duì)于客戶來(lái)說(shuō)，不管是 bug 或是 feature request，都是一個(gè)需要解決的問(wèn)題。一個(gè)優(yōu)秀的PM，可以把客戶反饋的 bug，包裝成 feature request，返回一套解決方案。然后，優(yōu)秀的商務(wù)代表出馬，簽訂補(bǔ)充協(xié)議。恭喜，你們的項(xiàng)目經(jīng)費(fèi)增加了一點(diǎn)點(diǎn)。

　　英格蘭有句諺語(yǔ)：

　　Where theres muck, theres brass.

　　如此看來(lái)，“ 如何寫(xiě)出沒(méi)有BUG的代碼？” 這問(wèn)題，恐怕確實(shí)問(wèn)錯(cuò)了。