如何寫出沒有Bug的代碼？
1947年9月9日，美國海軍準將Grace Hopper在哈佛學院計算機實驗室里使用MarkII和MarkIII計算機進行研究工作。她的團隊跟蹤到MarkII上的一個錯誤，操作人員發現是由于一只飛蛾鉆到了MarkII的繼電器里導致的。
團隊清除了這只飛蛾，一切恢復正常。當時的工作人員記錄了這樣一句日志：“First actual case of bug being found.”這次著名的事件，猶如潘多拉打開了魔盒，從此，程序員的世界里，bug滿天飛。
▲世界上第一個bug
趣談：如何為bug找借口？
在我所擔任過的角色中，有一個崗位叫做Development Manager，通常簡稱DM。記得在一次基于一款平臺的二次開發項目中，因為bug實在太多，我們幾乎拿出了一整個里程碑的周期來debug，于是我這個DM有了新的解釋：Debug Man。
沒有人喜歡bug，bug意味著錯誤、不確定性、加班、交付風險……負面的詞語怎么堆砌都不冗余。隨便找個有過一、兩個項目經驗的開發者，問問他debug的回憶，那氣氛就跟上墳一樣。
對于bug，開發者的神經往往也很敏感。有個段子很有趣——說的是“應該如何向程序員反饋一個bug？”
你不能直接跟他說：“這里不對啊，是不是你程序有bug?。?rdquo;，要這么說的話，會直接被懟回來：“你丫的自己不會用吧！”。
你可以換個說法：“咦，這里好像不對，是我操作錯了嗎？”，這時程序員心里就一咯噔：“Shit...不會是我代碼有bug吧？”
從業多年，發現有個現象還蠻有趣的：有時候，當某個bug被發現時，犯下這個錯誤的始作俑者會開玩笑地為自己解脫：“誰沒寫過bug啊，Windows還有bug呢。”這句托詞我也用過，感覺挺好用的，就好比：梅西都能罰丟點球，我空門沒進，也是可以理解的嘛。
但其實吧……這邏輯經不起推敲的。
Windows操作系統，一款長達30多年，裝機量估計都超過了地球人口數量的巨型工程，復雜度基本只能靠猜。以微軟公布的資料來看：
- Windows95代碼量約1500萬行；
- WindowsXP代碼量約4500萬行；
- WindowsVista代碼量約5000萬行；
- Windows7代碼量5000+萬行。
以Windows7為例，超5000萬的代碼量，23個小組，共1000多人的開發團隊。如此規模下產生的bug，和一個在辦公室里上了1天班，寫了200行代碼，就鬧出一堆bug，搞得項目亂七八糟的，能同日而語嗎？最后再輕描淡寫地來句“微軟也有bug”，不害臊？
所以我后來不用這句了，如此開脫，水平太low。其替代方案容我稍后再講。
思考：我們能不能杜絕bug？
為了對抗bug，人們發明了各種各樣的工具和手段，上至方法論，下至生產工具。越來越先進的IDE，復雜的代碼審查制度，從單元測試到集成聯調，再配上beta版，試用，公測等等。凡此種種，其目標無一不是消滅bug?？蛇@些琳瑯滿目的解決方案的存在，反倒證明了一個悲?。喝祟?，實在是太容易犯錯了。
如果說凡事都有正反兩面的意義，那么bug的正能量就是硬生生造就了大量就業機會，進而維護了社會穩定。
那么，為什么我們總是無法避免bug的產生？我們能不能杜絕bug？
答案當然是不可能了。因為那樣一來，程序員的日子豈不是太舒服了？不符合苦逼的定位。而且，我們所處的這個世界，但凡越是高呼要消滅的東西，越是會普遍地存在。就像蒼蠅、蚊蟲、污染、犯罪、戰爭，不一而足。
按照常識，經驗越豐富的老手寫出來的代碼，一次通過的幾率更高，比如他們思考得會更周全，對異常的判斷和處理更老練，邊界條件把握得更精確，等等。
所以我們可能會幻想：是不是只要我們足夠仔細，并努力磨練技藝，通過讓一部分碼農先老練起來，然后實現共同老練，最終就可以達到全世界開發者聯合起來消滅bug的大解放了？
很遺憾，這只是一個治標不治本的思路，因為bug是有階級的。老手們的bug相對少，只是低級錯誤少，他們也會遇到bug，而他們的bug，往往都是一眼蒙逼的難度系數N.x的難題，不發生在代碼層面，大多在業務層面，甚至需求設計層面，或者直接是一些不可抗拒因素（做過政府項目嗎？）。
總之，萌新有萌新們的秀逗，大叔有大叔們的短路，老桿也會有自己的滑鐵盧。
bug還是feature request？
bug這個概念的起源，就預示著它的不可避免性。世界上第一個bug是一只飛蛾，這劇本，誰能料到？某種意義上說，bug就是不可預見的錯誤，能被預估并且提前做好準備的，那叫exception，try catch是他們的朋友。
對于為什么會產生bug的原因，著名的荷蘭計算機科學家Edsger W.Dijkstra有過一句經典名言：
If debugging is the process of removing software bugs，then programming must be the process of putting the min.
這就是上文提到的那句托詞“Windows也有bug。”的替代方案。:)
設想一下，當你從無到有的寫下一句句代碼時，中間的任意一個時刻，你的程序都是運行不起來的，至少也是達不到目標效果的。從效用上完全等效于充滿bug的一堆代碼。你可能會辯解，程序還沒寫完呢，只是功能還沒實現，并沒有bug。
事實上，換位思考一下，缺失某個功能和包含一個有故障的功能，對于用戶而言，都是無用的。一個處于開發階段尚沒寫完的代碼和開發結束但寫得有缺陷的代碼，是一回事。
由此可以引申出一個著名的命題：That's not a bug，it's a feature request.
有時候，我們很難分清楚一個問題到底屬于bug還是feature request。文中作者拋出了一個案例：用Visual Studio構建一個Windows GUI程序時沒有采用系統默認字體。這個算不算一個bug呢？
不好說。畢竟，隨著軟件應用越來越普及、越來越追求所謂人性化的趨勢，傳統意義上的只要程序能運行就不算bug的觀點，也在慢慢發生改變。對于一個強迫癌用戶來說，UI上有缺陷，那基本上整個軟件就不能用了。
事實上，在當今各類app競爭白熱化、同質化的時代，用戶體驗上的問題，往往是致命的。以前大家沒得選，所以沒那么挑剔，只要程序能干活就行了。如今的計算機用戶已經被寵壞了，在這樣的時代下，bug早已悄悄地泛化了。
所以，到底如何才能寫出沒有bug的代碼呢？
答案：不寫代碼。
一個悲觀又絕望卻正確的唯一解。
盡可能少寫代碼
試著在這絕望里挖掘一點希望吧。這個答案隱含了一個方法論：盡可能少寫代碼。因為Dijkstra大師已經說得很清楚了，編程就是制造bug的過程。
那么，代碼寫的越少，犯錯的幾率就越小，這個道理顯而易見。維護一段300行的代碼，我們很容易有信心；接手一段3000行的代碼，什么反應就看各人素質了。
現代的開發方式也都包含有這個思路，從IDE的智能提示，代碼補全功能，到每門語言都會有的各種“21天從入門到精通”的開發框架，以及很多實戰層面的約定俗成，都是在幫助開發者減少不必要的編碼?？蚣芑?、規范化思維能降低出錯的可能性。
事實上，就連編程語言本身的歷史發展都是按照這個思路在進行。從底層的匯編語言，到C/C++，再到Java/C#/Python……等各種高級語言，語言演化的目的之一就是為了把程序員從臟活、累活的工作中解放出來。
“不要重復造輪子”的精神，一方面是在指導我們提高效率，不要重復勞動成本，另一方面也是減少重復犯錯的幾率。
當代Web開發中的各種包管理概念正深刻地踐行著這條精神，以至于在2016年3月爆發了著名的NPM&left-pad事件：一段區區11行的字符串填充函數模塊，被全世界依賴，結果作者Azer下架模塊包的那一天，全球前端大崩潰。受波及的產品和團隊中，甚至包含著名的React！
這個事件讓人們開始反思：我們是不是忘了該如何編程了？一個功能簡單到人人都會寫的函數，卻都不約而同地選擇引入，而不是自己實現。最終，過猶不及。
寫代碼，真的很難。NO BUG，NO CODE。
為什么要追求無bug呢？
可是，如果真的只能不寫代碼了，那么本身就已經沒有女朋友的程序員們，現在連代碼也沒有了，這還讓不讓人活了？
不能這樣把程序員們給逼死了，要講人權。
有時候，當答案實在不可接受的時候，我們就該思考是不是問題問錯了。
所以，換個角度，為什么要追求無bug呢？也許我們根本就沒必要害怕bug。
有bug的地方就有麻煩，有麻煩就有解決麻煩的需要，客戶就是給那些能解決麻煩事的人支付報酬的。只處理簡單的問題，是沒有價值的，市場只認可那些面對困難能提供解決方案的人。簡單來講，想賺錢，就別怕麻煩。
對于客戶來說，不管是bug或是feature request，都是一個需要解決的問題。一個優秀的PM，可以把客戶反饋的bug，包裝成feature request，返回一套解決方案。然后，優秀的商務代表出馬，簽訂補充協議。恭喜，你們的項目經費增加了一點點。
英格蘭有句諺語：Where there's muck，there's brass。
如此看來，“如何寫出沒有BUG的代碼？”這問題，恐怕確實問錯了。
