Wie verbringe ich weniger Zeit mit dem Debuggen? [geschlossen]

Nach der Pareto-Regel verbringt ein Programmierer nur 20% seiner Zeit mit wirklich nützlichen Dingen.

Ich verbringe 80% meiner Zeit mit dem Debuggen und dem Reparieren kleiner Dinge, um alles zum Laufen zu bringen.

Gibt es eine Möglichkeit, weniger Zeit mit dem Debuggen zu verbringen?

Code in Agda oder Coq . Sobald Ihr Code kompiliert ist, funktioniert er. Wenn es zu hardcore ist, wählen Sie eine Sprache mit einem schwächeren Typsystem, z. B. Haskell oder F #.

In den meisten Fällen sind Sie jedoch produktiver, wenn Sie 20% Ihrer Zeit für das Codieren und 80% für das Testen und Debuggen aufwenden. 100% einer Woche sind viel mehr als 20% einer Stunde. Wenn das Debuggen das ist, was Sie brauchen, um Dinge zu erledigen, dann ist das Debuggen keine Zeitverschwendung und Sie sollten sich nicht die Mühe machen, diesen Anteil zu "verbessern".

Unit-Test.

Nachdem ich angefangen hatte, Komponententests durchzuführen, stellte ich fest, dass der von mir geschriebene Code besser strukturiert war. Es war dann einfacher, Fehler zu vermeiden und zu erkennen. Ich habe weniger Zeit für das Debuggen aufgewendet, aber mehr Zeit für das Schreiben von Unit-Tests.

Ich denke auch, dass die in Unit-Tests investierte Zeit eine bessere Rendite als das Debuggen hat. Nach einer Debugsitzung habe ich den Code gerade korrigiert. Der gleiche Fehler kann Wochen später auftreten und ich muss erneut debuggen. Wenn ich einen Komponententest schreibe, wird der Fehler als Komponententest dokumentiert und fungiert später als Regressionstest. Wenn der Fehler erneut auftritt, zeigen mir die Unit-Tests dies.

• Unit-Test, damit Sie wissen, ob Ihr Code überhaupt funktioniert.
• Zumindest ein gewisses Maß an Upfront-Design, damit Sie wissen, was Sie codieren.
• Codeüberprüfungen, da zwei Köpfe besser als einer sind und vier Augen besser als zwei. Ganz zu schweigen davon, dass selbst der Versuch, Ihren Code jemand anderem zu erklären, viele Probleme aufzeigt.
• Versionskontrolle, damit Sie schnell herausfinden können, welche Änderungen den Fehler verursacht haben.
• Refactoring, damit Ihr Code nicht zu einem fürchterlichen, unverständlichen Durcheinander wird.
• Lesen Sie "Clean Code" von Robert C. Martin und tun Sie, was er Ihnen sagt. Sie werden von den Ergebnissen begeistert sein.

Unit-Tests helfen, denn wenn Sie Bugs einführen, brechen diese hoffentlich vor Ihrem Produktionscode. Gut geschriebene Unit-Tests zeigen Ihnen auch genau, was gebrochen ist.

Das wird Ihnen den größten Teil des Weges erleichtern, aber für 99,999% der Projekte müssen Sie immer noch die Dinge von Zeit zu Zeit debuggen. Das Beste, was ich hier tun kann, ist, 4 Dinge zu tun:

1. Verwenden Sie nach Möglichkeit unveränderliche Typen. Wenn ein Wert falsch ist, wissen Sie sofort genau, wo Sie suchen müssen (wo er erstellt wird).
2. Erzwingen Sie Invarianten im Code. Wenn Sie wissen, dass ein Wert definitiv nicht zulässig ist, überprüfen Sie ihn und lösen Sie eine Ausnahme in den Einstiegspunkten für Methoden und Konstruktoren aus. Wenn Sie dies mit unveränderlichen Typen kombinieren, können Sie auch bestimmte Annahmen darüber treffen, was gültig ist oder nicht.
3. Stellen Sie sicher, dass Sie über eine ausreichende Protokollierung verfügen. Melden Sie sich frühzeitig an, und Sie erhalten viele wichtige Informationen darüber, wann Probleme auftreten. AOP funktioniert hier wirklich gut. Nachträgliches Protokollieren ist in der Regel ein wenig Müll - holen Sie es sich frühzeitig im Rahmen des Projektaufbaus.
4. Wenn Ihre Codebasis groß / komplex genug ist, vermeiden Sie die Verwendung von Primitiven - z. B. haben Sie einen Typ namens "Age", anstatt nur einen Int. Zunächst scheint es ein bisschen sinnlos zu sein, aber in der Lage zu sein, alle Verwendungen von etwas in einem Augenblick aufzuspüren, ist ein großer Gewinn beim Debuggen.

Meine 80% sind debuggen. Ich behebe einfache Fehler und versuche, alles zum Laufen zu bringen.

