Stengt . Dette spørsmålet må være mer fokusert . Det aksepteres for øyeblikket ikke svar.

Kommentarer

  • Koblet spørsmål er fjernet.
  • Jeg synes tilnærmingen faktisk er enkel. Hvis du utviklet det alene, vet du alt om det. Du kan til og med fikse feilen uten feilsøking. Med det i tankene er den beste måten å bruke tiden din på å kode noe annet, til noen som vet mye om det kan svare på spørsmålet ditt om hvordan du løser det; eller la det hvile, kode andre ting, til en idé om å fikse det kommer opp i tankene dine, slik at du ikke mister tid verken energi. Jeg antar at spørsmålet ditt handler om ledelse av bedriftsteam.
  • Jeg tror Raid. Hylle, bugdrepsspray. Er dette et filosofisk spørsmål? Bøker er laget av den overvekt …

Svar

Tankesett og holdning til feilsøking er kanskje viktigste delen, fordi den avgjør hvor effektivt du vil løse feilen, og hva du vil lære av den – om noe.

Klassikere om programvareutvikling som The Pragmatic Programmer og Code Complete argumenterer i utgangspunktet for samme tilnærming: hver feil er en mulighet til å lære, nesten alltid om deg selv (fordi bare nybegynnere skylder kompilatoren / datamaskinen først).

Så behandle det som et mysterium som det vil være interessant å knekke. Og å knekke det mysteriet bør gjøres systematisk ved å uttrykke våre antagelser (til oss selv eller til andre) og deretter teste våre antagelser, en etter en om nødvendig – ved å bruke alle verktøyene vi har til rådighet, spesielt feilsøkere og automatiserte testrammer. Etter at mysteriet er løst, kan du gjøre det enda bedre ved å se gjennom all koden din for lignende feil du måtte ha gjort; og skriv en automatisert test for å sikre at feilen ikke skjer uvitende igjen.

En siste merknad – jeg foretrekker å kalle feil for «feil» og ikke «bugs» – Dijkstra hevdet kollegene sine for å bruke det siste ordet fordi det er uærlig og støtter ideen om at ondskapsfulle og ustabile bugfeer plantet feil i programmene våre mens vi ikke så, i stedet for å være der på grunn av vår egen (slurvete) tenkning: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Vi kan for eksempel begynne med å rydde opp i språket vårt ved å ikke lenger kalle en feil en feil, men ved å kalle den en feil. Det er mye mer ærlig fordi det helt og holdent legger skylden der den hører hjemme, nemlig. med programmereren som gjorde feilen. Den animistiske metaforen for feilen som ondskapsfullt snek seg inn mens programmereren ikke så, er intellektuelt uærlig da den forkledder at feilen er programmørens egen skapelse. Det fine med denne enkle endringen av ordforrådet er at den har en så dyp effekt. : mens et program med bare en feil tidligere var «nesten riktig», så er et program med en feil bare «feil» (fordi det er feil).

Kommentarer

  • Egentlig liker jeg begrepet " feil " i stedet for " bug ", ikke fordi det legger skylden på " programmereren som gjorde feilen ", men fordi det gjør det klart at det kanskje ikke har vært programmereren som skyldte. For meg, " bug " innebærer feil i koden; mens " erro r " innebærer feil et sted . Kanskje i koden, kanskje i miljøoppsettet, kanskje i kravene. Drives me nuts når sjefen min har en " bugliste " der halvparten av problemene er kravendringer. Kall det en oppgaveliste, ferchrissakes!
  • +1 for " hver feil er en mulighet til å lære, nesten alltid om deg selv (fordi bare nybegynnere skylder kompilatoren / datamaskin først) "
  • Du er kjent med historien til begrepet " bug ", ikke sant? Jeg mener, som brukt i programvareutvikling. Selvfølgelig har vi ikke ' dette problemet i dag, men en feil fløy faktisk inn i maskinvaren til en datamaskin ubemerket av programmereren og forårsaket et problem.For at ikke noen skal rette meg, vet jeg at Edison brukte dette begrepet lenge før møllhendelsen. Derfor brukte jeg ordet ' historie ', ikke ' opprinnelse '. Se computerworld.com/article/2515435/app-development/… og no.wikipedia.org/wiki/Software_bug#Etymology
  • @threed Selvfølgelig. Men i ganske lang tid har ikke insekter forårsaket det store flertallet av programvarefeil.

