如何寫(xiě)出沒(méi)有Bug的代碼？
1947年9月9日，美國(guó)海軍準(zhǔn)將Grace Hopper在哈佛學(xué)院計(jì)算機(jī)實(shí)驗(yàn)室里使用MarkII和MarkIII計(jì)算機(jī)進(jìn)行研究工作。她的團(tuán)隊(duì)跟蹤到MarkII上的一個(gè)錯(cuò)誤，操作人員發(fā)現(xiàn)是由于一只飛蛾鉆到了MarkII的繼電器里導(dǎo)致的。
團(tuán)隊(duì)清除了這只飛蛾，一切恢復(fù)正常。當(dāng)時(shí)的工作人員記錄了這樣一句日志：“First actual case of bug being found.”這次著名的事件，猶如潘多拉打開(kāi)了魔盒，從此，程序員的世界里，bug滿(mǎn)天飛。
▲世界上第一個(gè)bug
趣談：如何為bug找借口？
在我所擔(dān)任過(guò)的角色中，有一個(gè)崗位叫做Development Manager，通常簡(jiǎn)稱(chēng)DM。記得在一次基于一款平臺(tái)的二次開(kāi)發(fā)項(xiàng)目中，因?yàn)閎ug實(shí)在太多，我們幾乎拿出了一整個(gè)里程碑的周期來(lái)debug，于是我這個(gè)DM有了新的解釋?zhuān)篋ebug 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à)，會(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)看：
- Windows95代碼量約1500萬(wàn)行；
- WindowsXP代碼量約4500萬(wàn)行；
- WindowsVista代碼量約5000萬(wàn)行；
- Windows7代碼量5000+萬(wàn)行。
以Windows7為例，超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。其替代方案容我稍后再講。
思考：我們能不能杜絕bug？
為了對(duì)抗bug，人們發(fā)明了各種各樣的工具和手段，上至方法論，下至生產(chǎn)工具。越來(lái)越先進(jìn)的IDE，復(fù)雜的代碼審查制度，從單元測(cè)試到集成聯(lián)調(diào)，再配上beta版，試用，公測(cè)等等。凡此種種，其目標(biāo)無(wú)一不是消滅bug?？蛇@些琳瑯滿(mǎn)目的解決方案的存在，反倒證明了一個(gè)悲劇：人類(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還是feature request？
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 the min.
這就是上文提到的那句托詞“Windows也有bug。”的替代方案。:)
設(shè)想一下，當(dāng)你從無(wú)到有的寫(xiě)下一句句代碼時(shí)，中間的任意一個(gè)時(shí)刻，你的程序都是運(yùn)行不起來(lái)的，至少也是達(dá)不到目標(biāo)效果的。從效用上完全等效于充滿(mǎn)bug的一堆代碼。你可能會(huì)辯解，程序還沒(méi)寫(xiě)完呢，只是功能還沒(méi)實(shí)現(xiàn)，并沒(méi)有bug。
事實(shí)上，換位思考一下，缺失某個(gè)功能和包含一個(gè)有故障的功能，對(duì)于用戶(hù)而言，都是無(wú)用的。一個(gè)處于開(kāi)發(fā)階段尚沒(méi)寫(xiě)完的代碼和開(kāi)發(fā)結(jié)束但寫(xiě)得有缺陷的代碼，是一回事。
由此可以引申出一個(gè)著名的命題：That's not a bug，it's 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)迫癌用戶(hù)來(lái)說(shuō)，UI上有缺陷，那基本上整個(gè)軟件就不能用了。
事實(shí)上，在當(dāng)今各類(lèi)app競(jìng)爭(zhēng)白熱化、同質(zhì)化的時(shí)代，用戶(hù)體驗(yàn)上的問(wèn)題，往往是致命的。以前大家沒(méi)得選，所以沒(méi)那么挑剔，只要程序能干活就行了。如今的計(jì)算機(jī)用戶(hù)已經(jīng)被寵壞了，在這樣的時(shí)代下，bug早已悄悄地泛化了。
所以，到底如何才能寫(xiě)出沒(méi)有bug的代碼呢？
答案：不寫(xiě)代碼。
一個(gè)悲觀又絕望卻正確的唯一解。
盡可能少寫(xiě)代碼
試著在這絕望里挖掘一點(diǎn)希望吧。這個(gè)答案隱含了一個(gè)方法論：盡可能少寫(xiě)代碼。因?yàn)镈ijkstra大師已經(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ù)模塊，被全世界依賴(lài)，結(jié)果作者Azer下架模塊包的那一天，全球前端大崩潰。受波及的產(chǎn)品和團(tuán)隊(duì)中，甚至包含著名的React！
這個(gè)事件讓人們開(kāi)始反思：我們是不是忘了該如何編程了？一個(gè)功能簡(jiǎn)單到人人都會(huì)寫(xiě)的函數(shù)，卻都不約而同地選擇引入，而不是自己實(shí)現(xiàn)。最終，過(guò)猶不及。
寫(xiě)代碼，真的很難。NO BUG，NO CODE。
為什么要追求無(wú)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的地方就有麻煩，有麻煩就有解決麻煩的需要，客戶(hù)就是給那些能解決麻煩事的人支付報(bào)酬的。只處理簡(jiǎn)單的問(wèn)題，是沒(méi)有價(jià)值的，市場(chǎng)只認(rèn)可那些面對(duì)困難能提供解決方案的人。簡(jiǎn)單來(lái)講，想賺錢(qián)，就別怕麻煩。
對(duì)于客戶(hù)來(lái)說(shuō)，不管是bug或是feature request，都是一個(gè)需要解決的問(wèn)題。一個(gè)優(yōu)秀的PM，可以把客戶(hù)反饋的bug，包裝成feature request，返回一套解決方案。然后，優(yōu)秀的商務(wù)代表出馬，簽訂補(bǔ)充協(xié)議。恭喜，你們的項(xiàng)目經(jīng)費(fèi)增加了一點(diǎn)點(diǎn)。
英格蘭有句諺語(yǔ)：Where there's muck，there's brass。
如此看來(lái)，“如何寫(xiě)出沒(méi)有BUG的代碼？”這問(wèn)題，恐怕確實(shí)問(wèn)錯(cuò)了。
