谷歌瀏覽器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出色的調試工具來遍歷代碼。

更多調試技巧 (More Debugging tips)

• If your breakpoints aren't being hit, this could be part of the issue. Make sure the correct functions or event handlers are being called in the way you expect
  如果沒有遇到斷點，這可能是問題的一部分。 確保以您期望的方式調用正確的函數或事件處理程序

• You can step over functions you want to skip. If you want to debug any functions you come across, use the step into command

  你可以step over要跳過功能。 如果要調試遇到的任何功能，請使用step into命令

• Watch out for variables, parameters, and arguments as you are stepping through your code. Are the values what you expect?
  在逐步執行代碼時，請注意變量，參數和參數。 這些值是您期望的嗎？
• Write code in a way that is easier to read/debug. It might look cool to have your code on one line, but it makes debugging harder
  以更易于閱讀/調試的方式編寫代碼。 將代碼放在一行中可能看起來很酷，但是這會使調試更加困難

Google是你的朋友 (Google is your friend)

Ok so we've looked at the stack-trace, tried debugging, and we're still stuck with this bug. The only thing left to do now is make a sacrifice to the coding gods and hope things fix themselves!

好的，我們已經查看了堆棧跟蹤，嘗試了調試，但仍然遇到此錯誤。 現在剩下要做的唯一一件事就是犧牲編碼神，并希望事情能夠解決！

Or I guess we could use Google.

或者我想我們可以使用Google。

Google is a treasure trove of software development problems and solutions, all at our fingertips. It can be sneakily difficult to access this information though, as you have to know how to Google the right things to get the right information! So how do we effectively use Google?

Google唾手可得，是軟件開發問題和解決方案的寶庫。 但是，由于您必須知道如何使用Google的正確方法來獲取正確的信息，因此很難獲得這些信息！ 那么，我們如何有效地使用Google？

Let's look back to our first example - you've read the stack trace, looked at the code, but the message Cannot read property 'push' of undefined is still driving you mad. Bewildered, you take to Google in hopes of finding an answer. Here are some things to try:

讓我們回頭看第一個示例-您已經閱讀了堆棧跟蹤，查看了代碼，但是消息Cannot read property 'push' of undefined仍然使您發狂。 迷惑不解，您帶去Google希望找到答案。 這里有一些嘗試：

