什么是調(diào)試

原文：What is Debugging? How to Debug Your Code for Beginners，作者：Germán Cocca

在這篇文章中，我們將討論什么是調(diào)試，如何調(diào)試你的代碼，以及你如何能在這方面做得更好。

軟件中的 “bug” 和 “debugging” 這兩個詞被普遍認為是由 Admiral Grace Hopper 提出的。一個真正的傳奇人物，她寫了有史以來的第一個編譯器。

20世紀40年代，當她在哈佛大學為美國海軍開發(fā)的一臺計算機工作時，她的同事發(fā)現(xiàn)一只飛蛾（一種真實的昆蟲）卡在一個繼電器中，使計算機崩潰。

在解決這個問題時，她說，他們正在 debugging 系統(tǒng)。

如果你是一個詞源學愛好者，你可能會對這樣一個事實感興趣：在進入計算機世界之前，debugging 一詞似乎已經(jīng)作為一個術(shù)語在航空學中使用。

而且顯然有某種證據(jù)表明，甚至托馬斯-愛迪生在1878年也在 technical error 的意義上使用過這個詞。

但這并不是本文的重點。重點是，調(diào)試是軟件開發(fā)的一個核心部分。它一直都是，而且可能永遠都是。

然而，值得慶幸的是，現(xiàn)在我們需要從計算機中移除真正的昆蟲的情況相當罕見。

漏洞和錯誤在軟件開發(fā)中很容易發(fā)生，因為它是一種概念性和抽象的活動。

作為開發(fā)者，我們與信息打交道。我們組織它、移動它、更新它、編輯它、把它發(fā)送到各地，然后再次接收它。

我們一直在與信息打交道，但不是直接與它打交道。信息并不“實際”存在于計算機中，至少不是以用戶認為的格式存在。

在計算機中只有電脈沖，然后被抽象為1和0，然后再次被抽象為我們正在處理的任何信息。

為了與計算機交互和使用計算機，我們使用編程語言。這些提供了計算機正在執(zhí)行的實際任務(wù)的抽象，以及我們正在管理的信息的表示。

編程可以是一種非常抽象的活動，而且很容易很快就忽略了計算機正在執(zhí)行的實際任務(wù)是什么，或者我們在某一行代碼中根據(jù)什么信息行事。從那時起，我們就很容易給計算機發(fā)出錯誤的指令，從而錯失我們所要尋找的目標。

在軟件開發(fā)領(lǐng)域的一個內(nèi)部笑話是，開發(fā)人員通常會花5分鐘來寫代碼，花5個小時來理解為什么事情不能像它們應(yīng)該的那樣工作。

作為開發(fā)人員，無論我們做得多好，我們都要花無數(shù)個小時來調(diào)試我們的代碼，所以我們應(yīng)該努力在這方面做得更好、更快。

調(diào)試可以被定義為在代碼庫中找到問題的根源并加以修復的過程。

通常我們會從思考所有可能的原因開始，然后測試每個假設(shè)（從最有可能的假設(shè)開始），直到找到最終的根本原因。然后我們糾正它，確保它不會再發(fā)生。

對于bug，沒有神奇的解決方案。通常情況下，它需要結(jié)合搜索，記錄我們的代碼，并根據(jù)真正發(fā)生的情況檢查我們的邏輯。

雖然有許多工具可以幫助你進行調(diào)試，但使用這些工具并不一定是困難的部分。難的是真正理解你得到的錯誤，并真正理解什么是解決這些錯誤的最佳方案。

