Hvordan debugges kode mest effektivt? [lukket]

Mindset og holdning til debugging er måske den den vigtigste del, fordi den bestemmer, hvor effektivt du “løser fejlen, og hvad du” lærer af den – hvis noget.

Klassikere om softwareudvikling som The Pragmatic Programmer og Code Complete argumenterer grundlæggende for den samme tilgang: enhver fejl er en mulighed for at lære, næsten altid om dig selv (fordi kun begyndere bebrejder compileren / computeren først).

Så behandl det som et mysterium, som det vil være interessant at knække. Og at knække dette mysterium skal gøres systematisk ved at udtrykke vores antagelser (til os selv eller til andre) og derefter teste vores antagelser, en efter en, hvis det er nødvendigt – ved hjælp af ethvert værktøj til vores rådighed, især debuggere og automatiserede testrammer. Derefter, efter at mysteriet er løst, kan du gøre det endnu bedre ved at kigge igennem al din kode efter lignende fejl, du måske har lavet; og skriv en automatiseret test for at sikre, at fejlen ikke sker ubevidst igen.

En sidste note – jeg foretrækker at kalde fejl for “fejl” og ikke “bugs” – Dijkstra chiplede sine kolleger for at bruge det sidstnævnte udtryk, fordi det er uærligt og understøtter ideen om, at ondskabsfulde og ustabile bugfeer plantede bugs i vores programmer, mens vi ikke kiggede i stedet for at være der på grund af vores egen (sjuskete) tænkning: div> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Vi kunne for eksempel begynde med at rydde op i vores sprog ved ikke længere kalde en fejl en fejl, men ved at kalde den en fejl. Det er meget mere ærligt, fordi det helt og holdent lægger skylden, hvor den hører hjemme, dvs. med programmøren, der lavede fejlen. Den animistiske metafor af bugten, som ondskabsfuldt sneg sig ind, mens programmøren ikke kiggede, er intellektuelt uærlig, da den skjuler, at fejlen er programmørens egen oprettelse. Det pæne ved denne enkle ændring af ordforråd er, at den har en så dybtgående effekt. : mens et program med kun en fejl tidligere var “næsten korrekt”, er et program med en fejl bagefter bare “forkert” (fordi det ved en fejltagelse).

Kommentarer

• Faktisk kan jeg godt lide udtrykket " fejl " snarere end " bug ", ikke fordi det lægger skylden på " programmøren der lavede fejlen ", men fordi det gør det klart, at det muligvis ikke har været programmøren, der skyldte. For mig er " bug " indebærer fejl i koden; mens " erro r " indebærer fejl et eller andet sted . Måske i koden, måske i miljøopsætningen, måske i kravene. Gør mig nød, når min chef har en " bugliste " hvor halvdelen af spørgsmålene er kravændringer. Kald det en opgaveliste, ferchrissakes!
• +1 for " enhver fejl er en mulighed for at lære, næsten altid om dig selv (fordi kun begyndere bebrejder compileren / computer først) "
• Du er opmærksom på historien om udtrykket " bug ", ikke? Jeg mener, som brugt i softwareudvikling. Selvfølgelig har vi ' ikke dette problem i dag, men en fejl fløj faktisk ind i hardware på en computer ubemærket af programmøren og forårsagede et problem.For at nogen synes at rette mig, ved jeg, at Edison brugte dette udtryk længe før mølhændelsen, hvorfor jeg brugte ordet ' historie ', ikke ' oprindelse '. Se computerworld.com/article/2515435/app-development/… og da.wikipedia.org/wiki/Software_bug#Etymology
• @threed Selvfølgelig. Men i nogen tid har insekter ikke forårsaget langt størstedelen af softwarefejl.

1. Skriv test. Testning er ikke kun fantastisk til at forhindre bugs (efter min erfaring eliminerer TDD rigtigt næsten alle trivielle, dumme bugs), men hjælper også meget med fejlfinding. Test tvinger dit design til at være ret modulært, hvilket gør det meget lettere at isolere og replikere problemet. Du styrer også miljøet, så der bliver meget mindre overraskelser. Desuden kan du, når du først får en fejltagende testsag, være rimelig sikker på, at du har neglet den virkelige årsag til den adfærd, der generer dig.

2. Lær hvordan du bruger en debugger. print udsagn fungerer muligvis rimeligt godt på et eller andet niveau, men en debugger er for det meste meget nyttigt (og en gang du ved, hvordan du bruger det, det er meget mere behageligt end print udsagn).

3. Tal om nogen om dit problem, selvom det bare er en gummiduckie . At tvinge dig selv til at udtrykke det problem, du arbejder på med ord, gør virkelig mirakler.

4. Giv dig selv en frist. Hvis du for eksempel efter 45 minutter føler, at du ikke kommer nogen steder, skal du bare skifte til andre opgaver i nogen tid. Når du kommer tilbage til din fejl, vil du forhåbentlig være i stand til at se andre mulige løsninger, som du ikke tidligere havde overvejet.

Kommentarer

• +1 for " At tvinge dig selv til at udtrykke det problem, du arbejder på med ord, gør virkelig mirakler. "
• Og for at tilføje til (1) betyder næsten enhver fejl, du ser i koden, at der ' en fejl – eller i det mindste en udeladelse – i testpakken. Løs begge på samme tid og ikke kun beviser du, at du ' har løst problemet ved hånden, du ' er sikker på, at det ikke er genindført.

