谷歌瀏覽器bug調試快捷鍵_Bug壓榨初學者指南：如何使用調試器和其他工具查找和修復Bug

谷歌瀏覽器bug調試快捷鍵

As web developers, it often feels like we spend more time fixing bugs and trying to solve problems than we do writing code. In this guide we'll look at some common debugging techniques, so let's get stuck in.

作為Web開發人員，通常感覺我們比編寫代碼花費更多的時間來修復錯誤和嘗試解決問題。在本指南中，我們將介紹一些常見的調試技術，因此請緊緊抓住它。

“準備失敗，準備失敗” ("Fail to prepare, prepare to fail")

What better way to start an article than with an old cliche! Bug's and issues are going to pop up. There is simply no way of getting away from this (sorry). With some simple planning, there are ways in which we can minimize the complexity and number of problems we face.

與舊的陳詞濫調相比，還有什么更好的開始文章的方式！錯誤和問題將會彈出。根本沒有辦法擺脫這個(抱歉)。通過一些簡單的計劃，我們可以通過多種方法將所面臨問題的復雜性和數量降至最低 。

將任務分解為較小的任務 (Break the task up into smaller tasks)

Now, I get it, we all like to get very excited and dive straight into our coding projects. The thing is, without some sort of plan we are creating problems for ourselves before we even start!

現在，我明白了，我們大家都非常興奮，直接進入我們的編碼項目。問題是，如果沒有某種計劃，我們甚至在開始之前就為自己制造問題！

If I said to you, "you have to build a shopping list app", and you started coding straight away, what would happen? You would end up staring at a blinking cursor wondering how or what to do first, cursing my name under your breath for asking you to do such a task.

如果我對您說：“您必須構建一個購物清單應用程序”，并且立即開始進行編碼，那會發生什么？您最終將盯著一個閃爍的光標，想知道該怎么做或先做什么，然后屏住呼吸詛咒我的名字，要求您執行此任務。

It's always easier to take a large problem and break it up into many smaller problems. For example, we can break the shopping list project into smaller tasks:

將大問題分解成許多小問題總是比較容易。例如，我們可以將購物清單項目分解為較小的任務：

Create a form to add an item to the list
創建一個表單以將項目添加到列表
Allow a user to remove an item from the list
允許用戶從列表中刪除項目
Display a total number of items in the list
顯示列表中的項目總數

You can even break these tasks up into more detailed tasks. For example, for the first task in our list, our first, "little mini task" (should I trademark that term?) could be:

您甚至可以將這些任務分解為更詳細的任務。例如，對于列表中的第一個任務，我們的第一個“小微型任務”(我應該用這個商標嗎？)可以是：

1) Create an input field to capture the item name

1)創建一個輸入字段以捕獲項目名稱

2) Create a button that calls a functions addToList() when clicked

2)創建一個按鈕，當單擊該按鈕時調用函數addToList()

3) Write logic within the addToList() function that adds the item to the list

3)在將項目添加到列表的addToList()函數內編寫邏輯

And so on. You get the idea. I prefer breaking work up like this as it really makes me think about the problems I'll encounter early and the solutions (I've written an in-depth article about this here) before I've written any code. It also helps me understand what I'm trying to do, and puts me in the "zone". It's much easier to solve problems that arise when you understand what you are trying to achieve.

等等。你明白了。我更喜歡像這樣分手工作，因為這確實使我在寫任何代碼之前考慮一下我會較早遇到的問題和解決方案( 我在這里寫了一篇深入的文章 )。它還可以幫助我了解我要執行的操作，并將我置于“區域”。解決了當您了解要實現的目標時出現的問題要容易得多。

準備清除您的代碼 (Be prepared to purge your code)

To make an omelet, we have to break a few eggs. This means being prepared to completely re-write our code to get it working.

要制作煎蛋卷，我們必須打碎幾個雞蛋。這意味著準備完全重新編寫我們的代碼以使其工作。

I bet you're thinking, "oh man, it took me days/weeks/millennia to get this far with my code, and now I have to delete it?!" ?Um, yeah. Sometimes. Sorry. The reality with web development is that code will change all the time, for various reasons - bugs, code reviews, changes in requirements, boredom, etc.

我敢打賭，您在想，“哦，伙計，花了我幾天，幾周，幾千年的時間，我的代碼才能做到這一點，現在我必須刪除它了！！” 嗯是的有時。抱歉。 Web開發的現實是，由于各種原因，代碼將一直在變化-錯誤，代碼審查，需求變化，無聊等。

Sometimes we feel so precious about our code and can't bear to delete it, that we try and overcome problems by trying to "fit a round peg into a square hole". We think "NOO! I can't possibly delete this method. It took me forever. There has got to be a way!" This mental block causes our own problems - because by simply rewriting what we currently have, we could find the solution to our problems.

