為什么你一直在寫bug

1、01什么是bug相信絕大部分程序員都聽說過這個(gè)故事：曾經(jīng)真的有人在計(jì)算機(jī)里找到了一只昆蟲，正是這只昆蟲導(dǎo)致了計(jì)算機(jī)程序運(yùn)行出現(xiàn)了錯(cuò)誤。（但真實(shí)情況是，人們在那之前就已經(jīng)把程序的異常行為稱為bug了，但因?yàn)檫@則故事富有趣味，所以一直被人們津津樂道。）但說真的，當(dāng)談?wù)揵ug時(shí)我們究竟談?wù)摰氖鞘裁矗窟@里是關(guān)于bug的精確定義：程序的行為并沒有符合程序員的預(yù)期。程序員的預(yù)期沒有滿足絕大部分理性用戶的期望。通常來說只要程序能夠嚴(yán)格執(zhí)行程序員給出的指令，它就可以算是處于正常工作的狀態(tài)。但有時(shí)候程序員期望程序執(zhí)行的行為會出乎普通用戶的意料，甚至給他們帶來麻煩，所以這也算是一類bug。其他軟件功能上的不足都可

2、以歸納到新功能需求中。如果說程序的工作狀態(tài)的確與我們期望的一致，但離用戶期望還有差距，則意味著它需要新“功能”。“功能”和“bug”定義之間的區(qū)別也就在這。請注意硬件也可能產(chǎn)生bug。程序員不太可能發(fā)出“讓計(jì)算機(jī)爆炸”這類的指令。如果程序員編寫了一段程序?qū)е铝擞?jì)算機(jī)真的爆炸了，這很有可能是硬件bug引起的。硬件中當(dāng)然可能存在某些bug，但應(yīng)該不會是如此夸張的這種。本質(zhì)上說，任何導(dǎo)致程序員指令沒有被正確執(zhí)行的故障，都可以被認(rèn)為是bug，除非程序員打算讓計(jì)算機(jī)做一些它本不應(yīng)該去做的事情。舉個(gè)例子，如果程序員告訴計(jì)算機(jī)去“統(tǒng)治整個(gè)世界”，但是它本身就不是被設(shè)計(jì)用來統(tǒng)治世界的，那就意味著計(jì)算機(jī)需要一個(gè)

3、新的“統(tǒng)治整個(gè)世界”的功能。這也就算不上是一個(gè)bug。硬件至于硬件，你應(yīng)該同時(shí)考慮到硬件設(shè)計(jì)者的預(yù)期，以及大部分程序員的對于它們的期望。從這個(gè)層面上說，程序員其實(shí)是主要的“用戶”，硬件設(shè)計(jì)者則是需要考慮程序員預(yù)期的人。當(dāng)然，我們也應(yīng)該關(guān)心普通用戶的期望，特別是針對那些普通用戶會與之打交道的硬件設(shè)備，比如打印機(jī)、顯示器和鍵盤等。02bug的源頭bug來自哪里？我們能把所有bug的成因范圍縮小至一個(gè)或者幾個(gè)之內(nèi)嗎？答案是肯定的。bug通常來自開發(fā)者嘗試降低代碼復(fù)雜性未果而產(chǎn)生的副作用。也有部分來自對其實(shí)簡單的代碼產(chǎn)生的誤解。除了一些拼寫錯(cuò)誤以外，我能十分肯定以上兩點(diǎn)基本就是所有bug產(chǎn)生的根本原因

4、，盡管我還沒有進(jìn)行深入的研究來證明這件事。復(fù)雜的事物容易引起用戶的誤操作。想象一下一個(gè)黑色盒子，上面有上百萬個(gè)沒有任何標(biāo)識的按鈕，而其中的16個(gè)按鈕按下之后會毀滅整個(gè)世界，那么使用這個(gè)盒子的人中注定有人會一不小心讓毀滅降臨。在編程中也存在類似的情況，如果你無法輕易理解編程語言的文檔，或者是這門語言本身，你就或多或少存在錯(cuò)誤使用它的可能。說真的，就那個(gè)長滿上百萬個(gè)沒有標(biāo)識按鈕的盒子而言，正確的使用方式不可能存在。你永遠(yuǎn)也不可能弄清正確的方式是什么，即使你計(jì)劃閱讀完1000頁的說明書，也不一定能記住能夠幫助你正確使用盒子的整套流程。同樣的道理，只要你讓事物變得足夠復(fù)雜，人們就會傾向于用錯(cuò)誤的而不是

5、正確的方式使用它。如果你把50、100或者1000個(gè)這類的復(fù)雜組件拼裝在一起，無論由多聰明的工程師來進(jìn)行拼裝，它們也永遠(yuǎn)無法正常工作。所以你開始明白bug來自哪里了吧？你每引入一絲復(fù)雜性，開發(fā)者（這里的“開發(fā)者”甚至包括你自己）誤用你的代碼的概率就高一分。一旦代碼的意圖和使用方法變得極不明確，就會讓使用這份代碼的人犯錯(cuò)。又因?yàn)槟愕拇a和其他的代碼混合在了一起，導(dǎo)致了開發(fā)者誤用和犯錯(cuò)的可能性大大增加。而后這些代碼又會繼續(xù)和其他的代碼混合，形成惡性循環(huán)。復(fù)雜性的構(gòu)成硬件設(shè)計(jì)者將硬件制造得極為復(fù)雜的情況時(shí)常發(fā)生。所以它必須與復(fù)雜的匯編編程語言集成。而這又使得匯編語言和編譯器同樣復(fù)雜起來。當(dāng)你遇到這種

6、情況時(shí)，如果你不提前對程序進(jìn)行精妙的設(shè)計(jì)或者全方位的測試的話，基本上無法避免bug的發(fā)生。只要你的設(shè)計(jì)不夠完美，那么在運(yùn)行的一瞬間，大量的bug就會涌現(xiàn)出來。站在其他程序員的視角看這件事也很重要。畢竟有些事對你來說很簡單，但是對其他人來說或許很復(fù)雜。如果你想要感同身受地體驗(yàn)一下其他人看不懂你的代碼的感受，你可以找一份你從沒有使用過的類庫的文檔來閱讀看看。也可以找一些你從沒有閱讀過的代碼來閱讀。嘗試?yán)斫庹纬绦蚨皇菃涡写a的含義，并且想象當(dāng)你需要對它進(jìn)行修改時(shí)應(yīng)該從哪里入手。這些都是其他人閱讀你代碼時(shí)的體驗(yàn)。你大概注意到在閱讀他人代碼時(shí)，即使并不復(fù)雜的代碼也足以讓人產(chǎn)生挫敗感。現(xiàn)在我們考慮另一種程序員誤解簡單代碼的情況。這也是需要額外小心的另一件事。如果你察覺到某位程序員在向你解釋一段代碼時(shí)敘述得牛頭不對馬嘴，那便意味著他應(yīng)該是誤解了代碼中的某些內(nèi)容。當(dāng)然如果他正在研究的領(lǐng)域極其復(fù)雜，也情有可原，可能需要他讀到博士學(xué)位才能完全掌握它。這兩個(gè)方面是緊密關(guān)聯(lián)的。當(dāng)你編寫代碼時(shí)，需要承擔(dān)的部分職責(zé)是讓將來閱讀你代碼的程序員理解它，并且是很輕松地就能理解。如果你確實(shí)是這么做的，但是他在閱讀過程中仍然產(chǎn)生了嚴(yán)重誤解或許他根本就不明白“if”語句是什么含義。那應(yīng)該就與你無關(guān)了。假設(shè)將來那些