Begyndervejledningen til bug squashing: Sådan bruges din fejlfindingsværktøj og andre værktøjer til at finde og rette fejl

Som webudviklere føles det ofte som om vi bruger mere tid på at rette fejl og forsøge at løse problemer, end vi skriver kode. I denne vejledning ser vi på nogle almindelige fejlretningsteknikker, så lad os sidde fast i.

"Undlad at forberede, forberede sig på at mislykkes"

Hvilken bedre måde at starte en artikel på end med en gammel cliche! Fejl og problemer kommer til at dukke op. Der er simpelthen ingen måde at komme væk fra dette (undskyld). Med en simpel planlægning er der måder, hvorpå vi kan minimere kompleksiteten og antallet af problemer, vi står over for.

Opdel opgaven i mindre opgaver

Nu forstår jeg det, vi kan alle lide at blive meget begejstrede og dykke direkte ind i vores kodningsprojekter. Sagen er, uden nogen form for plan skaber vi problemer for os selv, før vi overhovedet starter!

Hvis jeg sagde til dig, "du skal oprette en indkøbsliste-app", og du begyndte at kode med det samme, hvad ville der ske? Du ender med at stirre på en blinkende markør og spekulerer på, hvordan eller hvad du skal gøre først, og forbander mit navn under din ånde for at bede dig om at udføre en sådan opgave.

Det er altid lettere at tage et stort problem og opdele det i mange mindre problemer. For eksempel kan vi opdele indkøbslisteprojektet i mindre opgaver:

  • Opret en formular for at føje et element til listen
  • Tillad en bruger at fjerne et element fra listen
  • Vis et samlet antal varer på listen

Du kan endda opdele disse opgaver i mere detaljerede opgaver. For eksempel for den første opgave på vores liste kunne vores første, "lille mini-opgave" (skal jeg varemærke det udtryk?) Være:

1) Opret et indtastningsfelt for at fange varenavnet

2) Opret en knap, der kalder en funktion, addToList()når der klikkes på den

3) Skriv logik inden for den addToList()funktion, der føjer elementet til listen

Og så videre. Du får ideen. Jeg foretrækker at bryde arbejde op som dette, da det virkelig får mig til at tænke på de problemer, jeg vil støde på tidligt, og løsningerne (jeg har skrevet en dybtgående artikel om dette her), før jeg har skrevet nogen kode. Det hjælper mig også med at forstå, hvad jeg prøver at gøre, og sætter mig i "zonen". Det er meget lettere at løse problemer, der opstår, når du forstår, hvad du prøver at opnå.

Vær forberedt på at rense din kode

For at lave en omelet skal vi bryde et par æg. Dette betyder at være parat til at omskrive vores kode fuldstændigt for at få den til at fungere.

Jeg vedder på, at du tænker, "åh mand, det tog mig dage / uger / årtusinder at komme så langt med min kode, og nu skal jeg slette den ?!" Um, ja. Sommetider. Undskyld. Virkeligheden med webudvikling er, at kode vil ændre sig hele tiden af ​​forskellige årsager - bugs, kodevurderinger, ændringer i krav, kedsomhed osv.

Nogle gange føler vi os så dyrebare over vores kode og orker ikke at slette den, at vi prøver at overvinde problemer ved at forsøge at "passe en rund pind i et firkantet hul". Vi tænker "NEJ! Jeg kan umuligt slette denne metode. Det tog mig for evigt. Der må være en måde!" Denne mentale blokering forårsager vores egne problemer - for ved simpelthen at omskrive det, vi i øjeblikket har, kunne vi finde løsningen på vores problemer.

Nu hvor vi er pæne og forberedte, lad os se på, hvad der sker, når ting går galt.

Fejlmeddelelser er gode

Hvad er værre end at se en fejlmeddelelse, når noget går galt? Kan ikke se nogen fejlmeddelelse, når noget går galt. Selvom det er en skræmmende følelse at se et stort rødt stakspor, når vi kører vores omhyggeligt udformede kode, er der fejlmeddelelser for at sige "ja, ting er rodet lige nu, men her er nogle steder, du kan se for at begynde at rette det" .