Beginnen Sie mit dem Schreiben von Komponententests und versuchen Sie, eine möglichst hohe Abdeckung zu erzielen. Jemand erwähnte TDD, aber ich würde mit BDD gehen .

Am Ende werden Sie höchstwahrscheinlich 80% für das Debuggen komplexer Fehler ausgeben.

Wie verbringe ich weniger Zeit mit dem Debuggen? Schreiben Sie weniger Code.

Im Ernst, solange Sie Code schreiben, müssen Sie ihn debuggen. Unit-Tests usw. helfen immens, aber denken Sie nicht, dass Sie jemals die Notwendigkeit dafür ganz aufheben werden.

Verstehen Sie das Was und Warum, bevor Sie mit dem Schreiben von Code beginnen. Dann wenden Sie konsequent eine Methodik an. Welche Methodik Sie wählen, ist bei weitem nicht so wichtig wie die konsequente wiederholte Anwendung der Methodik. Wenn Sie konstant gute Ergebnisse erzielen möchten, müssen Sie konstant gute Arbeit leisten, und eine "Methode für Ihren Wahnsinn" ist der erste Schritt, um diese Ergebnisse zu erzielen. Wenn Sie Probleme identifizieren, können Sie Ihre Methodik nach Bedarf anpassen und im Laufe der Zeit Ihren Entwicklungsprozess verbessern, und hoffentlich weniger Bugs und mehr neue, aussagekräftige Entwicklungen.

Lesen Sie Ihren Code sorgfältig durch, bevor Sie ihn kompilieren. Eine sehr sorgfältige Lektüre für Syntax und Funktionalität. Es kann überraschend informativ sein und ist auch ein guter Indikator, wenn ein Codeabschnitt zu kompliziert ist.

Die meisten Antworten scheinen sich darauf zu konzentrieren, wie Sie die Anzahl der zu debuggenden Probleme reduzieren können, und das ist wertvoll. Das Debuggen ist jedoch immer erforderlich, daher ist es hilfreich, Möglichkeiten zu prüfen, wie das Debuggen beschleunigt werden kann.

• Wissen, wie Sie Ihre Versionskontrollsoftware verwenden.

  • Mithilfe von Zweigen können Sie Entwicklungsbereiche herausfiltern und feststellen, in welchem ​​Entwicklungsbereich der Fehler auftritt und in welchem ​​nicht.
  • Wenn Sie ein anderes VCS verwenden, in dem keine Halbierung integriert ist, suchen Sie nach einem Tool, das wie git bisect funktioniert, aber für Ihr VCS (ich weiß, dass es dieses für SVN und SVN gibt) sollte für andere VCSs nicht zu schwer zu erstellen sein). Auf diese Weise können Sie sich auf die Codeänderung beschränken, die den Fehler verursacht hat, und wissen, wo Sie auf Ihren Debugger verweisen müssen. Dieser Teilungsprozess ist schneller, wenn Sie Tests auf den Fehler durchgeführt haben und wissen, welches Commit die anstößige Änderung enthält, wenn Sie atomare Commits ausführen.

• Verbessern Sie Ihr Verständnis der von Ihnen verwendeten Programmiersprache.

  • Lesen Sie Bücher, Blogs und Code über die Programmiersprache.
  • Stellen Sie jedes Mal, wenn Sie einen Fehler beheben, sicher, dass Sie genau verstehen, warum der Code nicht funktioniert hat und warum Ihr Fix funktioniert. Mit der Zeit werden Sie viele Fallstricke in Ihrer Sprache lernen, die Ihnen helfen, ihre Probleme zu vermeiden und die Symptome von ihnen zu erkennen, falls sie erneut auftreten.

• Sei logisch

  • Ändern Sie sonst nicht mehr als eine Sache auf einmal, wenn sich das Verhalten ändert, wissen Sie nicht, welche Änderung die Änderung des Verhaltens verursacht hat.
  • Überprüfen Sie Ihre Annahmen.

Das Hinzufügen zu den Kommentaren für Unit Testing ist aber nur dann wirklich gut, wenn Ihr Code zur Unterstützung separiert wurde (zB MVC). Wenn Sie MVC (oder ähnliches) (Legacy-Projekt) nicht implementieren können, funktionieren Unit-Tests für Ihre Benutzeroberfläche überhaupt nicht. Ich würde dann automatisierte UI-Tests (Microsoft Coded UI Tests, WaitN) hinzufügen, da dies die Fehler in diesem Teil Ihres Codes verringert.

Ich würde auch empfehlen, statische Analyse-Tools (z. B. FxCop / Microsoft Code Analysis, Resharper, JustCode für die MS-Welt) auszuführen. Diese können alle Arten von allgemeinen Codierungsproblemen finden, die die albernen Debugging-Aufgaben reduzieren und sich mehr auf das Debuggen von Geschäftslogik konzentrieren können.

