當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

为什么你一直在写bug？原因找到了

發(fā)布時(shí)間：2025/3/15 编程问答 25 豆豆

生活随笔收集整理的這篇文章主要介紹了为什么你一直在写bug？原因找到了小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

導(dǎo)讀：當(dāng)談?wù)揵ug時(shí)我們究竟談?wù)摰氖鞘裁?#xff1f;

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

來源：大數(shù)據(jù)DT（ID：hzdashuju）

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ù)摰氖鞘裁?#xff1f;

這里是關(guān)于bug的精確定義：

程序的行為并沒有符合程序員的預(yù)期。

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

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

其他軟件功能上的不足都可以歸納到新功能需求中。如果說程序的工作狀態(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è)新的“統(tǒng)治整個(gè)世界”的功能。這也就算不上是一個(gè)bug。

硬件

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

當(dāng)然，我們也應(yīng)該關(guān)心普通用戶的期望，特別是針對那些普通用戶會與之打交道的硬件設(shè)備，比如打印機(jī)、顯示器和鍵盤等。

02 bug的源頭

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

bug通常來自開發(fā)者嘗試降低代碼復(fù)雜性未果而產(chǎn)生的副作用。也有部分來自對其實(shí)簡單的代碼產(chǎn)生的誤解。

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

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

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

同樣的道理，只要你讓事物變得足夠復(fù)雜，人們就會傾向于用錯(cuò)誤的而不是正確的方式使用它。如果你把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)你遇到這種情況時(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è)將來那些閱讀你代碼的程序員，對編程的基本原理和正在使用的編程語言語法都略知一二，在這個(gè)前提下你的職責(zé)是寫出整潔的代碼。

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

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

你應(yīng)該始終想方設(shè)法去簡化程序中的代碼。

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

本文摘編自《編程原則：來自代碼大師Max Kanat-Alexander的建議》，經(jīng)出版方授權(quán)發(fā)布。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：数字化转型最致命的5个误区
下一篇：武书连2019中国大学排行榜公布：浙大排