Jeg kan godt lide de fleste af de andre svar, men her er nogle tip til hvad man skal gøre FØR du gør noget af det. Sparer dig for tiden.

1. Find ud af, om der virkelig er en fejl. En fejl er ALTID en forskel mellem systemadfærd og krav; testeren burde være i stand til at formulere forventet og faktisk adfærd. Hvis han ikke er i stand til at yde support til den forventede adfærd, er der ikke noget krav, og der er ingen fejl – bare en persons mening. Send den tilbage.

2. Overvej muligheden at den forventede adfærd er forkert. Dette kan skyldes en fejlagtig fortolkning af kravet. Det kan også skyldes en fejl i selve kravet (et delta mellem et detaljeret krav og et forretningskrav). Du kan også sende disse tilbage.

3. Isoler problemet. Kun erfaring lærer dig den hurtigste måde at gøre dette på – nogle mennesker kan næsten gøre det med deres tarm. En grundlæggende tilgang er at variere en ting, mens holde alle andre ting konstant (opstår problemet i andre miljøer? med andre browsere? i en anden testregion? på forskellige tidspunkter af dagen?) En anden tilgang er at se på stack dumps eller fejlmeddelelser – nogle gange kan du fortælle bare forresten er det formateret, hvilken komponent i systemet, der kastede den originale fejl (f.eks. hvis det er på tysk, kan du bla mig den tredjepart, du arbejder med i Berlin).

4. Hvis du har indsnævret det til to systemer, der samarbejder, skal du inspicere meddelelserne mellem de to systemer via trafikovervågning eller logfiler. , og bestem hvilket system der opfører sig specifikt, og hvilket ikke. Hvis der er mere end to systemer i scenariet, kan du udføre parvise kontroller og arbejde dig “ned” i applikationsstakken.

5. Årsagen til at isolere problemet er så kritisk er, at problemet muligvis ikke skyldes en mangel i kode, som du har kontrol over (f.eks. tredjepartssystemer eller miljøet), og du vil få den part til at overtage så hurtigt som muligt. Dette er både for at spare dig for arbejde og for at få dem til punkt med det samme, så opløsning kan opnås inden for en så kort tidsramme som muligt. Du vil ikke arbejde på et problem i ti dage kun for at finde det virkelig er et problem med en andens webtjeneste.

6. Hvis du har fastslået, at der virkelig er en fejl, og det virkelig er i koden, du styrer, kan du yderligere isolere problemet ved at kigge efter den sidste “kendte gode” build og inspektion af kildekontrologfiler for ændringer, der kan have forårsaget problemet. Dette kan spare meget tid.

7. Hvis du ikke kan finde ud af det fra kildekontrol, er det nu tid til at vedhæfte din debugger og gå gennem koden for at finde ud af det ud. Chancerne er nu, at du alligevel har en ret god idé om problemet.

Når du først ved, hvor fejlen er, og kan tænke på en løsning, her er det godt procedure til løsning af det:

1. Skriv en enhedstest, der gengiver problemet og mislykkes.

2. Uden at ændre enhedstesten, lav det passerer (ved at ændre applikationskode).

3. Hold enhedstesten i din testpakke for at forhindre / opdage regression.

Jeg synes gengivelsen af en fejl også er vigtig. Alle sager, der reproducerer bugten, kan vises, og derefter kan du sørge for, at din bug fix dækker alle disse sager.

Der er en fremragende bog, jeg læste om dette emne, kaldet Hvorfor programmer mislykkes , som skitserer forskellige strategier for at finde fejl lige fra anvendelse af den videnskabelige metode til at isolere og løse en bug, til delta debugging. Den anden interessante del af denne bog er, at den fjerner udtrykket “bug”. Zellers tilgang er:

(1) En programmør opretter en fejl i koden. (2) Fejlen forårsager en infektion (3) Infektionen formerer sig (4) Infektionen forårsager en fiasko.

Hvis du vil forbedre dine fejlretningsfærdigheder, kan jeg varmt anbefale denne bog.

I min egen personlige erfaring har jeg fundet masser af fejl i vores applikation, men ledelsen presser os blot videre for at få nye funktioner ud. Jeg har ofte hørt “Vi har fundet denne fejl selv, og klienten har ikke bemærket det endnu, så lad det bare være, indtil de gør det”. Jeg synes at være reaktiv i modsætning til proaktiv i at rette bugs er en meget dårlig idé, da når tiden er inde til faktisk at rette en løsning, har du andre problemer, der skal løses, og flere funktioner ledelse ønsker ud af døren ASAP, så du bliver fanget i en ond cirkel, der kan føre til meget stress og udbrændthed og i sidste ende et defektkørt system.

Kommunikation er også en anden faktor, når der findes fejl. Afsendelse af en e-mail eller dokumentation af den på bug tracker er alt sammen fint og godt, men efter min egen erfaring finder andre udviklere en lignende bug og i stedet for at genbruge den løsning, du har sat til at rette koden (da de har glemt alt om det), tilføjer de deres egne versioner, så du har 5 forskellige løsninger i din kode, og det ser mere oppustet og forvirrende ud som et resultat. Så når du løser en fejl, skal du sørge for, at et par mennesker gennemgår rettelsen og giver dig feedback, hvis de har rettet noget lignende og fandt en god strategi til at håndtere det.

limist nævnte bogen,