Svar

  1. Skriv tester. Testing er ikke bare bra for å forhindre feil (etter min erfaring eliminerer TDD gjort riktig nesten alle trivielle, dumme feil), men hjelper også mye med feilsøking. Testing tvinger designet ditt til å være ganske modulært, noe som gjør det enklere å isolere og replikere problemet. Dessuten kontrollerer du miljøet, så det blir mye mindre overraskelser. Når du først har fått en mislykket testsak, kan du være rimelig sikker på at du har spikret den virkelige årsaken til atferden som plager deg.

  2. Lær hvordan du bruker en feilsøkingsverktøy. print utsagn kan fungere rimelig bra på et eller annet nivå, men en feilsøking er for det meste veldig nyttig (og en gang du vet hvordan du bruker det, det er mye mer behagelig enn print utsagn).

  3. Snakk om noen om problemet ditt, selv om det bare er en gummiand . Å tvinge deg selv til å uttrykke problemet du jobber med med ord, gjør virkelig mirakler.

  4. Gi deg selv en tidsbegrensning. Hvis du for eksempel etter 45 minutter føler at du ikke kommer noen vei, er det bare å bytte til andre oppgaver i noen tid. Når du kommer tilbake til feilen din, vil du forhåpentligvis kunne se andre mulige løsninger som du ikke hadde tenkt på før.

Kommentarer

  • +1 for " Å tvinge deg selv til å uttrykke problemet du jobber med i ord, gjør virkelig mirakler. "
  • Og for å legge til (1), betyr nesten alle feil som du ser i koden at det ' en feil – eller i det minste en utelatelse – i testsuiten. Løs begge deler samtidig, og ikke bare beviser du at du ' har løst problemet, du ' er trygg mot at det blir introdusert på nytt.

Svar

Jeg liker de fleste andre svar, men her er noen tips om hva du skal gjøre FØR du gjør noe av det. Sparer deg for tiden.

  1. Finn ut om det virkelig er en feil. En feil er ALLTID en forskjell mellom systematferd og krav; testeren burde være i stand til å formulere forventet og faktisk oppførsel. Hvis han ikke er i stand til å gi støtte til forventet oppførsel, er det ikke noe krav og det er ingen feil – bare noens mening. Send den tilbake.

  2. Vurder muligheten at den forventede oppførselen er feil. Dette kan være på grunn av feiltolkning av kravet. Det kan også være på grunn av en mangel i selve kravet (et delta mellom et detaljert krav og et forretningskrav). Du kan også sende disse tilbake.

  3. Isoler problemet. Bare erfaring vil lære deg den raskeste måten å gjøre dette på – noen mennesker kan nesten gjøre det med tarmen. En grunnleggende tilnærming er å variere en ting mens å holde alle andre ting konstant (oppstår problemet i andre miljøer? med andre nettlesere? i en annen testregion? på forskjellige tidspunkter av dagen?) En annen tilnærming er å se på stack dump eller feilmeldinger – noen ganger kan du bare fortelle for øvrig er det formatert hvilken komponent i systemet som kastet den opprinnelige feilen (f.eks. hvis det er på tysk kan du bla meg den tredjeparten du jobber med i Berlin).

  4. Hvis du har begrenset det til to systemer som samarbeider, kan du inspisere meldingene mellom de to systemene via trafikkovervåker eller loggfiler. , og bestem hvilket system som oppfører seg for spesifikasjon og hvilket ikke. Hvis det er mer enn to systemer i scenariet, kan du utføre parvise kontroller og jobbe deg «ned» i applikasjonsstakken.

  5. Årsaken til at det å isolere problemet er så viktig er at problemet kanskje ikke skyldes en feil i koden du har kontroll over (f.eks. tredjepartssystemer eller miljøet), og at du vil få den parten til å ta over så raskt som mulig. Dette er både for å spare deg for arbeid og for å få dem på punkt med en gang, slik at oppløsningen kan oppnås på så kort tidsramme som mulig. Du vil ikke jobbe med et problem i ti dager bare for å finne det virkelig er et problem med andres webtjeneste.

  6. Hvis du har bestemt at det virkelig er en feil og det virkelig er i koden du kontrollerer, kan du ytterligere isolere problemet ved å lete etter den siste «kjent god» -byggingen og inspisere kildekontrolllogger for endringer som kan ha forårsaket problemet. Dette kan spare mye tid.

  7. Hvis du ikke kan finne ut av det fra kildekontrollen, er det nå på tide å feste feilsøkingsprogrammet og gå gjennom koden for å finne det Sjansene er nå at du uansett har en ganske god ide om problemet.

Når du vet hvor feilen er og kan tenke på en løsning, her er det bra prosedyre for å fikse det:

  1. Skriv en enhetstest som gjengir problemet og mislykkes.

  2. Uten å endre enhetstesten, gjør det passerer (ved å endre applikasjonskode).

  3. Hold enhetstesten i testsuiten din for å forhindre / oppdage regresjon.