有時我們對代碼感到如此珍貴，不愿刪除它，以至于我們試圖通過“將圓釘固定在方Kong中”來克服問題。我們認為“沒有！我無法刪除此方法。這花了我一輩子。一定有辦法！” 這種思維障礙導致了我們自己的問題-因為只需重寫當前的內容，我們就能找到解決問題的方法。

Now that we're nice and prepared, let's look at what happens when things do go wrong.

現在我們已經準備好了，讓我們看看當事情出錯時會發生什么。

錯誤消息很好 (Error messages are good)

What's worse than seeing an error message when something goes wrong? Not seeing any error message when something goes wrong. Even though it's a daunting feeling to see a big red stack trace when we run our carefully crafted code, error messages are there to say "yeah, things are messed up right now, but here are some places you can look to start fixing it".

有什么比發生錯誤時看到錯誤消息更糟糕的呢？出現問題時看不到任何錯誤消息 。盡管在運行我們精心設計的代碼時看到巨大的紅色堆棧痕跡令人生畏，但錯誤消息仍在上面說：“是的，事情現在已經搞砸了，但是您可以在這里找到一些地方開始修復它” 。

If we have a look at this example:

如果我們看一下這個例子：

let animals;function addAnimal(){animals.push('elephant');
}addAnimal();

Now let's have a look at the error:

現在讓我們看一下錯誤：

I've left out some of the stack trace as most of it is, well, gibberish. Depending on how your frontend project handles error messages, you may even see the error in your browser:

我省去了一些堆棧跟蹤信息，因為大部分都是亂碼。根據前端項目處理錯誤消息的方式，您甚至可能在瀏覽器中看到錯誤：

The important parts of the stack trace are usually at the top - the message, the function, and the line number, and our browser shows us this as well. So the interpreter does it's best to tell us what's wrong. It's a shame it can't solve the problem for us, eh?

堆棧跟蹤的重要部分通常位于頂部-消息，函數和行號，我們的瀏覽器也向我們顯示了這一點。因此，口譯員最好告訴我們出了什么問題。可惜不能為我們解決問題，是嗎？

So, we've finished having our panic attack at seeing the error and have picked some information from the error message. If we break it down we can see this line:

因此，我們已經對發現錯誤進行了緊急恐慌，并從錯誤消息中選擇了一些信息。如果我們將其分解，可以看到以下行：

Cannot read property 'push' of undefined

This usually means that there is a variable not defined or initialized somewhere. BUT WHERE?!?

這通常意味著某個變量未在某處定義或初始化。但是哪里？！？

If we continue reading the stack trace, we see the error occurs within the addAnimal() function. We can see that we are trying to push a new animal to an array - ah! I forgot to initialize the animals array. Doh! Our fixed code looks like this:

如果我們繼續讀取堆棧跟蹤，我們會在addAnimal()函數中看到錯誤發生。我們可以看到我們正在嘗試將新動物推入陣列-啊！我忘了初始化animals數組。 h！我們的固定代碼如下所示：

let animals = [];function addAnimal() {animals.push("elephant");
}addAnimal();

The error thrown in the browser will show you the problem quicker, but not all frontend projects will be configured to do this, and backend developers do not have this luxury. ?This is why I recommend learning to read the stack trace.

瀏覽器中引發的錯誤將更快地向您顯示問題，但并非所有前端項目都將配置為執行此操作，并且后端開發人員沒有這種奢望。這就是為什么我建議學習閱讀堆棧跟蹤的原因。

要擊敗該錯誤，您必須像錯誤一樣思考 (To defeat the bug, you must think like the bug)

The stack trace gives you an idea of what the error is. Well, sometimes it does and sometimes it doesn't. What if you see an error message that looks more like cave glyphs than English? Or what if there is no error, but your code is simply not acting as you thought?

堆棧跟蹤使您可以了解錯誤的原因。好吧，有時候會，有時候不會。如果您看到一條錯誤消息，看起來比英語更像洞穴字形怎么辦？或者，如果沒有錯誤，但是您的代碼根本沒有按照您的想法工作，該怎么辦？

It's time to get the debugger out. Let's walk through another example. But first some context!

是時候將調試器發布了。讓我們來看另一個例子。但是首先要有上下文！

Mr. Bob CEO (who is a CEO, who would have thought?!) approaches you and says,

