Das Handbuch für Anfänger zum Squashing von Fehlern: So verwenden Sie Ihren Debugger und andere Tools, um Fehler zu finden und zu beheben

Als Webentwickler haben wir oft das Gefühl, dass wir mehr Zeit damit verbringen, Fehler zu beheben und Probleme zu lösen, als Code zu schreiben. In diesem Handbuch werden einige gängige Debugging-Techniken vorgestellt.

"Nicht vorbereiten, nicht vorbereiten"

Wie könnte man einen Artikel besser beginnen als mit einem alten Klischee? Fehler und Probleme werden auftauchen. Es gibt einfach keine Möglichkeit, davon wegzukommen (sorry). Mit einer einfachen Planung gibt es Möglichkeiten , die Komplexität und Anzahl der Probleme, mit denen wir konfrontiert sind, zu minimieren .

Teilen Sie die Aufgabe in kleinere Aufgaben auf

Nun, ich verstehe, wir alle möchten sehr aufgeregt sein und direkt in unsere Codierungsprojekte eintauchen. Die Sache ist, ohne irgendeinen Plan schaffen wir Probleme für uns selbst, bevor wir überhaupt anfangen!

Wenn ich zu Ihnen sagen würde: "Sie müssen eine Einkaufslisten-App erstellen" und Sie sofort mit dem Codieren beginnen, was würde dann passieren? Sie würden am Ende auf einen blinkenden Cursor starren und sich fragen, wie oder was Sie zuerst tun sollen, und meinen Namen verfluchen, weil Sie Sie gebeten haben, eine solche Aufgabe zu erledigen.

Es ist immer einfacher, ein großes Problem in viele kleinere Probleme aufzuteilen. Zum Beispiel können wir das Einkaufslistenprojekt in kleinere Aufgaben aufteilen:

  • Erstellen Sie ein Formular, um der Liste ein Element hinzuzufügen
  • Ermöglichen Sie einem Benutzer, ein Element aus der Liste zu entfernen
  • Zeigen Sie die Gesamtzahl der Elemente in der Liste an

Sie können diese Aufgaben sogar in detailliertere Aufgaben aufteilen. Zum Beispiel könnte für die erste Aufgabe in unserer Liste unsere erste "kleine Mini-Aufgabe" (sollte ich diesen Begriff als Marke kennzeichnen?) Sein:

1) Erstellen Sie ein Eingabefeld, um den Elementnamen zu erfassen

2) Erstellen Sie eine Schaltfläche, die addToList()beim Klicken Funktionen aufruft

3) Schreiben Sie eine Logik in die addToList()Funktion, die das Element zur Liste hinzufügt

Und so weiter. Du hast die Idee. Ich ziehe es vor, die Arbeit so abzubrechen, da ich wirklich über die Probleme nachdenke, auf die ich früh stoßen werde, und über die Lösungen (ich habe hier einen ausführlichen Artikel darüber geschrieben), bevor ich Code geschrieben habe. Es hilft mir auch zu verstehen, was ich versuche, und bringt mich in die "Zone". Es ist viel einfacher, Probleme zu lösen, die auftreten, wenn Sie verstehen, was Sie erreichen möchten.

Seien Sie bereit, Ihren Code zu löschen

Um ein Omelett zu machen, müssen wir ein paar Eier zerbrechen. Dies bedeutet, dass Sie bereit sind, unseren Code komplett neu zu schreiben, damit er funktioniert.

Ich wette, Sie denken: "Oh Mann, ich habe Tage / Wochen / Jahrtausende gebraucht, um mit meinem Code so weit zu kommen, und jetzt muss ich ihn löschen?!" Hm ja. Manchmal. Es tut uns leid. Die Realität bei der Webentwicklung ist, dass sich der Code aus verschiedenen Gründen ständig ändert - Fehler, Codeüberprüfungen, Änderungen der Anforderungen, Langeweile usw.

Manchmal fühlen wir uns in Bezug auf unseren Code so wertvoll und können es nicht ertragen, ihn zu löschen, dass wir versuchen, Probleme zu überwinden, indem wir versuchen, "einen runden Stift in ein quadratisches Loch zu stecken". Wir denken "NEIN! Ich kann diese Methode unmöglich löschen. Es hat ewig gedauert. Es muss einen Weg geben!" Diese mentale Blockade verursacht unsere eigenen Probleme - denn indem wir einfach das umschreiben, was wir derzeit haben, können wir die Lösung für unsere Probleme finden.