因此，讓我們先來談?wù)劇罢{(diào)試心態(tài)”，然后探索一些我們可以用來調(diào)試代碼的有用工具。

在幾乎所有的開發(fā)環(huán)境中，如果你的代碼失敗了，很可能會顯示一個錯誤信息，（在某種程度上）解釋你的代碼為什么會失敗。

以這段代碼為例：

這段代碼出現(xiàn)了以下錯誤:

正如你所看到的，錯誤信息明確指出了問題所在，甚至聲明了問題發(fā)生在哪一行（test.js:4:1）。

這似乎是一個愚蠢的建議，但你可能會驚訝地看到有多少程序員不仔細閱讀錯誤信息，而只是用他們腦海中的第一個想法來應(yīng)對錯誤。

錯誤信息的存在是有原因的，這至少可以讓我們對問題的來源有一個初步的了解。

如果你得到的錯誤信息不清楚，或者你無法弄清楚為什么會得到它，那么好的第一步就是用谷歌搜索。

關(guān)于編碼的許多令人驚奇的事情之一是，在線社區(qū)是巨大的。幾乎可以肯定的是，已經(jīng)有大量的人遇到了和你一樣的問題，并且已經(jīng)解決了它，解釋了它，這樣其他人就不必再糾結(jié)于它了。

當搜索時，一個好主意是在搜索中盡可能詳細。按照前面的例子，我會使用 javascript ReferenceError: Cannot access before initialization 。我發(fā)現(xiàn)，在搜索中提到你所使用的技術(shù)會給你更準確的結(jié)果。

我還了解到，刪除那些只針對我的代碼而不是每個人都會遇到的錯誤的東西是很重要的。如我的函數(shù)的名字（'mickTheBug'）。

另一個好主意是盡量 使用可信的和最新的來源。可信的意思是官方文檔或已經(jīng)被其他人驗證過的解決方案。最近的意思是指盡可能在最近實現(xiàn)的解決方案，因為五年前有效的東西可能不是現(xiàn)在解決問題的最好方法。

當你在學習新東西或處理錯誤時，官方文檔總是應(yīng)該是首先要檢查的東西。

官方文檔通常是任何特定工具的最完整和最新的信息來源。有時，翻閱這么多的技術(shù)信息可能會感到乏味或不知所措，但從長遠來看，我認為這可以節(jié)省時間。

官方文檔的問題是，有時它們包含如此多的信息，而且解釋得如此詳細，以至于它更令人困惑而不是解釋。

正因為如此，我認為對于任何特定的主題，總是使用一個以上的來源，并“聽取不同的聲音”來解釋同一件事是一個好主意。通常只有在閱讀了文檔、一些文章和觀看了一些YouTube視頻之后，我才覺得我對我正在使用的工具有了很好的理解。

我之前提到過，編程可以是一種抽象的活動，這使得我們很容易忽視一些事情，做出錯誤的假設(shè)，并誤解我們正在處理的信息

解決這個問題的一個好辦法是逐行閱讀你的代碼，一邊讀一邊大聲解釋。小黃鴨調(diào)試法是一種流行的方法，但你可以選擇你最喜歡的寵物或想象中的朋友。=P

這樣做的目的是強迫自己真正讀懂你的代碼，而不是僅僅假設(shè)你知道它是做什么的。通過這種方式，你可以檢查你頭腦中的邏輯與你的代碼中實際發(fā)生的情況。

事實上，我們傾向于假設(shè)事情，而不是詳細關(guān)注每一行代碼，這只是人類的天性。這是一種幫助我們節(jié)省精力和更快做事的機制。

但在調(diào)試時，我們需要強制我們的大腦與我們一起工作，并盡可能地在每一行代碼上出現(xiàn)。

隨著你的代碼庫越來越大，你將很難分析每一行代碼來尋找你的錯誤。因此，一個好主意是分而治之，從最有可能產(chǎn)生問題的地方開始搜索。

讓我們看看這個例子。我有一個函數(shù)，它接收一個數(shù)字并返回它乘以2的結(jié)果，還有一個函數(shù)，它打印一個名字（firstName），一個姓氏（lastName），以及乘法函數(shù)的結(jié)果。

這段代碼是有意義的，運行時沒有出現(xiàn)錯誤，但我得到的結(jié)果是 My name is Mick 10 and the double of my age is NaN，這不是我想要的。

這里我可以看到，10 被打印在 lastName的位置。而由于參數(shù)是在調(diào)用函數(shù)的那一行設(shè)置的。

這可能是一個很好的猜測，首先要檢查參數(shù)的傳遞方式是否正確。事實上，我們可以看到，當我調(diào)用該函數(shù)時，我給它傳遞了兩個參數(shù)，Mick和 10，而該函數(shù)希望有三個參數(shù)firstName, lastName, age。

Typescript 可以輕松地防止我們犯這個錯誤。稍后再談這個問題。;)

