Wie kann man Code am effektivsten debuggen? [geschlossen]

Die Denkweise und Einstellung zum Debuggen ist vielleicht die Der wichtigste Teil, weil er bestimmt, wie effektiv Sie den Fehler beheben und was Sie daraus lernen werden – wenn überhaupt.

Klassiker der Softwareentwicklung wie The Pragmatic Programmer und Code Complete sprechen grundsätzlich für denselben Ansatz: Jeder Fehler ist eine Gelegenheit, fast immer etwas über sich selbst zu lernen (weil nur Anfänger zuerst den Compiler / Computer beschuldigen).

Behandle es also als ein Rätsel, das interessant zu knacken sein wird. Und dieses Rätsel zu lösen, sollte systematisch gelöst werden, indem wir unsere Annahmen (uns selbst oder anderen gegenüber) zum Ausdruck bringen und dann unsere Annahmen gegebenenfalls einzeln testen – unter Verwendung aller uns zur Verfügung stehenden Tools, insbesondere von Debuggern und automatisierten Test-Frameworks. Nachdem das Rätsel gelöst ist, können Sie es noch besser machen, indem Sie Ihren gesamten Code nach ähnlichen Fehlern durchsuchen, die Sie möglicherweise gemacht haben. und schreiben Sie einen automatisierten Test, um sicherzustellen, dass der Fehler nicht unwissentlich erneut auftritt.

Ein letzter Hinweis – Ich nenne Fehler lieber „Fehler“ und nicht „Fehler“ – Dijkstra warf seinen Kollegen vor, den letzteren Begriff zu verwenden, weil Es ist unehrlich und unterstützt die Idee, dass verderbliche und launische Insektenfeen Fehler in unsere Programme gepflanzt haben, während wir nicht hinschauten, anstatt aufgrund unseres eigenen (schlampigen) Denkens dort zu sein: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Wir könnten zum Beispiel damit beginnen, unsere Sprache zu bereinigen Nennen Sie einen Fehler nicht länger einen Fehler, sondern indem Sie ihn als Fehler bezeichnen. Es ist viel ehrlicher, weil es die Schuld genau dahin bringt, wo sie hingehört, nämlich. mit dem Programmierer, der den Fehler gemacht hat. Die animistische Metapher des Fehlers, der sich böswillig eingeschlichen hat, während der Programmierer nicht hinschaute, ist intellektuell unehrlich, da er verschleiert, dass der Fehler die eigene Schöpfung des Programmierers ist. Das Schöne an dieser einfachen Änderung des Wortschatzes ist, dass er eine so tiefgreifende Wirkung hat : Während früher ein Programm mit nur einem Fehler „fast korrekt“ war, ist ein Programm mit einem Fehler danach nur „falsch“ (weil irrtümlich).

Kommentare

• Eigentlich mag ich den Begriff " Fehler " anstatt " Fehler ", nicht weil es " dem Programmierer die Schuld gibt Wer hat den Fehler gemacht ", aber weil es klar macht, dass möglicherweise nicht der Programmierer schuld war. Für mich " Fehler " impliziert einen Fehler im Code, während " erro r " impliziert Fehler irgendwo . Vielleicht im Code, vielleicht im Umgebungssetup, vielleicht in den Anforderungen. Macht mich verrückt, wenn mein Chef eine " Fehlerliste " hat, bei der die Hälfte der Probleme Änderungen der Anforderungen sind. Nennen Sie es eine Aufgabenliste, ferchrissakes!
• +1 für " Jeder Fehler ist eine Gelegenheit, fast immer etwas über sich selbst zu lernen (weil nur Anfänger dem Compiler die Schuld geben /). Computer zuerst) "
• Sie kennen die Geschichte des Begriffs " Fehler ", richtig? Ich meine, wie in der Softwareentwicklung verwendet. Natürlich haben wir ' dieses Problem heute nicht, aber ein Fehler ist tatsächlich unbemerkt in die Hardware eines Computers geflogen und hat ein Problem verursacht.Damit mich niemand korrigieren kann, weiß ich, dass Edison diesen Begriff lange vor dem Mottenvorfall verwendet hat, weshalb ich das Wort ' history ', nicht ' Ursprung '. Siehe computerworld.com/article/2515435/app-development/… und de.wikipedia.org/wiki/Software_bug#Etymology
• @threed Natürlich. Aber seit geraumer Zeit haben Insekten nicht mehr die meisten Softwarefehler verursacht.