Lass es funktionieren, dann mach es schnell, dann mach es hübsch. Die meisten Fehler stammen aus frühen Optimierungen oder Re-Factoring bei Codezeilen, die völlig in Ordnung waren. Wenn Sie sich für die Objektorientierung entscheiden, wiederholen Sie sich nicht, halten Sie es einfach und überprüfen Sie die Wertebereiche immer auf ihre Richtigkeit, insbesondere, wenn Ihre Methoden bei Einschränkungen noch funktionieren. Es wird Ihnen nicht helfen, weniger Fehler zu machen, aber es wird Ihnen wahrscheinlich helfen, Fehler schneller zu erkennen, und daher dauert das Debuggen weniger Zeit.

Ich habe in letzter Zeit viel über dieses Problem nachgedacht. Die einfache Antwort lautet: Lesen Sie Don Normans Das Design alltäglicher Dinge. Schreiben Sie Code, als würden Sie ein Produkt entwerfen.

Gutes Design minimiert Fehler. Das heißt, ein paar Dinge, von denen die meisten Sie bereits tun (obwohl Sie möglicherweise nicht genau wissen, warum ).

-Name funktioniert intuitiv. Dies ist formal als Erschwinglichkeit bekannt. Das heißt, ein Knopf kann gedrückt werden, ein Hebel kann geschaltet werden, ein Griff kann gezogen werden usw.

- Mach es dir schwer, schlechten Code zu schreiben. Suchen Sie lieber früher als später nach schlechten Eingaben und werfen Sie Fehler, verwenden Sie gegebenenfalls ungarische Apps usw. Diese werden als Sperrfunktionen bezeichnet.

-Verwenden Sie gegebenenfalls die Abstraktion. Das Kurzzeitgedächtnis ist schwach.

-Dokumentation ist natürlich wichtig, aber am wenigsten effektiv, um sicherzustellen, dass der Code ordnungsgemäß verwendet wird. Kurz gesagt, gut gestaltete Produkte benötigen keine Dokumentation. (Der offensichtlichste Weg, dies zu sehen, sind schlechte Beispiele: Türen mit Griffen, die man schieben sollte.)

-Einheitentests. Diese verhindern Fehler nicht wirklich, sondern machen deutlich, wo sich die Fehler befinden, und sorgen für geistige Gesundheit.

Ich bin mir sicher, dass ich noch viel mehr Prinzipien vermisse, aber der springende Punkt ist, lesen Sie mehr über das Entwerfen für Fehler.

Die beste Möglichkeit, das Debugging zu verringern, besteht darin, sich beim Codieren zu konzentrieren und zu verlangsamen. Dies zwingt Sie dazu, Fehler zu sehen, die Sie möglicherweise gemacht haben!

Obwohl ich den oben vorgeschlagenen Komponententest voll und ganz unterstütze, ist TDD oder BDD von großem Wert, da Sie zuerst über das Problem und die Lösung nachdenken müssen.

Aber für mich persönlich ist es ein Wunder, wenn ich mir ein paar Minuten Zeit nehme, um ruhig zu sitzen und über das Problem nachzudenken und wie ich mit jedem Ansatz und den Vor- und Nachteilen umzugehen habe.

Manchmal hilft ein schnelles Kritzeln auf einem Blatt Papier, die größeren zusammenhängenden Teile des Puzzles zu erkennen.

Ich schreibe den schlechtesten Code, wenn ich nur mit dem Kopf voran eintauche und auf die Tastatur klopfe. Ein bisschen Nachdenken und Kontemplation macht einen großen Unterschied.

PS. Ich meine 5 vielleicht 10 Minuten, nicht Stunden, um eine riesige Spezifikation zu schreiben.

Einige gute Antworten schon, nur ein paar mehr als das, was andere gesagt haben.

Lerne aus deinen Fehlern. Machen Sie nicht immer wieder dieselben.

Achten Sie beim Programmieren darauf, Randfälle abzudecken - dies sind Stellen, an denen häufig Fehler auftreten.

Beachten Sie die Anforderung. Selbst wenn es funktioniert, aber nicht den Anforderungen entspricht, ist das ein Fehler.

Ausnahmeprotokolle können eine echte Hilfe sein, wenn in sechs Monaten etwas schief geht. Machen Sie es sich zur Gewohnheit, Ausnahmen aufzuzeichnen.

Meine beiden wichtigsten Gedanken sind: 1) Schreiben Sie besseren Code, der fehlschlägt, wenn Sie etwas Unerwartetes tun. 2) Verbessern Sie das Debuggen

Mein Code ist übersät mit

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Jedes Mal, wenn ich diesen Code ausführe, wird eine Ausnahme ausgelöst, die den Debugger zum Stoppen bringt. Dadurch kann ich die neuen Funktionen programmieren oder die Bedingungen umgehen, anstatt mich darüber zu wundern, was gerade passiert oder einen Fehler aufweist

Um das Debuggen von Problemen mit dem Aufrufstapel, Haltepunkten (mit Bedingungen), dem Sofortfenster (auch als Eingabeaufforderungs- oder Replikationsfenster bezeichnet), Beobachtungsvariablen und was auch immer zu verbessern.