同樣，這是一個愚蠢的例子，但它說明了我們?nèi)绾文軌蛲茢喑鰡栴}的來源，即使我們沒有錯誤信息來幫助我們。

在這些時候，試著問自己以下問題：

像我們到目前為止看到的例子那樣的錯誤，解決起來小菜一碟。但許多其他的就不是這樣了，在許多情況下，你不得不與bug斗爭幾個小時（或幾天），直到你找到一個解決方案。

在這種情況下，我發(fā)現(xiàn)注意你的心理狀態(tài)真的很重要。編程是一種非常消耗精力的活動。因此，你的大腦在某一時刻的工作方式或你的感覺將直接影響你的代碼的外觀和你以有效方式解決問題的能力。

如果你花了幾個小時閱讀，大聲重復同樣的代碼行，上網(wǎng)搜索，翻閱Stack Overflow的問題，但你的代碼仍然失敗，你遲早會感到沮喪，并開始給自己施加壓力。

當你嘗試不同的解決方案并一次次失敗時，你對細節(jié)的關(guān)注很可能會淡化，你會開始有不同的想法，并同時嘗試很多東西。

一旦你到了這個地步，明智的做法是出去走走，或者干脆不去管它，直到第二天。

如果你在這種緊張和疲憊的精神狀態(tài)下繼續(xù)下去，你可能不會找到一個解決方案。更重要的是，你甚至可能因為觸碰了與之無關(guān)的東西而使 bug 變得更糟。

當把事情擱置一段時間并思考其他事情時，我們的大腦會在默默地繼續(xù)處理問題，并以 潛意識 和創(chuàng)造性的方式將想法聯(lián)系起來。

在很多情況下，我在洗澡時或第二天早上一看到這個問題，我的腦海中就會出現(xiàn)一個新的解決方案。這就是那種 啊哈! 的時刻。它可能就在你的眼前，但因為你很累，壓力很大，所以你沒能看到它。

集中精力、充分休息和放松是寫好代碼和有效修復錯誤的關(guān)鍵。努力工作和燒壞頭腦之間的界限并不遠，但重要的是我們要注意它，并在我們需要時讓自己休息一下。

通常當我沒有想法了，是休息的好時機，或者開始失去焦點，以一種沖動的、非系統(tǒng)性的方式嘗試不同的方法。

另外，在你的腦海中保持這樣的想法：bug 只是軟件開發(fā)的一部分。這并不意味著你作為一個開發(fā)者很糟糕。每個人都會有 bug，即使是最好的程序員。因此，冷靜下來，利用這種情況來學習新的東西。

我之前提到過在線社區(qū)的重要性，以及我們可以在幾秒鐘內(nèi)輕松找到幾乎任何主題的幫助是多么酷。

能夠進入正確的社區(qū)，在那里你可以向?qū)δ闼褂玫墓ぞ哂薪?jīng)驗的人詢問和交談，這真的非常、非常、非常有幫助。

這取決于你工作的領(lǐng)域和你使用的工具，但對我來說，像 freecodecamp、stackoverflow 和 meetupjs 這樣的Sack或Dscord社區(qū)都起到了很大的作用。

在這些社區(qū)內(nèi)提問時，我發(fā)現(xiàn)記住以下幾點很重要：

這將使另一個人更容易理解你的問題，并希望為你提供解決思路。

如果你得到了回復，重要的是你要 回復他們，要么確認解決方案有效，要么確認它沒有，并解釋原因。

記住，你提出的問題可能會被儲存起來，在下一次有人來搜索同樣的錯誤時可以使用。這里的想法是要 構(gòu)筑知識，并使其為 所有人所用，而不僅僅是為了解決這個特定的錯誤。

另外，如果你最終自己找到了解決方案，那么 回答你自己的問題，并與大家分享解決方案也是一個好主意。

按照同樣的思路，如果你通過提問參與這些社區(qū)，你也應(yīng)該參與回答問題。只要你有能力，并且發(fā)現(xiàn)你有知識，回饋一下也是好的。;)

我對這個問題的最后一個想法是，在這些類型的社區(qū)中，大多數(shù)人都很好，很開放，而且非常愿意幫助和分享知識。但是，就像在任何其他生活領(lǐng)域一樣，偶爾你會遇到一些粗魯、傲慢、甚至具有攻擊性的人。

