Kezdő útmutató a hibakereséshez: Hogyan használhatjuk a hibakeresőt és más eszközöket a hibák megtalálásához és kijavításához

Webfejlesztőként gyakran úgy érezzük, hogy több időt töltünk a hibák kijavításával és a problémák megoldásával, mint kódírással. Ebben az útmutatóban áttekintünk néhány általános hibakeresési technikát, ezért ragaszkodjunk hozzá.

"Nem készül fel, készül fel a kudarcra"

Mi a jobb módja annak, hogy cikket kezdjünk, mint egy régi közléssel! A hibák és a problémák fel fognak tűnni. Ettől egyszerűen nincs mód megúszni (sajnálom). Néhány egyszerű tervezéssel vannak olyan módszerek, amelyekkel minimalizálhatjuk az összetett problémák összetettségét és számát.

Bontsa fel a feladatot kisebb feladatokra

Most már értem, mindannyian szeretünk nagyon izgulni és egyenesen belemerülni a kódolási projektjeinkbe. A helyzet az, hogy valamiféle terv nélkül problémákat okozunk magunknak, még mielőtt elkezdenénk!

Ha azt mondanám neked: "Be kell építened egy bevásárló listás alkalmazást", és azonnal kódolni kezdtél, mi történne? Végül egy villogó kurzort nézegetne azon, hogy vajon hogyan vagy mit tegyen először, és átkozta a nevemet az orra alatt, amiért ilyen feladat elvégzésére kért.

Mindig könnyebb egy nagy problémát felvenni és sok kisebb problémára bontani. Például feloszthatjuk a bevásárlólista projektet kisebb feladatokra:

  • Hozzon létre egy űrlapot egy elem hozzáadásához a listához
  • Engedje meg, hogy a felhasználó eltávolítson egy elemet a listáról
  • A lista összes elemének megjelenítése

Ezeket a feladatokat akár részletesebb feladatokra is felbonthatja. Például a listánk első feladatához az első, "kis mini feladatunk" (védjegyeznem kellene ezt a kifejezést?) Lehet:

1) Hozzon létre egy beviteli mezőt az elem nevének rögzítéséhez

2) Hozzon létre egy gombot, amely addToList()kattintással meghív egy funkciót

3) Írjon logikát azon addToList()függvényen belül, amely hozzáadja az elemet a listához

Stb. Megkapja az ötletet. Jobban szeretem az ilyen szakítást, mivel ez valóban elgondolkodtat azon a problémákon, amelyekkel korán találkozom, és a megoldásokra (itt írtam erről egy részletes cikket), mielőtt bármilyen kódot írtam volna. Ez segít abban is, hogy megértsem, mit akarok csinálni, és a „zónába” helyez. Sokkal könnyebb megoldani a felmerülő problémákat, ha megérted, mit akarsz elérni.

Készüljön fel a kód megtisztítására

Omlett készítéséhez néhány tojást el kell törnünk. Ez azt jelenti, hogy felkészültünk arra, hogy teljesen újraírjuk a kódunkat, hogy működőképes legyen.

Fogadok, hogy arra gondolsz: "ó, ember, napok / hetek / évezredek kellettek, mire idáig eljutottam a kódommal, és most törölnöm kell ?!" Ja, igen. Néha. Sajnálom. A webfejlesztéssel a valóság az, hogy a kód folyamatosan változik, különféle okokból - hibák, kódellenőrzések, követelmények változása, unalom stb.

Néha olyan értékesnek érezzük magunkat kódunk iránt, és nem tudjuk elviselni a törlését, hogy megpróbáljuk legyőzni a problémákat azzal, hogy megpróbálunk "egy kerek csapot egy négyzet alakú lyukba illeszteni". Azt gondoljuk, hogy "NEM! Ezt a módszert nem tudom törölni. Örökké tartott. Van egy út!" Ez a mentális blokk saját problémáinkat okozza - mert egyszerűen átírva azt, ami jelenleg van, megtalálhatnánk a megoldást problémáinkra.

