Hur felsöker man koden mest effektivt? [stängd]

Tänkesättet och inställningen till felsökning är kanske viktigaste delen, eftersom den avgör hur effektivt du kommer att åtgärda felet och vad du kommer att lära dig av det – om något.

Klassiker om mjukvaruutveckling som The Pragmatic Programmer och Code Complete argumenterar i princip för samma tillvägagångssätt: varje fel är ett tillfälle att lära sig, nästan alltid om dig själv (eftersom bara nybörjare skyller kompilatorn / datorn först).

Så behandla det som ett mysterium som blir intressant att knäcka. Och att knäcka detta mysterium bör göras systematiskt genom att uttrycka våra antaganden (för oss själva eller för andra) och sedan testa våra antaganden, en efter en om det behövs – med hjälp av alla verktyg vi har till vårt förfogande, särskilt debuggare och automatiska testramar. Sedan efter att mysteriet är löst kan du göra ännu bättre genom att leta igenom all din kod för liknande fel som du kan ha gjort; och skriv ett automatiskt test för att säkerställa att felet inte kommer att ske omedvetet igen.

En sista anmärkning – jag föredrar att kalla fel för ”fel” och inte ”buggar” – Dijkstra chippade sina kollegor för att använda den senare termen eftersom det är oärligt och stöder idén att skadliga och ojämna bugfeer planterade buggar i våra program medan vi inte tittade istället för att vara där på grund av vårt eget (slarviga) tänkande: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Vi kan till exempel börja med att städa upp vårt språk genom att inte längre kalla ett fel för ett fel utan genom att kalla det ett fel. Det är mycket mer ärligt eftersom det helt och hållet lägger skulden där det hör hemma, nämligen. med programmeraren som gjorde felet. Den animistiska metaforen för buggen som skadligt smög in medan programmeraren inte letade är intellektuellt oärlig eftersom den förklarar att felet är programmerarens egen skapelse. Det fina med denna enkla ordförändring är att den har en så djupgående effekt. : medan ett program med bara en bugg tidigare var ”nästan korrekt”, är ett program med ett fel bara ”fel” (för fel).

Kommentarer

• Egentligen gillar jag termen " fel " snarare än " bug ", inte för att det lägger skulden på " programmeraren som gjorde felet ", men eftersom det gör det tydligt att det kanske inte har varit programmeraren fel. För mig " bug " innebär fel i koden; medan " erro r " innebär fel någonstans . Kanske i koden, kanske i miljöinställningarna, kanske i kraven. Gör mig nöjd när min chef har en " bugglista " där hälften av frågorna är kravändringar. Kalla det en uppgiftslista, ferchrissakes!
• +1 för " varje fel är ett tillfälle att lära sig, nästan alltid om dig själv (för bara nybörjare skyller kompilatorn / dator först) "
• Du är medveten om historien om termen " bug ", eller hur? Jag menar, som används vid mjukvaruutveckling. Självklart har vi inte ' det här problemet idag, men ett fel flydde faktiskt in i maskinvaran på en dator utan att det märktes av programmeraren och orsakade ett problem.För att inte någon ska korrigera mig vet jag att Edison använde den här termen långt före malhändelsen, varför jag använde ordet ' history ', inte ' ursprung '. Se computerworld.com/article/2515435/app-development/… och sv.wikipedia.org/wiki/Software_bug#Etymology
• @threed Naturligtvis. Men under en längre tid har insekter inte orsakat de allra flesta programvarufel.

1. Skriv tester. Testning är inte bara bra för att förhindra buggar (enligt min erfarenhet eliminerar TDD rätt rätt nästan alla triviala, dumma buggar), men hjälper också mycket till felsökning. Testning tvingar din design att vara ganska modulär, vilket gör det mycket enklare att isolera och replikera problemet. Du kontrollerar också miljön, så det kommer att bli mycket mindre överraskningar. Dessutom, när du väl har fått ett misslyckat testfall kan du vara ganska säker på att du har spikat den verkliga anledningen till det beteende som stör dig.

2. Lär dig hur du använder en felsökare. print uttalanden kan fungera ganska bra på någon nivå, men en felsökare är för det mesta mycket till hjälp (och en gång du vet hur du använder det, det är mycket bekvämare än print uttalanden).

3. Prata om någon om ditt problem, även om det bara är en gummiduckie . Att tvinga dig själv att uttrycka det problem du arbetar med i ord gör verkligen mirakel.

4. Ge dig själv en tidsgräns. Om du till exempel känner att du inte går någonstans efter 45 minuter, byt bara till andra uppgifter under en tid. När du kommer tillbaka till din bugg kommer du förhoppningsvis att kunna se andra möjliga lösningar som du inte hade tänkt på tidigare.

Kommentarer

• +1 för " Att tvinga dig själv att uttrycka det problem du arbetar med i ord gör verkligen mirakel. "
• Och för att lägga till (1) innebär nästan varje fel som du ser i koden att det finns ' ett fel – eller åtminstone en utelämning – i testsviten. Åtgärda båda samtidigt och inte bara bevisar du att ' har åtgärdat problemet till hands, du ' är säker på att det inte är återinfördes.