Svar

Jeg tror reproduksjon av en feil også er viktig. Alle saker som reproduserer feilen kan vises, og deretter kan du sørge for at feilrettingen din dekker alle disse tilfellene.

Svar

Det er en utmerket bok jeg leste om dette emnet kalt Hvorfor programmer mislykkes , som skisserer ulike strategier for å finne feil som spenner fra å bruke den vitenskapelige metoden for å isolere og løse en bug, til delta feilsøking. Den andre interessante delen av denne boka er at den fjerner begrepet «bug». Zellers tilnærming er:

(1) En programmerer skaper en feil i koden. (2) Feilen forårsaker en infeksjon (3) Infeksjonen forplantes (4) Infeksjonen forårsaker en feil.

Hvis du ønsker å forbedre feilsøkingsevnen din, anbefaler jeg denne boken på det sterkeste.

I min egen personlige erfaring har jeg funnet mange feil i applikasjonen vår, men ledelsen presser oss bare videre for å få ut nye funksjoner. Jeg har ofte hørt «Vi fant denne feilen selv, og klienten har ikke lagt merke til den ennå, så bare la den være til de gjør det». Jeg synes det å være reaktiv i motsetning til proaktiv i å fikse feil er en veldig dårlig idé, da når tiden kommer til å faktisk sette i gang, har du fått andre problemer som må løses, og flere funksjoner, ledelse vil ut av døren ASAP, slik at du blir fanget i en ond syklus som kan føre til mye stress og utbrenthet, og til slutt, et defekt ridd system.

Kommunikasjon er også en annen faktor når feil blir funnet. Sende en e-post eller dokumentere den på bug tracker er alt bra og bra, men etter min egen erfaring finner andre utviklere en lignende bug og i stedet for å bruke løsningen du la for å fikse koden (ettersom de har glemt alt om det), legger de til sine egne versjoner, så du har 5 forskjellige løsninger i koden din, og den ser mer oppblåst og forvirrende ut som et resultat. Så når du fikser en feil, må du sørge for at noen få personer går igjennom løsningen og gir deg tilbakemelding i tilfelle de har løst noe lignende og fant en god strategi for å takle det.

limist nevnte boka,

The Pragmatic Programmer som har noe interessant materiale om å fikse feil. Ved å bruke eksemplet jeg ga i forrige avsnitt, ville jeg se på dette: Software Entrophy , der analogien til en ødelagt enke brukes. Hvis to mange går i stykker vinduer vises, kan teamet ditt være apatisk overfor å fikse det med mindre du tar en proaktiv holdning.

Kommentarer

  • I ' har hørt " Vi fant denne feilen selv, og klienten har ikke ' ikke lagt merke til den ennå, så bare la den være til de gjør " for mange ganger også. Og etter å ha besøkt nettstedet, har klienten ofte lagt merke til , men har ikke ' t rapporterte det. Noen ganger fordi de tror at ' ikke har noe poeng fordi det ikke ' t blir løst, noen ganger fordi de ser allerede på en konkurrent ' erstatning, og noen ganger (riktig eller galt) " vel, det er allikevel en dampende haug med skitt ".
  • @JuliaHayward – Dette er veldig ofte tilfelle, men i din situasjon, kundene dine kan være fornøyde med funksjonaliteten og ikke være for opptatt av hva ' som foregår under panseret. Problemet begynner å dukke opp når klienten kommer tilbake og ber om ekstra funksjoner, og du må legge til ytterligere forbedringer, for eksempel å gjøre appen din flerspråklig, mobilkompatibel bla bla, du begynner å se på hva du har og se alle sprekker i veggen.
  • Viser deg bare, alle bøkene i verden om programvaredesign, testing og god kommunikasjon og mange av produktene du jobber med er et vilt rot.Til tross for å vite hva ' er riktig, er stress og urealistiske tidsfrister (i ansiktet på den allerede rotete koden din) årsakene til at koden er i den tilstanden den er. Jeg har ikke ' ikke svar på det selv, jeg ' er ganske utpreget på kontoret som et stønnende ansikt ***** * mens jeg sparker og skriker for å holde koden sunn og utviklingsprosessen jevn, men noen ganger binder teamet seg ikke ' t godt sammen.

Svar