1. Tests schreiben. Testen ist nicht nur großartig, um Fehler zu verhindern (meiner Erfahrung nach beseitigt TDD, wenn es richtig gemacht wird, fast alle trivialen, dummen Fehler), sondern hilft auch beim Debuggen. Das Testen zwingt Ihr Design dazu, ziemlich modular zu sein, was das Isolieren und Replizieren des Problems viel einfacher macht. Außerdem kontrollieren Sie die Umgebung, sodass es weniger Überraschungen gibt. Wenn Sie einen fehlgeschlagenen Testfall erhalten, können Sie außerdem ziemlich sicher sein, dass Sie den echten Grund für das Verhalten, das Sie stört, ermittelt haben.

2. Erfahren Sie, wie Sie einen Debugger verwenden. print -Anweisungen funktionieren auf einer bestimmten Ebene recht gut, aber ein Debugger ist meistens sehr hilfreich (und einmal) Sie wissen, wie man es benutzt, es ist viel komfortabler als print Anweisungen).

3. Sprechen Sie über jemanden über Ihr Problem. selbst wenn es nur ein Gummiente ist. Sich zu zwingen, das Problem, an dem Sie arbeiten, in Worten auszudrücken, ist wirklich ein Wunder.

4. Geben Sie sich ein Zeitlimit. Wenn Sie beispielsweise nach 45 Minuten das Gefühl haben, dass Sie nirgendwo hingehen, wechseln Sie einfach für einige Zeit zu anderen Aufgaben. Wenn Sie zu Ihrem Fehler zurückkehren, werden Sie hoffentlich andere mögliche Lösungen sehen können, die Sie vorher nicht in Betracht gezogen hätten.

Kommentare

• +1 für " Wenn Sie sich zwingen, das Problem, an dem Sie arbeiten, in Worten auszudrücken, ist das wirklich ein Wunder. "
• Und um (1) hinzuzufügen, impliziert fast jeder Fehler, den Sie im Code sehen, dass ' ein Fehler vorliegt – oder zumindest eine Auslassung – In der Testsuite. Beheben Sie beide gleichzeitig und beweisen Sie nicht nur, dass Sie ' das vorliegende Problem behoben haben, sondern dass Sie ' sicher davor sind wieder eingeführt.

Ich mag die meisten anderen Antworten, aber hier sind einige Tipps, was zu tun ist Bevor Sie etwas davon tun. Sparen Sie Zeit.

1. Stellen Sie fest, ob wirklich ein Fehler vorliegt. Ein Fehler ist IMMER ein Unterschied zwischen Systemverhalten und Anforderungen. Der Tester sollte in der Lage sein, das erwartete und tatsächliche Verhalten zu artikulieren. Wenn er das erwartete Verhalten nicht unterstützen kann, gibt es keine Anforderung und keinen Fehler – nur die Meinung von jemandem. Senden Sie es zurück.

2. Berücksichtigen Sie die Möglichkeit Dies kann auf eine Fehlinterpretation der Anforderung zurückzuführen sein. Dies kann auch auf einen Fehler in der Anforderung selbst zurückzuführen sein (ein Delta zwischen einer detaillierten Anforderung und einer Geschäftsanforderung). Sie können diese auch zurücksenden.