Jag gillar de flesta andra svar, men här är några tips om vad du ska göra INNAN du gör något av det. Sparar tid för beaucoup.

1. Bestäm om det verkligen finns ett fel. Ett fel är ALLTID en skillnad mellan systembeteende och krav; testaren borde kunna formulera förväntat och faktiskt beteende. Om han inte kan ge stöd för det förväntade beteendet, finns det inget krav och det finns inget fel – bara någons åsikt. Skicka tillbaka det.

2. Överväg möjligheten att det förväntade beteendet är fel. Detta kan bero på en felaktig tolkning av kravet. Det kan också bero på en defekt i själva kravet (ett delta mellan ett detaljerat krav och ett affärskrav). Du kan också skicka tillbaka dessa.

3. Isolera problemet. Endast erfarenheten lär dig det snabbaste sättet att göra detta – vissa människor kan nästan göra det med tarmen. En grundläggande metod är att variera en sak medan hålla alla andra saker konstanta (uppstår problemet i andra miljöer? med andra webbläsare? i en annan testregion? vid olika tider på dygnet?) Ett annat tillvägagångssätt är att titta på stackdumpar eller felmeddelanden – ibland kan du bara berätta förresten är det formaterat vilken komponent i systemet som kastade originalfelet (t.ex. om det är på tyska kan du bla mig den tredje parten du arbetar med i Berlin).

4. Om du har begränsat det till två system som samarbetar, inspektera meddelandena mellan de två systemen via trafikövervakare eller loggfiler , och bestäm vilket system som beter sig och vilket inte. Om det finns mer än två system i scenariot kan du utföra parvisa kontroller och arbeta dig ”ner” i applikationsstacken.

5. Anledningen till att det är så viktigt att isolera problemet är att problemet kanske inte beror på en kodfel som du har kontroll över (t.ex. tredjepartssystem eller miljön) och att du vill få den parten att ta över så snabbt som möjligt. Detta är både för att spara arbete och för att få dem på plats omedelbart så att upplösningen kan uppnås på så kort tid som möjligt. Du vill inte arbeta med ett problem i tio dagar bara för att hitta det verkligen är ett problem med någon annans webbtjänst.

6. Om du har bestämt att det verkligen finns en defekt och det verkligen finns i koden du kontrollerar kan du ytterligare isolera problemet genom att leta efter den senaste ”kända goda” byggnaden och inspektera källkontrollloggar för ändringar som kan ha orsakat problemet. Detta kan spara mycket tid.

7. Om du inte kan räkna ut det från källkontrollen är det dags att bifoga din felsökare och gå igenom koden för att räkna ut den Chansen är nu att du ändå har en ganska bra uppfattning om problemet.

När du väl vet var felet är och kan tänka på en lösning, här är det bra procedur för att åtgärda det:

1. Skriv ett enhetstest som återger problemet och misslyckas.

2. Utan att ändra enhetstestet, gör det passerar (genom att ändra applikationskod).

3. Håll enhetstestet i din testsvit för att förhindra / upptäcka regression.

Jag tror att reproduktionen av ett fel också är viktigt. Alla fall som reproducerar felet kan listas och sedan kan du se till att din buggfix täcker alla dessa fall.

Det finns en utmärkt bok jag läste om detta ämne som heter Varför program misslyckas , som beskriver olika strategier för att hitta buggar, allt från att använda den vetenskapliga metoden för att isolera och lösa en bug, till delta felsökning. Den andra intressanta delen av denna bok är att den tar bort begreppet ”bug”. Zellers strategi är:

(1) En programmerare skapar en defekt i koden. (2) Defekten orsakar en infektion (3) Infektionen sprids (4) Infektionen orsakar ett fel.

Om du vill förbättra dina felsökningsfärdigheter rekommenderar jag den här boken.

Enligt min egen personliga erfarenhet har jag hittat många buggar i vår applikation, men ledningen trycker helt enkelt på oss för att få ut nya funktioner. Jag har ofta hört ”Vi hittade detta fel själva och klienten har inte märkt det ännu, så lämna det bara tills de gör det”. Jag tycker att det är en mycket dålig idé att vara reaktiv i motsats till proaktiv för att fixa buggar, eftersom när det är dags att faktiskt fixa, har du andra problem som behöver lösas och fler funktioner förvaltning vill ut genom dörren ASAP, så du blir fast i en ond cirkel som kan leda till mycket stress och utbrändhet och i slutändan ett defektkört system.

Kommunikation är också en annan faktor när buggar hittas. Skicka ett e-postmeddelande eller dokumentera det på bug tracker är allt bra och bra, men enligt min egen erfarenhet hittar andra utvecklare en liknande bugg och snarare än att återanvända den lösning du satte för att fixa koden (eftersom de har glömt allt om det) lägger de till sina egna versioner, så du har fem olika lösningar i din kod och det ser mer uppsvälld och förvirrande ut som ett resultat. Så när du fixar ett fel, se till att några personer granskar fixen och ger dig feedback om de har fixat något liknande och hittade en bra strategi för att hantera det.

limist nämnde boken,