Feil, feil, problem, defekt – uansett hva du vil kalle det, gjør det ikke så stor forskjell. Jeg vil holde meg til problemet siden det «s hva jeg pleide å gjøre.

  1. Finn ut hva oppfatningen av problemet er: oversett fra en kunde» s «Bob er fortsatt ikke i systemet» til «Når jeg prøver å opprette en brukeroppføring for Bob, den mislykkes med unntak av duplikatnøkkel, selv om Bob ikke allerede er der «
  2. Finn ut om det virkelig er et problem eller bare en misforståelse (faktisk er Bob ikke» t der inne, det er ingen som heter bob, og innsatsen skal fungere).
  3. Prøv å få minimale pålitelige trinn du kan følge for å reprodusere problemet – noe sånt som «Gitt et system med en brukeroppføring» Bruce «, når en brukeroppføring» Bob «settes inn, oppstår et unntak»
  4. Dette er testen din – legg den om mulig i en automatisert test sele som du kan kjøre igjen og igjen, dette vil være uvurderlig når du feilsøker. Du kan også gjøre det til en del av testpakken din for å sikre at det aktuelle problemet ikke dukker opp igjen senere.
  5. Få feilsøkingsprogrammet ditt og begynn å sette brytepunkter – finn ut koden når du kjører testen, og identifiser hva som er galt. Mens du gjør det, kan du også avgrense testen ved å gjøre den så smal som mulig – ideelt sett en enhetstest.
  6. Løs det – bekreft testpresteringen.
  7. Bekreft det opprinnelige problemet som beskrevet av kunden er også løst (veldig viktig – du har kanskje bare løst en delmengde av problemet). Bekreft at du ikke introduserte regresjoner i andre aspekter av programmet.

Hvis du er veldig kjent med koden, eller hvis problemet eller løsningen er åpenbar, kan du hoppe over noen av disse trinn.

Hvordan skal vi nærme oss det for å utnytte vår verdifulle tid mest effektivt og gjøre det mulig for oss å bruke mindre tid på å finne den og mer tid på koding ?

Det tar jeg anledning til, da det innebærer at det å skrive ny kode er verdifullt enn å ha et arbeidsprogram av høy kvalitet. Det er ingenting galt med å være så effektiv som mulig for å løse problemer, men et program blir ikke nødvendigvis bedre ved å bare legge til mer kode i det.

Kommentarer

  • dette er det beste svaret IMO

Svar

Slik gjør jeg det:

  1. bruker den samme metoden hver gang for å finne problemet. Dette vil forbedre reaksjonstiden din for feilene.
  2. Den beste måten er sannsynligvis å lese koden. Dette er fordi all informasjon er tilgjengelig i koden. Du trenger bare effektive måter å finne riktig posisjon og evne til å forstå alle detaljene.
  3. feilsøking er veldig treg, og bare nødvendig hvis programmørene dine ikke forstår hvordan datamaskinen utfører asm-instruksjoner / ikke kan forstå samtalestabler og grunnleggende ting
  4. Prøv å utvikle bevisteknikker som å bruke funksjonsprototyper for å resonnere om oppførselen til programmet. Dette vil hjelpe deg med å finne riktig posisjon raskere

Svar

Når vi oppdager en feil i koden vår, hva kan vi gjøre for å luke den ut? Hvordan skal vi nærme oss den for å utnytte vår verdifulle tid mest mulig og gjøre det mulig for oss å bruke mindre tid på å finne den og mer tid på koding? Hva bør vi også unngå når vi feilsøker?

Forutsatt at du befinner deg i et produksjonsmiljø, er det dette du trenger å gjøre:

  1. Beskriv «feilen» riktig, og identifiser hendelsene som får den til å skje.

  2. Finn ut om «feilen» er en kodefeil eller spesifikasjonsfeil. For eksempel kan inntasting av navnet på 1 bokstav betraktes som en feil i noen systemer, men akseptabel oppførsel for andre systemer. Noen ganger rapporterte en bruker en feil som han / hun mener er et problem, men brukerens forventning om systemets oppførsel var ikke en del av kravene.

  3. Hvis du har bevist at det i en feil og feilen skyldes koden, kan du bestemme hvilke kodestykker som må fikses for å forhindre feilen. Undersøk også effekten av atferden på nåværende data og fremtidige systemoperasjoner (konsekvensanalyse på kode og data).

  4. På dette tidspunktet vil du sannsynligvis ha et estimat på hvor mye ressurser som skal brukes til å fikse feilen. Du kan enten fikse den med en gang eller planlegge en løsning i en kommende utgivelse av programvaren.Dette avhenger også av om sluttbrukeren er villig til å betale for reparasjonen. Du bør også evaluere forskjellige tilgjengelige alternativer for å fikse feilen. Det kan være mer enn én vei. Du må velge tilnærmingen som passer best for situasjonen.

  5. Analyser årsakene til at denne feilen dukket opp (krav, koding, testing osv.). Håndheve prosesser som vil forhindre at tilstanden oppstår igjen.

  6. Dokumenter episoden tilstrekkelig.

  7. Slipp løsningen (eller ny versjon)

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *