Hvordan fejlsøgning kan gøre dig til en bedre udvikler.

Inde i hvert stort program er der et lille program, der prøver at komme ud.

Billedkreditter: unsplash.com Jeshoots

Hvis jeg skulle opsummere min programmeringskarriere i 2 hårde sandheder, vil de være følgende.

· Alt, der muligvis kan gå galt, vil gå galt.

· Kode lugter.

Og den eneste færdighed, der kræves for at modvirke disse bitre virkeligheder, er fejlsøgning.

Ja, fejlsøgning. Ingen (eller næsten ingen!) Starter programmeringen med en kærlighed til debugging. I stedet er det ofte en kilde til frustration og frygt. ”Hvor mange timer skal jeg spilde med at løse denne fejl?”, Undrer mange af os. Vi vil hellere vende tilbage til at bygge seje ting. (Fordi hvem kan ikke lide at bygge seje ting !?)

Alligevel er det svært at finde en udvikler, som vi beundrer, som ikke betragter fejlfinding som vigtig. Det er fordi de ved, at det er en uvurderlig kilde til vækst for dem. Der er nogle få situationer, der tester dine evner som udvikler i det omfang, at fejlfinding vil.

Og det virkelige problem med fejlsøgning er, at det ikke er tilgængeligt for en tidsboks. Du kan timeboks næsten enhver aktivitet i programmering fra design til udvikling. Men debugging er en anden slags fisk helt. Med en debugging-session kan en time, en dag eller endda en uge komme og gå og finde dig ikke tættere på at finde og løse problemet.

Derfor bør du begynde at nærme sig debugging som en læringsmulighed. Sikker på, at smerten stadig vil være der, men du holder den under kontrol ved at gøre det på den rigtige måde.

Og her er nogle måder, hvorpå du kan være bedre til debugging.

Forstå systemet først

Vi begår ofte fejlen ved at ”forstå problemet” først og derefter ”forstå systemet”. Det skulle være omvendt.

For en tid tilbage debuggerede jeg et problem i en SAP smart form. Nogle værdier kom ikke ordentligt på formularen, jeg debugged hele formularen i to hele dage, og jeg kunne ikke finde problemet. Naturligvis var jeg frustreret. Der var ikke noget galt i den forbandede form. Så slog inspiration mig.

Jeg bemærkede, at formularen kaldes samtidig fra to steder i hovedkoden. Ved yderligere analyse fandt jeg, at problemet var i opkaldskoden og ikke i formen. Jeg løste problemet med en jippy. Min indsats i to dage krævede bare en meget meget mindre finjustering et andet sted.

Hvad gjorde jeg forkert her?

Jeg kunne ikke fejlsøge problemet, medmindre jeg forstod, hvordan systemet fungerede. Så snart jeg forstod det, var problemet åbenlyst.

Husk altid, at du har brug for en arbejdsviden om, hvad systemet skal, hvordan det er designet, og i nogle tilfælde hvorfor det blev designet på den måde. Hvis du ikke forstår en del af systemet, ser det altid ud til, at problemet er.

Angreb problemer isoleret

Jeg lærte denne vigtige klump af visdom på den hårde måde.

For en tid tilbage arbejdede jeg i et stort SAP-datamigreringsprojekt. Tidslinjerne var kritiske, og der skete for mange kodeblokke parallelt. Og på dette afgørende tidspunkt fik jeg et problem med datakorruption.

Nogle af de migrerede kundedata blev ødelagt, og det var en ydmyg opgave at finde ud af, hvad der gik galt i de millioner, der blev migreret. Jeg kendte til problemet, men hvor problemet eksisterede var hovedproblemet.

Til sidst løste jeg problemet med prototype. Jeg oprettede en lille prototype, der viste lignende symptomer med en undergruppe af data. Arbejdet med denne prototype fik mig til hovedårsagen, og til sidst blev problemet lukket.

Pointen her er at indsnævre søgningen.

Store systemer er komplicerede, og mange faktorer er involveret i deres udførelse. Når du arbejder med hele systemet, er det svært at adskille de detaljer, der påvirker dit særlige problem, fra dem, der ikke gør det.

Løsningen er splittelse og erobring. Forsøg ikke at arbejde med hele systemet på én gang. Adskil den komponent eller det modul, du har problemer med resten af ​​koden til alvorlig fejlsøgning.

At isolere et problem har mange fordele. Du er i stand til at fokusere direkte på de spørgsmål, der er relevante for problemet. Du kommer hurtigt til problemet, fordi du arbejder med en minimal mængde kode.

Husk altid, at det er svært for en fejl at holde sig skjult, når dens skjul bliver ved med at blive skåret i halve.

Skift et ting ad gangen

I en enkelt foring; Brug en rifle, ikke en hagle.

Lad mig forklare.

Forestil dig, at du skal fjerne en tand, og du besøger en tandlæge. Tandlægen “forsøger” at finde problemet og begynder at narre med alle dine tænder. Du stønner forgæves som en efter en bærer dine tænder angrebet på hans hammer.

Hvordan vil du have det? ”Hvad i helvede sker der. Kender fyren sit job? ”

