30 Stimmen

Gibt es Muster für die Fehlersuche?

Ich weiß, dass es viele beliebte und nützliche Design Patters gibt.

Gibt es so etwas auch für Debugging-Szenarien? Vielleicht keine Muster, aber Methoden, die kategorisiert sind und die wiederholt für ähnliche Fälle verwendet werden können.

4 Stimmen

Um Ihre Frage zu beantworten: Ja. Es gibt verschiedene Debugging-Strategien, die je nach Art des Problems angewendet werden. Wenn Sie einen Katalog dieser Strategien haben möchten, sollten Sie dies zu einem Community-Wiki machen.

0 Stimmen

Es wird ein Gemeinschafts-Wiki werden, wenn es nötig ist :)

6 Stimmen

Bei fast jeder Frage, die ich in den letzten Wochen eröffnet habe, hat jemand darum gebeten, dass der Beitrag in ein Gemeinschafts-Wiki aufgenommen wird. Ich denke, die Leute sollten sich um ihre eigenen Angelegenheiten kümmern und die Person, die die Frage gestellt hat, respektieren.

11voto

Broam Punkte 4548

Ich möchte noch ein weiteres Debugging-Muster hinzufügen, das ziemlich offensichtlich erscheint, aber noch nicht erwähnt wurde:

Reduzieren Sie den Fehler auf den kleinstmöglichen Fall, und verwenden Sie diesen dann als Einheitstest für jede vorgeschlagene Korrektur.

0 Stimmen

Absolut! Das einzige Problem, auf das ich immer stoße, ist, dass in den Systemen, mit denen ich arbeite, eine Menge Fehlersuche betrieben werden muss, bevor ich den "kleinsten Fall" erreichen kann. Es gibt auch einige Situationen, in denen man die auslösende(n) Bedingung(en) einfach nicht erzwingen kann, egal wie sehr man sich bemüht. Dies ist vor allem bei Systemen der Fall, die auf externe Stimuli reagieren, z. B. bei Netzwerkanwendungen oder Echtzeitsteuerungen.

8voto

Chris Cleeland Punkte 4457

Hier sind ein paar, die für mich funktionieren:

  • Entfernen Sie sich von dem Problem. Ähnlich wie bei "mehr schlafen" hilft es manchmal, sich von dem Problem zu lösen und sich auf etwas völlig anderes zu konzentrieren (z. B. Sport zu treiben), um Klarheit zu gewinnen, wenn Sie die Arbeit an dem Problem wieder aufnehmen.
  • Erklären Sie meiner Frau das Problem. Nun, es muss nicht unbedingt meine Frau sein, aber jemand, der mit dem Problem, dem System oder anderem nicht vertraut ist. Das wird Sie dazu zwingen, Ihre Annahmen an die Oberfläche zu bringen, zu erklären, wie das System wirklich funktioniert, und vielleicht sogar zum Code zurückzugehen, um zu überprüfen, was Sie sagen. Nach einem solchen Austausch habe ich oft bedeutende Durchbrüche erzielt.

0 Stimmen

Der Ansatz "erkläre meiner Frau das Problem" war für mich oft sehr hilfreich. Jemand, der mit der Komponente oder dem System nicht vertraut ist, und oft auch jemand, der nicht einmal mit dem Programmieren vertraut ist, ist ein großartiges Publikum, das mich dazu zwingt, Dinge zu sagen, die ich sonst nicht gesagt hätte, und daher auf Dinge zu achten, die ich vielleicht übersehen hätte.

0 Stimmen

Mein Teamleiter hat in der Vergangenheit schon oft von diesem Ansatz profitiert. Wenn etwas nicht in Ordnung ist, ruft er mich in der Regel zu sich, beginnt zu erklären, was er mit dem Code gemacht hat, und mitten in seiner Erklärung hört er plötzlich auf und sagt: "Er ist ein Idiot" oder etwas Ähnliches und behebt das Problem. Ich brauche nicht einmal zu reden. Was den Vorschlag betrifft, meiner Frau das Problem zu erklären, frage ich mich, ob es auch umgekehrt funktioniert. Wenn ich ein Problem mit meiner Frau habe, sollte ich beim nächsten Mal das Muster "erkläre es deinem Kollegen" ausprobieren :)

0 Stimmen