我在這里的建議是，你不要讓別人嚇到你，即使他們看起來比你有更多的知識。

沒有人天生就知道所有的事情，如果你已經(jīng)做了研究并致力于解決問題，你完全有權(quán)問任何你想要的東西。如果其他人傲慢或無禮，這說明他們不好，而不是你。

唯一比與一個棘手的bug作斗爭更令人沮喪的事情是，在修復它之后，卻發(fā)現(xiàn)這個bug仍然在那里。甚至更糟糕的是，由于這個 "解決方案"，更多的bug被引入到你的代碼中。

為了避免這種情況，關(guān)鍵是你要測試你的代碼。如果你能用自動化單元測試來做，那就更好了。

理想情況下，你的代碼庫的每個部分或組件都應(yīng)該有自己的測試。這些測試應(yīng)該在每次對代碼庫做任何修改時運行。這樣一來，如果測試寫得正確，我們就可以在新的錯誤出現(xiàn)時注意到它。這當然會使我們更容易找到它的原因并解決它。

如果你沒有自動化測試（如果你想創(chuàng)建高質(zhì)量的軟件，你真的應(yīng)該這樣做），至少要手動測試你的代碼，重現(xiàn)用戶可能與之發(fā)生的所有互動，并確保該bug被有效地殺死。

對抗bug的最好方法是首先避免插入bug。對任何程序員來說，寫出有保證的無缺陷的代碼是不可能的，但有幾件事你可以做，以減少缺陷被插入的機會。

一個好的開始是經(jīng)典的DRY、KISS和SOLID原則。

關(guān)于這些主題有整整一本書，但長話短說，這些原則旨在使軟件易于開發(fā)，易于理解和維護，并盡可能地接近于無缺陷。

DRY 原則代表著 不要重復自己。它基本上意味著我們應(yīng)該盡可能地避免重復相同的代碼。

例如，如果你發(fā)現(xiàn)你在代碼的不同部分反復執(zhí)行相同的作，那么更好的方法是將該邏輯抽象為一個函數(shù)，并調(diào)用該函數(shù)，而不是直接在代碼的不同部分執(zhí)行作。

這樣一來，如果在該作中發(fā)生了一些錯誤或意外行為，我們就知道只有一段代碼要負責，而不是許多分散在代碼庫中的代碼。

KISS 原則代表著 保持簡單的愚蠢。隨著一個軟件項目的發(fā)展，它不可避免地開始變得越來越復雜。隨著新的、計劃外的功能被添加，不同的開發(fā)人員開始工作，不同的邏輯和執(zhí)行任務(wù)的方式可能會在同一個項目中實現(xiàn)。

這使得代碼更難理解、維護和工作。而當代碼難以理解時，就很容易做出錯誤的假設(shè)和插入錯誤的代碼。

我們的目標應(yīng)該是使軟件易于閱讀和理解，有一個清晰的邏輯，對每個人都是明確的，而不僅僅是對我們。

請記住，將來有人可能要使用你寫的代碼，所以要讓那個人容易理解你在做什么。甚至你在幾個月后可能都不記得你想用那個函數(shù)做什么。

還要記住，沒有軟件是永遠不變的。軟件的本質(zhì)是通過新的功能來改變和增強，所以你的代碼應(yīng)該在需要時易于修改。

再進一步說，只要你能找到一個更簡單的方法來執(zhí)行同樣的任務(wù)，你就應(yīng)該修改你的代碼。

也許在加入了一些新的功能后，你一開始想到的設(shè)計并不是仍然是最好的選擇。編碼的另一個很酷的事情是，沒有什么是一成不變的，當需要的時候，事情可以很容易地轉(zhuǎn)過來。所以要利用這一點，習慣于不斷重構(gòu)你的代碼，尋找更簡單的方法。

一些有助于此的實用概念是使用明確的函數(shù)和變量名稱，將關(guān)注點分離成不同的函數(shù)和代碼模塊，當你的任務(wù)不可避免地復雜時，寫簡短的注釋來解釋你的代碼。

SOLID 是一套主要適用于 OOP 的原則。它們是由Robert C. Martin (他也是 agile manifesto 的作者)，這本書中 是面向?qū)ο笤O(shè)計的。

如前所述，SOLID更適用于OOP而不是一般的編程。我們不打算在本文中深入探討OOP，但了解這些原則并將其牢記在心仍然是很好的。

現(xiàn)在讓我們來了解一些你可以用來幫助你調(diào)試代碼的工具。

有許多工具我們可以用來減少在我們的代碼中插入bug的機會，或者更有效地打擊現(xiàn)有的bug。

在這方面，我們將看看TypeScript，流行的（非常有用的）console.log，以及VS Code和Chrome中內(nèi)置的調(diào)試器。

這些工具和例子將以JavaScript為中心，但這些原則適用于任何編程語言。

你還應(yīng)該知道，現(xiàn)在大多數(shù)代碼編輯器和網(wǎng)絡(luò)瀏覽器都有內(nèi)置的調(diào)試器，但我們要審查的是VS代碼和Chrome，因為它們是最流行的。

最后，你還應(yīng)該知道有一些特定的調(diào)試工具，你可以用來調(diào)試特定類型的應(yīng)用程序，比如 React 和Redux 開發(fā)工具，這是你可以安裝的瀏覽器擴展，以幫助你更有效地調(diào)試你的代碼。

但我們將來會在另一篇關(guān)于如何調(diào)試React應(yīng)用程序的文章中回顧這些。;)

我提到TypeScript是第一個工具，因為它與前面關(guān)于編寫干凈代碼的部分密切相關(guān)。

TypeScript不只是為你提供了一個強大的JavaScript類型系統(tǒng)。它還增加了一個編譯器，可以幫助你在運行代碼之前識別代碼中的錯誤和誤區(qū)。它提供了驚人的自動完成功能，并且可以被認為是一個自動文檔工具。

為了了解它的好處，讓我們重溫一下前面的例子，在這個例子中，我們沒有為我們的函數(shù)調(diào)用提供正確的參數(shù)。

正如你在這里看到的，在運行程序之前，TypeScript立即檢測到我們?nèi)鄙僖粋€參數(shù)，并給了我們以下錯誤:

這些類型的通知是非常有用的，特別是當你在大項目中工作時，你必須與許多API或不同的代碼部分互動。

因此，如果你習慣于使用普通的JavaScript，TypeScript一開始可能會覺得是不必要的模板。但從長遠來看，它肯定會節(jié)省你的時間，防止你在代碼中插入愚蠢的錯誤。

在控制臺中記錄你的代碼是最基本的調(diào)試方式，也是我們作為開發(fā)者最先學會使用的方式。

其目的是打印變量、函數(shù)、輸入和輸出的值，以檢查我們頭腦中的邏輯與我們代碼中的真實情況。它還可以幫助我們看到我們正在做哪些錯誤的假設(shè)。

盡管它是一個基本的工具，但我們可以用它做一些很酷的事情。讓我給你看看。

如果我們調(diào)用 "console.log"，我們將得到任何我們作為參數(shù)傳遞的對象打印在我們的控制臺。

console.table is great when working with arrays or objects, as it sets the information within a table where your can easily see keys/indexes and properties/values.

當同時記錄許多事情時，console.group 給了我們一種有組織的方式來看待事情。

console.assert 在測試我們代碼中的條件時非常有用。它需要兩個參數(shù)：第一個參數(shù)是條件，第二個參數(shù)是條件為假時記錄的信息。

console.warning 和 console.error 在調(diào)試我們代碼中的錯誤時很有用。第一個將以黃色背景打印錯誤，第二個以紅色背景打印。

隨著我們的應(yīng)用程序的增長和開始變得更加復雜，控制臺.記錄的做法變得不是那么有效。

為了幫助我們與錯誤作斗爭，我們開發(fā)了調(diào)試器。它們只不過是能夠讀取其他程序并逐行查看的程序，沿途檢查我們想要的任何信息（例如，變量的值）。

我們要看到的第一個例子是 Visual Studio調(diào)試器。

為了調(diào)試一個Node.js應(yīng)用程序，我們不需要安裝任何額外的東西（假設(shè)我們的電腦中已經(jīng)安裝了VS代碼和Node），因為VS代碼中內(nèi)置了node調(diào)試器。