Dårlig fejlsøgning fungerer nøjagtigt på samme måde.

Skift en ting ad gangen. Få dig en god riffel. Du vil være meget bedre til at rette fejl. Jeg har kendt udviklere, der forsøger at rette en dårlig kode ved blot at bytte eller tulle med andre komponenter. De kan ændre tre eller fire ting og opdage, hej, det fungerer nu. Det er lidt cool, bortset fra at de absolut ikke har nogen idé om, hvilken del der var den dårlige. Værre er, at alt det hacking kan ødelægge andre ting, der var fine, til at begynde med.

I mange tilfælde ønsker du at ændre forskellige dele af systemet for at se, om de påvirker problemet. Dette skal normalt være en advarsel om, at du gætter snarere end at kende koden godt nok til at se, hvad der foregår. Du ændrer betingelser i stedet for at lede efter fejlen, da den forekommer naturligt.

Dette kan skjule det første problem og forårsage mere. Dette er en illusionsfælde, som udviklere har brug for at undgå.

Husk altid, at du altid kan fortælle nøjagtigt, hvilken parameter der havde effekt, hvis du foretager en ændring ad gangen. Og hvis en ændring ikke ser ud til at have nogen virkning, skal du straks bakke den ud!

Kontroller, om det virkelig er din løsning, der fik det løst.

En gylden regel om fejlsøgning er, at hvis du ikke fikseret den, er den ikke rettet.

Alle vil tro, at fejlen netop forsvandt. ”Vi ser ikke ud til at få det til at mislykkes mere.” ”Det skete nogle gange, men giv, så skete der noget, og det holdt op med at mislykkes.” Og selvfølgelig er den logiske konklusion, ”Måske vil det ikke ske igen ." Gæt hvad? Det vil.

Undskyld at skuffe, men der er ingen magiske fe i den virkelige verden.

Når du tror, ​​at du har rettet en fejl, skal du fjerne rettelsen. Sørg for, at det er ødelagt igen. Sæt rettelsen tilbage i. Sørg for, at den er løst igen. Indtil du har cyklet fra fast til brudt og tilbage til fast igen og kun ændret den tilsigtede rettelse, har du ikke bevist, at du fikseret den.

Rettelser opfører sig ofte oftere på en sjov måde. Nogle gange ”skjuler” de sig snarere end faktisk at løse problemet. Og da vi er klar over, at rettelsen ikke har noget at gøre med problemet er blevet løst, ville produktet være sendt til kunden, som åbenbart ikke vil være tilfreds. Fald ikke i fælden.

Husk altid, hvis systemet mislykkes, som det plejede at bruge, når du kun fjerner rettelsen, kun kan du være temmelig sikker på, at fixen virkelig fungerer.

Og til sidst skal du opbevare en løsningslog

Dette lyder måske trivielt. Men det er et meget vigtigt problemløsningsværktøj, som ofte overses. Problemer opstår og vises igen i liv, arbejde og endda i forhold på flerårig basis. Og det giver ikke mening at opfinde hjulet igen og igen.

Med hensyn til, hvilken type information, der rent faktisk opretholdes i løsningslogfiler, er det vanskeligt at forudsige i betragtning af forskellige krav fra forretning til virksomhed. Generelt kan følgende poster dog overvejes.

· Problem #

· Initiativtager (der loggede opkaldet)

· Initiatorudvidelse eller telefonnummer

· Åbn dato / tid

· Resume Beskrivelse

· Virkning / betydning

· Type (fejl)

· Ejer (af system)

· Aktuel status (åben, under behandling, lukket)

· Næste skridt

· Næste trin dato

· Færdiggørelsesdato

· Opløsning, udviklingsanmodning # eller link til leverandørens supportanmodning

Bliv ikke forbrændt to gange. For at være mere produktive skal du vedligeholde en log over de problemer, der er stillet, og hvilke løsninger der findes. Når der opstår et problem, i stedet for at sige “Hej, jeg har set dette før. Men jeg har ingen anelse om, hvordan jeg fikseret det. ”, Du kan hurtigt slå den løsning, du har brugt i fortiden, op. Naturligvis sparer det ikke kun din tid, men øger din selvtillid og selvtillid til utænkelige niveauer.

Husk, at fejlsøgning er en læringsmulighed. Sikker på, nogle gange kan du indse, at du begik en fjollet fejl, som du ikke burde have gjort i første omgang. Men det er lige så meget en del af at blive en bedre udvikler som at lære en cool ny sprogfunktion.

Som Richard Pattis med rette har sagt.

”Ved fejlsøgning indsætter nybegyndere korrektiv kode; eksperter fjerner mangelfuld kode. ”
Om forfatteren-:
Ravi Rajan er en global it-programleder baseret fra Mumbai, Indien. Han er også en ivrig blogger, Haiku poesi skribent, arkæolog entusiast og historie gal. Opret forbindelse med Ravi på LinkedIn, Medium og Twitter.

Denne historie er offentliggjort i The Startup, Medium's største iværksætterpublikation efterfulgt af +418.678 personer.

Abonner for at modtage vores tophistorier her.