Copy and paste the error message. Sometimes this works, depending on how "generic" the error message is. For example, if you get a Null pointer exception (who doesn't love those?), Googling "Null pointer exception" might not return very helpful results.

復制并粘貼錯誤消息。 有時這可以起作用，具體取決于錯誤消息的“通用”程度。 例如，如果您得到一個Null指針異常 (誰不喜歡那些異常 ？)，則搜索“ Null指針異?！笨赡懿粫祷胤浅Ｓ杏玫慕Y果。

Search for what you are trying to do. For example, "How to create an array and add an item to the end". You might find some generous developer has posted a solution using best practices on StackOverflow, for example. You might also find this solution is completely different from yours - remember what I said about being comfortable purging your code?

搜索您要執行的操作。 例如， “如何創建數組并在最后添加項目” 。 例如，您可能會發現一些慷慨的開發人員已在StackOverflow上發布了使用最佳實踐的解決方案。 您可能還會發現此解決方案與您的解決方案完全不同-還記得我說過的關于輕松清除代碼的說法嗎？

A side note on using someone else's code - try and avoid blindly copying and pasting, make sure you understand what the code does first!

關于使用他人代碼的附加說明-嘗試避免盲目復制和粘貼，請確保您首先了解代碼的作用！

以正確的方式尋求幫助 (Ask for help the right way)

Hopefully, after a mix of debugging, stack trace investigating, and Googling you have seen the light at the end of the tunnel and solved your problem. Unfortunately, depending on what you are trying to do, you still might be a bit stumped. This is a good time to seek advice from other people.

希望在經過調試，堆棧跟蹤調查和Googling混合之后，您已經看到了隧道盡頭的曙光，并解決了您的問題。 不幸的是，根據您要嘗試執行的操作，您仍然可能會有些困惑。 這是尋求他人意見的好時機。

Now, before you run into the street screaming "my code is broken please help me!", it's important to know the best way to ask for help. Asking for help in the right way makes it easier for people to understand the problem and help you solve it. Let's look at some examples:

現在，在街上大喊“我的代碼已損壞，請幫助我！”之前，了解尋求幫助的最佳方法很重要。 以正確的方式尋求幫助可以使人們更容易理解問題并幫助您解決問題。 讓我們看一些例子：

Bad - "My code is broken and I don't know what's wrong."

錯誤 -“我的代碼已損壞，我不知道出了什么問題。”

Good - "I'm trying to add an item to the end of an array in JavaScript, and I'm getting this error message: Cannot read property 'push' of undefined. Here's my code so far."

好 -“我正在嘗試在JavaScript中將項目添加到數組的末尾，并且收到此錯誤消息：無法讀取未定義的屬性'push'。到目前為止，這是我的代碼?！?

See how the "Good" example is much more informative? More information makes it easier for other kindhearted devs to help you out. This is a good habit to get into as it not only benefits you when you are learning to code but also in your first job when you need to ask for help.

看看“好”示例如何提供更多信息？ 更多信息使其他善良的開發人員可以更輕松地為您提供幫助。 這是一個良好的習慣，因為它不僅在您學習編程時對您有所幫助，而且在您需要尋求幫助時會在您的第一份工作中受益。

So where can you ask for help?

那么，您可以在哪里尋求幫助？

• StackOverflow
  堆棧溢出
• Twitter
  推特
• Slack groups
  松弛組
• Colleagues or developer friends
  同事或開發者朋友

Quick Tip: You can use a tool like CodeSandbox.io or CodePen.io to recreate your problem and share it with people.

快速提示：您可以使用CodeSandbox.io或CodePen.io之類的工具來重新創建問題并與他人共享。

練習練習 (Practice, practice, practice)

Just like Rome wasn't built in a day (well, it could have been for all I know) you will not become king bug squasher overnight. As your career goes on and your experience grows, you'll be armed with a wealth of knowledge that helps you solve bugs and issues faster. I regularly find myself saying "ah, I've solved that before" or "oh yeah, I have a StackOverflow link that helps me here" and the whole thing becomes a lot easier. So keep practicing, and this skill will grow naturally.

就像羅馬不是一天建成的(好吧，據我所知)，您不會在一夜之間成為臭蟲搶劫者。 隨著您事業的發展和經驗的增長，您將獲得大量知識，可以幫助您更快地解決錯誤和問題。 我經常發現自己在說“啊，我之前已經解決了這個問題”或“哦，是的，我有一個StackOverflow鏈接可以在這里幫助我”，整個過程變得容易得多。 因此，繼續練習，該技能將自然增長。

Thanks for reading! If you enjoyed this article, why not subscribe to my newsletter?

謝謝閱讀！ 如果您喜歡這篇文章， 為什么不訂閱我的新聞通訊呢？

Every week I send out a list of 10 things I think are worth sharing — my latest articles, tutorials, tips and interesting links for upcoming developers like you. I also give out some free stuff from time to time :)

每周，我都會發送一份我認為值得分享的10件事的清單 -我的最新文章，教程，技巧和有趣的鏈接，為像您這樣的即將來臨的開發人員提供。 我也會不時提供一些免費的東西:)

翻譯自: https://www.freecodecamp.org/news/the-beginner-bug-squashing-guide/

谷歌瀏覽器bug調試快捷鍵

總結

以上是生活随笔為你收集整理的谷歌浏览器bug调试快捷键_Bug压榨初学者指南：如何使用调试器和其他工具查找和修复Bug的全部內容，希望文章能夠幫你解決所遇到的問題。

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