Jetzt, da wir nett und vorbereitet sind, schauen wir uns an, was passiert, wenn etwas schief geht.

Fehlermeldungen sind gut

Was ist schlimmer als eine Fehlermeldung zu sehen, wenn etwas schief geht? Keine Fehlermeldung angezeigt, wenn etwas schief geht. Obwohl es ein entmutigendes Gefühl ist, eine große rote Stapelspur zu sehen, wenn wir unseren sorgfältig ausgearbeiteten Code ausführen, werden Fehlermeldungen angezeigt, die besagen: "Ja, die Dinge sind im Moment durcheinander, aber hier sind einige Stellen, an denen Sie nachsehen können, um sie zu reparieren." .

Wenn wir uns dieses Beispiel ansehen:

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

Schauen wir uns nun den Fehler an:

TypeError: Cannot read property 'push' of undefined at addAnimal (//vanilla.csb.app/src/index.js:8:11) at evaluate (//vanilla.csb.app/src/index.js:11:1) at $n (//codesandbox.io/static/js/sandbox.acff3316.js:1:148704)

Ich habe einen Teil der Stapelspur weggelassen, da das meiste davon Kauderwelsch ist. Abhängig davon, wie Ihr Frontend-Projekt mit Fehlermeldungen umgeht, wird der Fehler möglicherweise sogar in Ihrem Browser angezeigt:

Die wichtigen Teile der Stapelverfolgung befinden sich normalerweise oben - die Nachricht, die Funktion und die Zeilennummer, und unser Browser zeigt uns dies ebenfalls an. Der Dolmetscher sagt uns am besten, was los ist. Es ist eine Schande, dass es das Problem für uns nicht lösen kann, oder?

Wir haben also unsere Panikattacke beendet, als wir den Fehler gesehen haben, und haben einige Informationen aus der Fehlermeldung ausgewählt. Wenn wir es aufschlüsseln, können wir diese Zeile sehen:

Cannot read property 'push' of undefined

Dies bedeutet normalerweise, dass eine Variable nicht irgendwo definiert oder initialisiert ist. ABER WO?!?

Wenn wir den Stack-Trace weiter lesen, sehen wir, dass der Fehler innerhalb der addAnimal()Funktion auftritt . Wir können sehen, dass wir versuchen, ein neues Tier in eine Reihe zu schieben - ah! Ich habe vergessen, das animalsArray zu initialisieren . Doh! Unser fester Code sieht folgendermaßen aus:

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

Der im Browser ausgelöste Fehler zeigt Ihnen das Problem schneller, aber nicht alle Frontend-Projekte sind dafür konfiguriert, und Backend-Entwickler haben diesen Luxus nicht. Aus diesem Grund empfehle ich, das Lesen des Stack-Trace zu lernen.

Um den Fehler zu besiegen, müssen Sie wie der Fehler denken

Die Stapelverfolgung gibt Ihnen eine Vorstellung davon, was der Fehler ist. Nun, manchmal schon und manchmal nicht. Was ist, wenn Sie eine Fehlermeldung sehen, die eher wie Höhlenzeichen als wie Englisch aussieht? Oder was ist, wenn kein Fehler vorliegt, Ihr Code jedoch einfach nicht so funktioniert, wie Sie gedacht haben?

Es ist Zeit, den Debugger herauszubekommen. Lassen Sie uns ein anderes Beispiel durchgehen. Aber zuerst etwas Kontext!

Mr. Bob CEO (wer ist ein CEO, wer hätte das gedacht?!) Kommt auf Sie zu und sagt:

"Hey, ich habe eine tolle Idee für ein Produkt.

  • Ich möchte eine Web-App, mit der der Benutzer eine Nummer eingeben kann.
  • If the number is less than 5, the message should read "UNDER".
  • If the number is equal to or more than 5, the message should read "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!

    My super awesome number app      Submit 0 
(function () { const numberInputSubmitButton = document.getElementById("number-input-submit-button") numberInputSubmitButton.addEventListener("click", function () { const numberInputValue = document.getElementById("number-input").value; let text; if(numberInputValue > 5) { text = "OVER"; } else { text = "UNDER"; } document.getElementById("number-display").innerHTML = text }); })(); 

(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:

2) User enters 7

So far so good! But what happens if we enter 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.

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.

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:

  • 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)

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?

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...

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.

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
  • 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 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 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?

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:

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.

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?

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.

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."

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.

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.

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 :)