導讀：當談論bug時我們究竟談論的是什么？

作者：馬克斯·卡納特-亞歷山大（Max Kanat-Alexander）

來源：大數據DT（ID：hzdashuju）

01 什么是bug

相信絕大部分程序員都聽說過這個故事：曾經真的有人在計算機里找到了一只昆蟲，正是這只昆蟲導致了計算機程序運行出現了錯誤。（但真實情況是，人們在那之前就已經把程序的異常行為稱為bug了，但因為這則故事富有趣味，所以一直被人們津津樂道。）

但說真的，當談論bug時我們究竟談論的是什么？

這里是關于bug的精確定義：

程序的行為并沒有符合程序員的預期。

程序員的預期沒有滿足絕大部分理性用戶的期望。

通常來說只要程序能夠嚴格執行程序員給出的指令，它就可以算是處于正常工作的狀態。但有時候程序員期望程序執行的行為會出乎普通用戶的意料，甚至給他們帶來麻煩，所以這也算是一類bug。

其他軟件功能上的不足都可以歸納到新功能需求中。如果說程序的工作狀態的確與我們期望的一致，但離用戶期望還有差距，則意味著它需要新“功能”。“功能”和“bug”定義之間的區別也就在這。

請注意硬件也可能產生bug。程序員不太可能發出“讓計算機爆炸”這類的指令。如果程序員編寫了一段程序導致了計算機真的爆炸了，這很有可能是硬件bug引起的。硬件中當然可能存在某些bug，但應該不會是如此夸張的這種。

本質上說，任何導致程序員指令沒有被正確執行的故障，都可以被認為是bug，除非程序員打算讓計算機做一些它本不應該去做的事情。

舉個例子，如果程序員告訴計算機去“統治整個世界”，但是它本身就不是被設計用來統治世界的，那就意味著計算機需要一個新的“統治整個世界”的功能。這也就算不上是一個bug。

• 硬件

至于硬件，你應該同時考慮到硬件設計者的預期，以及大部分程序員的對于它們的期望。從這個層面上說，程序員其實是主要的“用戶”，硬件設計者則是需要考慮程序員預期的人。

當然，我們也應該關心普通用戶的期望，特別是針對那些普通用戶會與之打交道的硬件設備，比如打印機、顯示器和鍵盤等。

02 bug的源頭

bug來自哪里？我們能把所有bug的成因范圍縮小至一個或者幾個之內嗎？答案是肯定的。

bug通常來自開發者嘗試降低代碼復雜性未果而產生的副作用。也有部分來自對其實簡單的代碼產生的誤解。

除了一些拼寫錯誤以外，我能十分肯定以上兩點基本就是所有bug產生的根本原因，盡管我還沒有進行深入的研究來證明這件事。

復雜的事物容易引起用戶的誤操作。想象一下一個黑色盒子，上面有上百萬個沒有任何標識的按鈕，而其中的16個按鈕按下之后會毀滅整個世界，那么使用這個盒子的人中注定有人會一不小心讓毀滅降臨。在編程中也存在類似的情況，如果你無法輕易理解編程語言的文檔，或者是這門語言本身，你就或多或少存在錯誤使用它的可能。

說真的，就那個長滿上百萬個沒有標識按鈕的盒子而言，正確的使用方式不可能存在。你永遠也不可能弄清正確的方式是什么，即使你計劃閱讀完1000頁的說明書，也不一定能記住能夠幫助你正確使用盒子的整套流程。

同樣的道理，只要你讓事物變得足夠復雜，人們就會傾向于用錯誤的而不是正確的方式使用它。如果你把50、100或者1000個這類的復雜組件拼裝在一起，無論由多聰明的工程師來進行拼裝，它們也永遠無法正常工作。

所以你開始明白bug來自哪里了吧？你每引入一絲復雜性，開發者（這里的“開發者”甚至包括你自己）誤用你的代碼的概率就高一分。

一旦代碼的意圖和使用方法變得極不明確，就會讓使用這份代碼的人犯錯。又因為你的代碼和其他的代碼混合在了一起，導致了開發者誤用和犯錯的可能性大大增加。而后這些代碼又會繼續和其他的代碼混合，形成惡性循環。

• 復雜性的構成

