Sådan forbedres dine fejlretningsfærdigheder

Vi skriver alle kode, der går i stykker på et eller andet tidspunkt. Det er en del af udviklingsprocessen. Når du støder på en fejl, kan du føle, at du ikke ved, hvad du skal gøre. Men selv de mest erfarne udviklere introducerer fejl og fejl, der bryder deres kode. Vi er trods alt mennesker.

Det vigtige er at lære af disse fejl og undgå at gentage dem ved at udvikle teknikker til at forbedre dine programmerings- og fejlretningsfærdigheder. Fejl er primært logiske eller syntaktiske. Nogle af dem manifesterer sig via undtagelser eller nedbrud, mens andre kun kan observeres, når du bruger softwaren.

Her er nogle af de fejl, som udviklere laver

Manglende logmeddelelser

Et af de mest hjælpsomme scenarier, du kan løbe ind i, er, når dit program går ned, og der ikke er nogen fejlmeddelelser, der angiver, hvad der gik galt. Det første trin er at identificere, om programmet går ned ved start eller under kørsel. Du kan opnå dette ved at udskrive en simpel logbesked til terminalen i begyndelsen af ​​din kode.

Hvis du ikke ser din logmeddelelse, kolliderer dit program sandsynligvis under indlæsning, og det er muligvis et afhængigheds- eller bygningsrelateret problem.

Hvis du ser din besked, skal du indsnævre til den generelle nærhed af nedbruddet. Den bedste måde er at placere nogle logbeskeder strategisk i hele dit program afhængigt af, hvor meget information du har om udførelsesstien, når den går ned. Derefter er alt, hvad du skal gøre, at se, hvilke meddelelser der udskrives.

Fejlmeddelelser kan ikke læses

Undtagelsesmeddelelser på frontend vises normalt på brugergrænsefladen eller udviklerkonsollen. Nogle gange er disse meddelelser synlige i backend gennem terminalen eller via logfiler. Uanset hvor disse fejl opstår, skræmmes nye udviklere af dem og tager ikke tid til at læse dem.

Dette er den førende årsag til, at fejlretning tager længere tid for mange udviklere. Den første ting du skal gøre er at tage dig tid til at læse fejlmeddelelsen foran dig, lade den synke ned og behandle den grundigt.

Manglende læsning af systemlogfiler

Nogle programmer genererer logfiler eller skriver til systemhændelsesloggen. Der er ofte nyttige oplysninger i disse logfiler. Selvom det ikke fortæller dig nøjagtigt, hvad der er forkert, kan der være en advarsel eller en fejlmeddelelse eller endda en succesmeddelelse, der giver et tip om, hvad der skete, før fejlen opstod.

Manglende skrivning af sporingslogfiler

Sporing følger dit programflow og dine data. Skrivning af sporingsmeddelelser i hele dit program hjælper med at forenkle fejlretningsprocessen. Trace Logs er en nem måde at holde styr på programudførelse i hele din applikations kørselstid.

Undlader at foretage trinvise ændringer, opbygge dem og teste dem

Mange udviklere skriver store stykker kode, før de bygger og tester den. Tiden til at finde fejl øges proportionalt med mængden af ​​kode, der blev ændret. Du skal stræbe efter at foretage trinvise ændringer, opbygge dem og teste dem så ofte som muligt. Dette vil sikre, at du ikke ender i en situation, hvor der blev skrevet meget kode, før du opdager, at dit program ikke fungerer.

Ofte vil jeg endda omlægge min kode for at forenkle det, jeg har skrevet.

Mangler ikke at skrive testautomatisering

Enhedstest og end-to-end-automatisering giver dig mulighed for at opfange potentielle fejl, når de sker. En af grundene til, at eksisterende kodebrud er, at udviklere refaktorer deres kode, når de har lav testdækning, hvilket betyder, at alle ændringer ikke testes automatisk.

Manglende anvendelse af eliminationsmetoden

Hvis du ikke er i stand til at identificere årsagen til dit problem, skal du bruge metoden til eliminering. Du kan kommentere nye kodeblokke for at se, om fejlene stopper. Fjernelse af kodeblokke hjælper dig med at komme tættere på at diagnosticere problemet.

Du kan danne en bestemt hypotese og prøve at bevise eller modbevise den. Mange gange kan en simpel antagelse forhindre dig i at finde fejl.

Kopiering og indsætning fra StackOverflow

Ofte kopierer og indsætter udviklere kode fra stackoverløb uden at forstå, hvad det gør. Dette har så mange bivirkninger. For det første er det vigtigt, at du er opmærksom på, hvad der følger med din ansøgning.

Oftere end jeg gerne vil, når jeg skriver et spørgsmål om StackOverflow og tænker på, hvordan man effektivt artikulerer det, ender jeg med at besvare mit eget spørgsmål!

På samme måde besvarer jeg nogle gange mit eget spørgsmål, når jeg taler med andre medlemmer af teamet. Dette sker, fordi det tvinger dig til at tænke over din løsning.

Mislykkes med at løse deres problem igen

En af de mest succesrige fejlretningsteknikker, jeg har fundet, er at prøve at gå igennem din løsning igen og igen og i nogle tilfælde prøve at genimplementere visse funktioner fra bunden. Dette tvinger dig til at finde potentielle problemer ved at genskabe din implementering.

Mislykkes med at gå tilbage

Normalt, hvis du kan isolere symptomerne til et bestemt område, kan du begynde at gå op på opkaldsstakken for at kontrollere alle variabler og forventede værdier. Dette kan hurtigt føre dig til at afdække dele af dit program, hvor tingene opfører sig uventet.

Mangler at lære debugger

Endelig er den bedst investering, du kan foretage i dig selv, at lære at bruge en debugger. Alle IDE'er har kraftfulde debuggere. De følger de samme grundlæggende begreber. De giver dig mulighed for programmatisk at stoppe udførelsen af ​​din applikation, enten ved start eller i en bestemt del af programflowet.

Der er også masser af fejlretningsværktøjer, der kan hjælpe i denne proces.

Hvis denne artikel var nyttig, ??? og følg mig på Twitter.

GitHub-udvidelser for at øge din produktivitet

Her er GitHub-udvidelser, som jeg bruger. De giver dig mulighed for at forbedre din produktivitet på GitHub. Del venligst din ... medium.freecodecamp.org