鮑勃(Bob)首席執行官(誰是首席執行官，誰會想到的！

"Hey, I have an amazing idea for a product.

“嘿，我對產品有一個很棒的主意。

I want a web app that allows the user to enter a number.
我想要一個允許用戶輸入數字的Web應用程序。
If the number is less than 5, the message should read "UNDER".
如果數字小于5，則消息應顯示為“ UNDER”。
If the number is equal to or more than 5, the message should read "OVER".
如果數字等于或大于5，則消息應顯示為“ OVER”。

This is a million-dollar idea and I want you to build it for me".

這是一個數百萬美元的想法，我希望您為我建立它。”

"OKAY!" You say, and you get to work.

“好的！” 你說，就可以上班了。

*Coding montage with dramatic music plays as time fast forwards*

*隨著時間的推移，將蒙太奇與戲劇性音樂一起播放*

You've completed the code for your web app. Huzzah!

您已經完成了Web應用程序的代碼。暈！

(Note: You may have spotted the bug already. If you did, let's pretend you didn't. If you haven't noticed the bug, that's OK.)

(注意：您可能已經發現了該錯誤。如果發現了，請假裝您沒有。如果您沒有注意到該錯誤，那沒關系。)

Time to start testing. Let's run through some use cases for our business logic.

是時候開始測試了。讓我們來看一些業務邏輯用例。

1) User enters 3:

1)用戶輸入3：

2) User enters 7

2)用戶輸入7

So far so good! But what happens if we enter 5?

到目前為止，一切都很好！但是，如果我們輸入5會怎樣？

OH NO! A bug! The text displayed is incorrect, it should display "OVER" but instead displays "UNDER". Hmm, no error messages, and I can't seem to see in the code what is wrong. Let's run the debugger and step through the code.

不好了！蟲子！顯示的文本不正確，應顯示“ OVER ”，而顯示“ UNDDER ”。嗯，沒有錯誤消息，而且我似乎看不出代碼有什么問題。 讓我們運行調試器并逐步執行代碼。

使用調試器 (Using the debugger)

A good place to start is to put a breakpoint as close to the buggy code as possible. You can determine this by reading the code, error messages, or if you have that "ah-ha! I know which method is causing this" moment. From here, it's a case of stepping through the code, inspecting the variables, and checking if the correct code branches are run.

一個不錯的起點是將斷點放置在盡可能靠近越野車代碼的位置。 您可以通過閱讀代碼，錯誤消息或是否有“ 啊哈！ 我知道是哪種方法導致了這一時刻” 來確定這一點。從這里開始，需要逐步執行代碼，檢查變量并檢查是否運行了正確的代碼分支。

In our example, I have put a breakpoint at the start of my if statement - as this is where the failing logic is.

在我們的示例中，我在if statement的開頭放置了一個斷點-因為這是邏輯失敗的地方。

Once I start debugging, chrome opens and I can replicate the issue by entering "5" and clicking submit. This hits the breakpoint, and immediately there are a few things to note:

開始調試后，Chrome打開，可以通過輸入“ 5”并單擊“提交”來復制問題。這到達了斷點，立即有幾件事要注意：

The debugger stops at the breakpoint, so this means I'm on the right track
調試器在斷點處停止，所以這意味著我在正確的軌道上
This also means that the function is being called correctly, and event handlers are working as expected
這也意味著該函數被正確調用，并且事件處理程序正在按預期方式工作
I can also see that the user input is being captured correctly (from the "variables" panel on the left-hand side, I can see that "5" was entered)
我還可以看到用戶輸入已被正確捕獲(從左側的“變量”面板中，我看到輸入了“ 5”)

So far so good, no immediate issues to worry about. Well, code related ones anyway. Next, I'll press F10 to step through the code. This runs each statement individually, allowing us to inspect elements, variables, and other things at our own pace. Isn't technology just fabulous?

到目前為止，一切都很好，無需擔心任何即時問題。好吧，還是與代碼相關的代碼。接下來，我將按F10鍵單步執行代碼 。這將單獨運行每個語句，使我們能夠按照自己的步調檢查元素，變量和其他事物。技術不只是神話般的嗎？

Remember since I expect the message "OVER" to appear when the user enters "5", I'm expecting the debugger to take me into the first branch of the if statement...

請記住，由于我希望在用戶輸入“ 5”時出現消息“ OVER”，所以我希望調試器將我帶入if語句的第一個分支...

BUT NO! I'm brought into the second branch. Why? I need to amend the conditional to read "more than or equals to" as opposed to "more than".

但不是！我被帶到第二個分支。為什么？我需要修改條件，以將“ 大于或等于”讀為“大于”。

if(numberInputValue >= 5) {text = "OVER";
} else {text = "UNDER";
}

Success! Our bug is fixed. Hopefully this gives you an idea on how to walk through the code, making use of VSCodes awesome debugging tools.

成功！我們的錯誤已修復。希望這可以使您了解如何使用VSCodes出色的調試工具來遍歷代碼。