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