Hvis vi ser på dette eksempel:

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

Lad os nu se på fejlen:

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)

Jeg har udeladt noget af staksporet, da det meste af det er, ja, pludrende. Afhængigt af hvordan dit frontend-projekt håndterer fejlmeddelelser, kan du endda se fejlen i din browser:

De vigtige dele af staksporet er normalt øverst - meddelelsen, funktionen og linjenummeret, og vores browser viser os det også. Så tolk gør det bedst at fortælle os, hvad der er galt. Det er en skam, at det ikke kan løse problemet for os, ikke?

Så vi er færdige med at få vores panikanfald ved at se fejlen og har valgt nogle oplysninger fra fejlmeddelelsen. Hvis vi nedbryder det, kan vi se denne linje:

Cannot read property 'push' of undefined

Dette betyder normalt, at der er en variabel, der ikke er defineret eller initialiseret et eller andet sted. MEN HVOR?!?

Hvis vi fortsætter med at læse stakksporingen, ser vi, at fejlen opstår inden for addAnimal()funktionen. Vi kan se, at vi prøver at skubbe et nyt dyr til en matrix - ah! Jeg glemte at initialisere animalsarrayet. Doh! Vores faste kode ser sådan ud:

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

Fejlen i browseren viser dig problemet hurtigere, men ikke alle frontend-projekter er konfigureret til at gøre dette, og backend-udviklere har ikke denne luksus. Dette er grunden til, at jeg anbefaler at lære at læse stacksporingen.

For at besejre fejlen skal du tænke som bugten

Stacksporingen giver dig en idé om, hvad fejlen er. Nogle gange gør det, og nogle gange gør det ikke. Hvad hvis du ser en fejlmeddelelse, der ligner huleglyffer end engelsk? Eller hvad hvis der ikke er nogen fejl, men din kode fungerer simpelthen ikke som du troede?

Det er tid til at få debuggeren ud. Lad os gennemgå et andet eksempel. Men først noget sammenhæng!

Mr. Bob CEO (hvem er administrerende direktør, hvem ville have troet ?!) henvender sig til dig og siger,

”Hej, jeg har en fantastisk idé til et produkt.

  • Jeg vil have en webapp, der giver brugeren mulighed for at indtaste et nummer.
  • Hvis antallet er mindre end 5, skal meddelelsen lyde "UNDER".
  • Hvis antallet er lig med eller mere end 5, skal meddelelsen lyde "OVER".

Dette er en million-dollar-idé, og jeg vil have dig til at bygge den til mig ".

"OKAY!" Du siger, og du kommer på arbejde.

* Kodning af montage med dramatisk musik, når tiden går hurtigt frem *

Du har udfyldt koden til din webapp. 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 }); })(); 

(Bemærk: Du har muligvis allerede set fejlen. Hvis du gjorde det, lad os lade som om du ikke gjorde det. Hvis du ikke har bemærket fejlen, er det OK.)

Tid til at starte test. Lad os gennemgå nogle brugssager til vores forretningslogik.

1) Bruger indtaster 3:

2) Bruger indtaster 7

Så langt så godt! Men hvad sker der, hvis vi går ind i 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

Ligesom Rom ikke blev bygget på en dag (ja, det kunne have været for alt, hvad jeg ved), bliver du ikke konge bug squasher natten over. Efterhånden som din karriere fortsætter, og din erfaring vokser, vil du være bevæbnet med et væld af viden, der hjælper dig med at løse fejl og problemer hurtigere. Jeg finder mig selv regelmæssigt og siger "ah, det har jeg løst før" eller "åh ja, jeg har et StackOverflow-link, der hjælper mig her", og det hele bliver meget lettere. Så fortsæt med at øve, og denne færdighed vokser naturligt.

Tak for læsningen! Hvis du kunne lide denne artikel, hvorfor ikke abonnere på mit nyhedsbrev?

Hver uge sender jeg en liste over 10 ting, som jeg synes er værd at dele - mine seneste artikler, tutorials, tip og interessante links til kommende udviklere som dig. Jeg giver også nogle gratis ting fra tid til anden :)