如果你用其他語言調(diào)試，如Python或Java，你可能需要在運行調(diào)試器之前安裝一個特定的VS擴展。

開始時，我們只需選擇我們要調(diào)試的文件，然后按下 bug 圖標。

之后，我們將看到以下畫面:

我們將選擇 Run and debug，這將只是為我們在編輯器中運行該程序。

考慮到你也可以創(chuàng)建一個launch.json文件，這是一個VS代碼用來 知道 如何運行你的程序的文件。對于這個簡單的例子來說，這不是必要的，但要知道這種方法。

點擊 Run and debug 按鈕后，我們的程序?qū)⑦\行，我們將進入以下屏幕:

在左上方，我們有程序中所有可用的變量，包括本地和全局的變量。

在下面，我們會有一個空間，可以聲明我們想觀察的特定表達式。表達式可以是任何東西，比如你想關(guān)注的特定變量或函數(shù)，以評估它們?nèi)绾坞S著你的程序而變化。

例如，我添加了我的變量 arr，VS代碼向我顯示了該變量的值:

在這下面，我們可以看到調(diào)用堆棧（如果你不知道那是什么，這里有一個很好的視頻來解釋），正在加載的腳本，以及我們在代碼中設(shè)置的斷點（我們一會兒就會看到這些是什么）。

斷點 是使調(diào)試器有用的一個重要部分。正如它們的名字所示，它們是你可以在你的代碼中聲明的點，在這些點上調(diào)試器將停止運行程序。當程序停止時，你就可以檢查我們之前提到的所有信息，因為它是在那個特定時刻。

所以斷點允許我們看到程序正在運行的實際信息，而不需要在控制臺中記錄任何東西。相當酷啊!

你可以通過出現(xiàn)在代碼中行號左邊的小紅點來識別斷點（或者通過查看上面提到的部分）。

默認情況下，當你運行調(diào)試器時，斷點會被插入到你代碼的最后一行。要插入新的斷點，只需在你希望調(diào)試器停止的行號左邊點擊即可。

現(xiàn)在，當你運行調(diào)試器時，你會看到在第一個斷點的上方有一個小小的左箭頭，表示程序的執(zhí)行已經(jīng)停止。

在屏幕的頂部，我們有 controls，這將使我們能夠通過程序從斷點到斷點的步驟。

所以，你看，這就是一個內(nèi)置于你的代碼編輯器中的非常強大的調(diào)試器。正如你所看到的，有了這個工具，我們可以同時檢查很多信息，只需在我們想要的地方設(shè)置斷點，而且不需要任何console.logs。

要在Chrome中進行調(diào)試，我們首先要在瀏覽器中打開我們的應(yīng)用程序。在我的例子中，我創(chuàng)建了一個簡單的HTML文件，其中鏈接了我的JS文件（與前面的例子相同）。

然后我們打開developer tools（ctrl+shit+i或右鍵->inspect），進入 "sources"標簽。

我們應(yīng)該看到像這樣的東西:

在左邊，我們可以看到我們的應(yīng)用程序中可用的文件（在我的例子中，只有一個HTML文件和JS文件）。 在中間，我們可以看到我們選定的文件的代碼，在右邊，我們有一組信息，與我們在VS Code中的信息非常相似。

要設(shè)置斷點，我們必須點擊我們想要停止的那一行的頂部。在Chrome瀏覽器中，斷點被識別為行號上方的藍色箭頭。

然后，如果我們刷新我們的頁面，腳本將在第一個斷點處停止，我們將被允許使用控件來瀏覽它，這與VS代碼中的工作方式完全相同。

正如我們所看到的，Chrome和VS代碼調(diào)試器的工作原理非常相似，你決定使用哪一個只是一個偏好的問題。

調(diào)試是我們作為開發(fā)者所做工作的一個核心部分。正因為如此，我認為以一種有效的方式來考慮它和做它是一個好主意，而不是在錯誤發(fā)生時才做出反應(yīng)。

正如我們所看到的，我們有很多事情可以做，無論是從精神上還是從技術(shù)上，都可以成為更好的調(diào)試。

希望這對你有幫助，下一節(jié)課見!

你也可以在 Twitter 和 LinkedIn 關(guān)注我。