3. Isolieren Sie das Problem. Nur die Erfahrung wird Ihnen den schnellsten Weg zeigen, dies zu tun. Einige Leute können es fast mit ihrem Bauch tun. Ein grundlegender Ansatz besteht darin, eine Sache währenddessen zu variieren Alle anderen Dinge konstant halten (tritt das Problem in anderen Umgebungen auf – mit anderen Browsern – in einer anderen Testregion – zu verschiedenen Tageszeiten?) Ein anderer Ansatz besteht darin, Stapelspeicherauszüge oder Fehlermeldungen zu betrachten – manchmal kann man das einfach sagen Übrigens wird formatiert, welche Komponente des Systems den ursprünglichen Fehler ausgelöst hat (zB wenn es auf Deutsch ist, können Sie bla Ich bin der Dritte, mit dem Sie in Berlin zusammenarbeiten.

4. Wenn Sie es auf zwei Systeme eingegrenzt haben, die zusammenarbeiten, überprüfen Sie die Nachrichten zwischen den beiden Systemen über Verkehrsüberwachung oder Protokolldateien und bestimmen, welches System sich gemäß Spezifikation verhält und welches nicht. Wenn das Szenario mehr als zwei Systeme enthält, können Sie paarweise Überprüfungen durchführen und sich im Anwendungsstapel „nach unten“ arbeiten.

5. Der Grund, warum das Problem eingegrenzt wird, ist so kritisch ist, dass das Problem möglicherweise nicht auf einen Codefehler zurückzuführen ist, über den Sie die Kontrolle haben (z. B. Systeme von Drittanbietern oder die Umgebung), und Sie möchten, dass diese Partei so schnell wie möglich die Kontrolle übernimmt. Dies dient sowohl dazu, Ihnen Arbeit zu ersparen als auch sie sofort auf den Punkt zu bringen, damit die Auflösung in einem möglichst kurzen Zeitrahmen erreicht werden kann. Sie möchten zehn Tage lang nicht an einem Problem arbeiten, nur um festzustellen, dass es sich wirklich um ein Problem mit dem Webdienst eines anderen handelt.

6. Wenn Sie festgestellt haben, dass tatsächlich ein Fehler vorliegt und der Code, den Sie steuern, tatsächlich vorhanden ist, können Sie das Problem weiter eingrenzen, indem Sie nach dem letzten „bekannt guten“ Build suchen und Überprüfen der Quellcodeverwaltungsprotokolle auf Änderungen, die das Problem verursacht haben könnten. Dies kann viel Zeit sparen.

7. Wenn Sie es nicht aus der Quellcodeverwaltung herausfinden können, ist es jetzt an der Zeit, Ihren Debugger anzuhängen und den Code zu durchlaufen, um ihn herauszufinden Die Chancen stehen gut, dass Sie inzwischen sowieso eine ziemlich gute Vorstellung von dem Problem haben.

Wenn Sie wissen, wo der Fehler liegt und sich eine Lösung vorstellen können, ist dies „gut“ Verfahren zur Behebung des Problems:

1. Schreiben Sie einen Komponententest, der das Problem reproduziert und fehlschlägt.

2. Machen Sie make, ohne den Komponententest zu ändern Es wird bestanden (durch Ändern des Anwendungscodes).

3. Behalten Sie den Komponententest in Ihrer Testsuite, um eine Regression zu verhindern / zu erkennen.

Ich denke, die Reproduktion eines Fehlers ist ebenfalls wichtig. Alle Fälle, die den Fehler reproduzieren, können aufgelistet werden. Anschließend können Sie sicherstellen, dass Ihre Fehlerbehebung alle diese Fälle abdeckt.

Zu diesem Thema habe ich ein ausgezeichnetes Buch mit dem Titel Warum Programme fehlschlagen gelesen, in dem verschiedene Strategien zum Auffinden von Fehlern beschrieben werden, die von der Anwendung der wissenschaftlichen Methode bis zur Isolierung und Behebung von a reichen Fehler, Delta-Debugging. Der andere interessante Teil dieses Buches ist, dass es den Begriff „Bug“ beseitigt. Zellers Ansatz ist:

(1) Ein Programmierer erstellt einen Fehler im Code. (2) Der Fehler verursacht eine Infektion. (3) Die Infektion breitet sich aus. (4) Die Infektion verursacht einen Fehler.

Wenn Sie Ihre Debugging-Fähigkeiten verbessern möchten, empfehle ich dieses Buch.

Nach meiner persönlichen Erfahrung habe ich in unserer Anwendung viele Fehler gefunden, aber das Management drängt uns einfach weiter um neue Funktionen herauszubekommen. Ich habe oft gehört, dass wir diesen Fehler selbst gefunden haben und der Client ihn noch nicht bemerkt hat. Lassen Sie ihn also einfach, bis er es tut. Ich denke, dass es eine sehr schlechte Idee ist, reaktiv und nicht proaktiv Fehler zu beheben, da es an der Zeit ist, tatsächlich Probleme zu beheben. Sie haben andere Probleme, die behoben werden müssen, und mehr Funktionen möchten das Management so schnell wie möglich aus der Tür, sodass Sie erwischt werden in einem Teufelskreis, der zu viel Stress und Burn-out und letztendlich zu einem fehlerhaften System führen kann.

Kommunikation ist auch ein weiterer Faktor, wenn Fehler gefunden werden. Senden einer E-Mail oder Dokumentieren auf dem Bug Tracker ist alles in Ordnung und gut, aber nach meiner eigenen Erfahrung finden andere Entwickler einen ähnlichen Fehler und anstatt die Lösung, die Sie zur Behebung des Codes verwendet haben (da sie alles vergessen haben), wiederzuverwenden, fügen sie ihre eigenen Versionen hinzu Sie haben 5 verschiedene Lösungen in Ihrem Code und es sieht dadurch aufgeblähter und verwirrender aus. Wenn Sie also einen Fehler beheben, stellen Sie sicher, dass einige Leute den Fix überprüfen und Ihnen Feedback geben, falls sie etwas Ähnliches behoben haben und fand eine gute Strategie, um damit umzugehen.

Limist erwähnte das Buch,