硬件設計者將硬件制造得極為復雜的情況時常發生。所以它必須與復雜的匯編編程語言集成。而這又使得匯編語言和編譯器同樣復雜起來。當你遇到這種情況時，如果你不提前對程序進行精妙的設計或者全方位的測試的話，基本上無法避免bug的發生。只要你的設計不夠完美，那么在運行的一瞬間，大量的bug就會涌現出來。

站在其他程序員的視角看這件事也很重要。畢竟有些事對你來說很簡單，但是對其他人來說或許很復雜。

如果你想要感同身受地體驗一下其他人看不懂你的代碼的感受，你可以找一份你從沒有使用過的類庫的文檔來閱讀看看。

也可以找一些你從沒有閱讀過的代碼來閱讀。嘗試理解整段程序而不是單行代碼的含義，并且想象當你需要對它進行修改時應該從哪里入手。這些都是其他人閱讀你代碼時的體驗。你大概注意到在閱讀他人代碼時，即使并不復雜的代碼也足以讓人產生挫敗感。

現在我們考慮另一種程序員誤解簡單代碼的情況。這也是需要額外小心的另一件事。如果你察覺到某位程序員在向你解釋一段代碼時敘述得牛頭不對馬嘴，那便意味著他應該是誤解了代碼中的某些內容。當然如果他正在研究的領域極其復雜，也情有可原，可能需要他讀到博士學位才能完全掌握它。

這兩個方面是緊密關聯的。當你編寫代碼時，需要承擔的部分職責是讓將來閱讀你代碼的程序員理解它，并且是很輕松地就能理解。如果你確實是這么做的，但是他在閱讀過程中仍然產生了嚴重誤解——或許他根本就不明白“if”語句是什么含義。那應該就與你無關了。

假設將來那些閱讀你代碼的程序員，對編程的基本原理和正在使用的編程語言語法都略知一二，在這個前提下你的職責是寫出整潔的代碼。

所以最后可以總結出幾條有趣的原則：

你寫的代碼越簡單，bug就越少。

你應該始終想方設法去簡化程序中的代碼。

關于作者：馬克斯·卡納特-亞歷山大（Max Kanat-Alexander）是谷歌的代碼健康技術主管，主要幫助其他軟件工程師提高生產力，包括編寫開發工具、創建教育程序、指導重構工作等。他還曾在谷歌擔任YouTubeXbox的技術主管，從事Java JDK、JVM和Java其他方面的工作，以及擔任YouTube的工程實踐技術主管，他在YouTube上為所有開發人員提供最佳實踐和工程開發效率方面的支持。

本文摘編自《編程原則：來自代碼大師Max Kanat-Alexander的建議》，經出版方授權發布。

延伸閱讀《編程原則》

點擊上圖了解及購買

轉載請聯系微信：DoctorData

推薦語：Google代碼健康技術主管、編程大師Max Kanat-Alexander又一力作，聚焦于適用于所有程序開發人員的原則，從新的角度來看待軟件開發過程，幫助你在工作中避免復雜，擁抱簡約。

延伸閱讀《深入理解計算機系統》

點擊上圖了解及購買

轉載請聯系微信：DoctorData

推薦語：卡內基梅隆大學計算機學院院長兼美國4大機構院士撰寫，暢銷全球40余國，中文版售逾30萬冊。

劃重點????

干貨直達????

• 吐血整理：人工智能、機器學習領域13個常見概念
  

• 多圖詳解邊緣計算系統的組成及概念
  

• 中國提出碳中和，到底能得到什么好處？（真想不到！）
  

• 什么是數據產品經理？需要什么能力？有哪些相關書籍可以讀？

更多精彩????

在公眾號對話框輸入以下關鍵詞

查看更多優質內容！

讀書?|?書單?|?干貨?|?講明白?|?神操作?|?手把手

大數據?|?云計算?|?數據庫?|?Python?|?爬蟲?|?可視化

AI?|?人工智能?|?機器學習?|?深度學習?|?NLP

5G?|?中臺?|?用戶畫像?|?數學?|?算法?|?數字孿生

據統計，99%的大咖都關注了這個公眾號

????

總結

以上是生活随笔為你收集整理的为什么你一直在写bug？原因找到了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。