Mehr Schlaf zu bekommen, ist ebenfalls eine gute Sache. Eigentlich ist es etwas, das sogar die Sportler tun. Den hart trainierenden Athleten wird empfohlen, sich mindestens 3-4 Wochen im Jahr eine Auszeit zu gönnen, in der sie weder lesen noch über ihren Sport nachdenken oder ihn ansehen. Das nennt man Renaissance-Effekt. Man gibt ein Problem - oder eine Bewegung oder Technik - für einige Zeit auf. Und wenn man es dann wieder versucht, stellt man fest, dass man es viel leichter kann.

7voto

Moshe Levi Punkte 3363

Ich stimme den anderen zu, dass Unit Testing ein "Muster" zur Fehlervermeidung ist. Zusätzlich möchte ich die folgenden Schritte aus Fehlersuche: Die 9 unverzichtbaren Regeln zum Auffinden selbst der schwer fassbaren Software- und Hardwareprobleme :

  • Verstehen Sie das System
  • Lass es scheitern
  • Hören Sie auf zu denken und schauen Sie
  • Teilen und Erobern
  • Eine Sache nach der anderen ändern
  • Führen Sie einen Prüfpfad
  • Prüfen Sie den Stecker
  • Ein neuer Blick
  • Wenn du es nicht repariert hast, ist es nicht repariert

Und schließlich hat Dimitry Vostokov auf der praktischen Seite einige sehr schöne Debugging-Muster in seinem Buch et Website .

1 Stimmen

Wenn Sie es nicht repariert haben, ist es nicht repariert, das sollte eine Antwort für sich sein! Wenn es auf wundersame Weise besser geworden ist oder Sie irgendeine Voodoo- oder Cargo-Kult-Änderung am Code ausprobiert haben, ohne eine Hypothese darüber aufzustellen, was falsch war, oder einen Test durchzuführen, um Ihre Hypothese zu beweisen, werden Sie das Problem immer wieder neu beheben müssen, vielleicht sogar jahrelang.

5voto

Bob Punkte 93584

Wenn ich bei der Fehlersuche nur im Dunkeln tappe, wähle ich den Ansatz der binären Suche. Ich kommentiere die Hälfte meines Codes oder die Hälfte einer Methode aus, und dann konzentriere ich mich auf die unkommentierte Hälfte. Wenn das Problem immer noch besteht, kommentiere ich eine weitere Hälfte aus. Und so weiter.

0 Stimmen

Das klingt sehr kontextspezifisch und hilft Ihnen überhaupt nicht, wenn eine Änderung des Quelltextes nicht möglich ist (was oft der Fall ist).

4 Stimmen

Ich weiß nicht, wann ich "debuggen" würde, wenn eine Änderung des Quellcodes nicht möglich ist. Wenn ich den Quellcode nicht habe, kann ich ihn nicht debuggen, obwohl ich einen schönen Fehlerbericht erstellen kann.

1 Stimmen

Häufig treten Bugs in einem Kontext auf, in dem eine Änderung des Quellcodes nicht möglich ist, denn Bugs treten am häufigsten in realen Systemen und nicht in konstruierten Testszenarien auf. Man könnte geneigt sein zu antworten: "Nun, das bedeutet, dass Sie nicht genügend Unit-Tests haben", aber Unit-Tests können nicht alles erfassen, insbesondere nicht in komplexen, miteinander verbundenen Systemen. Eingesetzte Systeme lassen in der Regel keine Änderungen am Quellcode zu, vor allem, wenn sie immer größer werden. Außerdem kann die Modifizierung des Quellcodes die Art dessen, was Sie debuggen, verändern - printfs führen zu anderen Locking Patterns, mehr Code = andere Layouts, usw.

5voto

GSto Punkte 40158

Mein Ansatz ist die Anwendung der wissenschaftlichen Methode:

  1. Sammeln Sie Daten darüber, was passiert, probieren Sie viele verschiedene Eingaben aus und sehen Sie, welche Ergebnisse ich erhalte.
  2. Entwickeln Sie eine Hypothese darüber, was vor sich geht
  3. Testen Sie die Hypothese, und wenn ich nicht richtig liege, dann gehen Sie zurück zu Schritt 1 und wiederholen Sie ihn.

0 Stimmen

+1 für die Hypothesenmethode. In wirklich kniffligen Debugging-Situationen habe ich diesen Ansatz verwendet. Manchmal stelle ich mehrere verschiedene Hypothesen auf und entwickle dann einen Test, um jede davon zu überprüfen, indem ich das Ausschlussverfahren verwende, um herauszufinden, welche die beste Erklärung für das, was passiert, liefert.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X