Most, hogy kedvesek és felkészültek vagyunk, nézzük meg, mi történik, ha rosszul alakulnak a dolgok.

A hibaüzenetek jók

Mi a legrosszabb, ha hibaüzenetet látunk, ha valami nem megfelelő Nem lát semmilyen hibaüzenetet, ha valami nem megfelelő. Annak ellenére, hogy ijesztő érzés látni egy nagy piros verem nyomot, amikor futtatjuk a gondosan kialakított kódunkat, hibaüzenetek vannak, amelyek azt mondják, hogy "igen, a dolgok jelenleg el vannak zavarva, de itt van néhány hely, ahol elkezdheted kijavítani" .

Ha megnézzük ezt a példát:

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

Most nézzük meg a hibát:

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)

A veremnyomok egy részét kihagytam, mivel nagy része ziccer. Attól függően, hogy a frontend projekt hogyan kezeli a hibaüzeneteket, még a böngészőben is láthatja a hibát:

A verem nyomkövetésének fontos részei általában a legfelső részen vannak - az üzenet, a funkció és a sor száma, és ezt böngészőnk is megmutatja nekünk. Tehát a tolmács a legjobb, ha elmondja nekünk, mi a baj. Kár, hogy számunkra nem tudja megoldani a problémát, mi?

Tehát befejeztük a pánikrohamot, amikor megláttuk a hibát, és kivettünk néhány információt a hibaüzenetből. Ha lebontjuk, láthatjuk ezt a sort:

Cannot read property 'push' of undefined

Ez általában azt jelenti, hogy van olyan változó, amelyet valahol nem definiáltak vagy inicializáltak. DE HOL?!?

Ha folytatjuk a veremkövetés beolvasását, látjuk, hogy a hiba a addAnimal()függvényen belül jelentkezik . Láthatjuk, hogy egy új állatot próbálunk egy tömbhöz tolni - ah! Elfelejtettem inicializálni a animalstömböt. Doh! A fix kódunk így néz ki:

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

A böngészőbe dobott hiba gyorsabban megmutatja a problémát, de nem minden frontend projektet állítanak be erre, és a backend fejlesztői nem rendelkeznek ezzel a luxussal. Ezért ajánlom megtanulni a verem nyomkövetését.

A hiba legyőzéséhez úgy kell gondolkodnia, mint a hibának

A verem nyomkövetése képet ad arról, hogy mi a hiba. Nos, néha igen, és néha nem. Mi van, ha olyan hibaüzenetet lát, amely jobban hasonlít a barlangjelekre, mint az angolra? Vagy mi van, ha nincs hiba, de a kódod egyszerűen nem úgy működik, ahogy gondoltad?

Ideje kimenekíteni a hibakeresőt. Menjünk át egy másik példán. De először valami kontextus!

Mr. Bob vezérigazgató (aki vezérigazgató, ki gondolta volna ?!) odalép hozzád és azt mondja:

"Hé, elképesztő ötletem van egy termékről.

  • Szeretnék egy webalkalmazást, amely lehetővé teszi a felhasználó számára, hogy megadjon egy számot.
  • Ha a szám kevesebb, mint 5, akkor az üzenetnek "ALÁ" -nak kell lennie.
  • Ha a szám egyenlő vagy nagyobb, mint 5, akkor az üzenetnek "OVER" feliratúnak kell lennie.

Ez egy millió dolláros ötlet, és azt akarom, hogy építsen nekem. "

"OKÉ!" Azt mondod, és nekilátsz a munkának.

* Kódoló montázs drámai zenével játszik, ahogy előre halad előre *

Elkészítette webalkalmazásának kódját. 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 }); })(); 

(Megjegyzés: Lehet, hogy már észrevette a hibát. Ha mégis, tegyünk úgy, mintha nem. Ha nem vette észre a hibát, akkor rendben van.)

Ideje elkezdeni a tesztelést. Futtassunk át néhány üzleti esetet az üzleti logikánkhoz.

1) A felhasználó megadja a 3 értéket:

2) A felhasználó beírja a 7-et

Eddig jó! De mi történik, ha belépünk az 5-be?

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