Stellen Sie sich vor, Sie erstellen einen Video-Player in JavaScript. Dieser Videoplayer wiederholt das Video des Benutzers mit einer rekursiven Funktion und aus diesem Grund löst der Browser zu einem too much recursion RangeErrorbestimmten Zeitpunkt eine Schleife aus .

Wahrscheinlich wird niemand die Loop-Funktion so oft nutzen. Ihre Anwendung wird diesen Fehler niemals auslösen, auch wenn der Benutzer die Anwendungsschleife für eine Woche verlassen hat, sie jedoch weiterhin vorhanden ist. Um das Problem zu lösen, müssen Sie die Funktionsweise von Schleifen in Ihrer Anwendung neu gestalten, was sehr viel Zeit in Anspruch nimmt. Wie geht's? Warum?

• Beheben Sie den Fehler

• Lass den Käfer

Sollten Sie nicht nur Fehler beheben, über die die Leute stolpern? Wann wird Bugfixing übertrieben, wenn überhaupt?

BEARBEITEN:

Wenn der rekursive Ansatz, der keinen eigentlichen Fehler verursacht, Sie beunruhigt, nehmen wir an, dass für jede Wiedergabeschleife eines Videos eine Variable um erhöht wird 1. Nach 2 ⁵³ Schleifen läuft diese Variable über und Ihr Programm kann sie nicht mehr verarbeiten, wodurch eine Ausnahme ausgelöst wird.

Man muss pragmatisch sein.

Wenn es unwahrscheinlich ist, dass der Fehler in der realen Welt ausgelöst wird und die Kosten für die Behebung hoch sind, bezweifle ich, dass viele Leute dies als eine gute Verwendung der zu behebenden Ressourcen ansehen. Auf dieser Basis würde ich sagen, lassen Sie es, aber stellen Sie sicher, dass der Hack in ein paar Monaten für Sie oder Ihren Nachfolger dokumentiert ist (siehe letzter Absatz).

Das heißt, Sie sollten dieses Problem als "Lernerfahrung" verwenden und beim nächsten Schleifen keine unnötige rekursive Schleife verwenden.

Seien Sie auch auf diesen Fehlerbericht vorbereitet. Sie werden erstaunt sein, wie gut Endbenutzer an die Grenzen gehen und Fehler aufdecken können. Wenn es für Endbenutzer zu einem Problem wird, müssen Sie es beheben - dann sind Sie froh, dass Sie den Hack dokumentiert haben.

In Windows 95 gab es einen ähnlichen Fehler, der dazu führte, dass Computer nach 49,7 Tagen abstürzten . Es wurde erst einige Jahre nach der Veröffentlichung bemerkt, da ohnehin nur sehr wenige Win95-Systeme so lange aufhielten. Es gibt also einen Punkt: Fehler können durch andere, wichtigere Fehler irrelevant werden.

Was Sie tun müssen, ist eine Risikobewertung für das gesamte Programm und eine Folgenabschätzung für einzelne Fehler.

• Befindet sich diese Software an einer Sicherheitsgrenze?
• Wenn ja, kann dieser Fehler zu einem Exploit führen?
• Ist diese Software für die beabsichtigten Benutzer "geschäftskritisch"? (Siehe die Liste der Dinge, für die die Java-EULA die Verwendung verbietet. )
• Kann der Fehler zu Datenverlust führen? Finanzieller Verlust? Reputationsverlust?
• Wie wahrscheinlich ist es, dass dieser Fehler auftritt? (Sie haben dies in Ihr Szenario aufgenommen.)

Und so weiter. Dies wirkt sich auf die Fehlersuche aus, dh darauf , welche Fehler behoben werden sollen. So ziemlich jede Versand-Software hat sehr lange Listen kleinerer Fehler, deren Behebung noch nicht als wichtig genug erachtet wurde.

Die anderen Antworten sind bereits sehr gut und ich weiß, dass Ihr Beispiel nur ein Beispiel ist, aber ich möchte auf einen großen Teil dieses Prozesses hinweisen, der noch nicht besprochen wurde:

Sie müssen Ihre Annahmen identifizieren und diese Annahmen dann anhand von Eckfällen testen.

Wenn ich mir Ihr Beispiel anschaue, sehe ich ein paar Annahmen:

• Der rekursive Ansatz verursacht schließlich einen Fehler.
• Niemand wird diesen Fehler bemerken, da die Wiedergabe von Videos zu lange dauert, um das Stapellimit zu erreichen.

Andere Leute haben die erste Annahme diskutiert, aber schauen Sie sich die zweite Annahme an: Was ist, wenn mein Video nur einen Bruchteil einer Sekunde lang ist?

Und sicher, vielleicht ist das kein alltäglicher Anwendungsfall. Aber bist du wirklich sicher, dass niemand ein sehr kurzes Video hochladen wird? Sie gehen davon aus, dass Videos eine Mindestdauer haben, und Sie haben wahrscheinlich nicht einmal bemerkt, dass Sie etwas angenommen haben! Könnte diese Annahme andere Fehler an anderen Stellen in Ihrer Anwendung verursachen?

Unbekannte Annahmen sind eine riesige Fehlerquelle.

Wie gesagt, ich weiß, dass Ihr Beispiel nur ein Beispiel ist, aber dieser Prozess, bei dem Sie Ihre Annahmen identifizieren (was oft schwieriger ist als es sich anhört) und dann über Ausnahmen von diesen Annahmen nachdenken, ist ein wichtiger Faktor bei der Entscheidung, wo Sie Ihre Zeit verbringen möchten.

Wenn Sie sich also denken, "Ich sollte das nicht programmieren müssen, da es niemals passieren wird", sollten Sie sich etwas Zeit nehmen, um diese Annahme wirklich zu untersuchen. Sie werden oft an Eckfälle denken, die möglicherweise häufiger vorkommen, als Sie ursprünglich dachten.

Abgesehen davon gibt es einen Punkt, an dem dies zu einer Übung der Sinnlosigkeit wird. Es ist Ihnen wahrscheinlich egal, ob Ihre JavaScript-Anwendung auf einem TI-89-Rechner einwandfrei funktioniert. Daher ist es reine Zeitverschwendung, dafür Zeit aufzuwenden.

Die anderen Antworten haben dies bereits behandelt, aber diese Grenze zwischen "das ist wichtig" und "das ist Zeitverschwendung" zu finden, ist keine exakte Wissenschaft und hängt von vielen Faktoren ab, die sich von einer völlig unterscheiden können Person oder Firma zu einem anderen.

Ein großer Teil dieses Prozesses besteht jedoch darin, zuerst Ihre Annahmen zu identifizieren und dann zu versuchen, Ausnahmen von diesen Annahmen zu erkennen.

Ich würde empfehlen, dass Sie das folgende Papier lesen:

Zuverlässigkeit und ihre Gefahren: Eine Taxonomie

Unter anderem werden verschiedene Arten von Fehlern beschrieben, die in Ihrem Programm auftreten können. Was Sie beschrieben haben, wird als ruhender Fehler bezeichnet . In diesem Artikel wird dies folgendermaßen beschrieben:

Ein Fehler ist aktiv, wenn er einen Fehler erzeugt, andernfalls ruht er. Ein aktiver Fehler ist entweder a) ein interner Fehler, der zuvor ruhte und der durch den Berechnungsprozess oder die Umgebungsbedingungen aktiviert wurde, oder b) ein externer Fehler. Fehleraktivierung ist die Anwendung eines Eingangs (Aktivierungsmuster) auf eine Komponente, die bewirkt, dass ein ruhender Fehler aktiv wird. Die meisten internen Fehler wechseln zwischen ihrem Ruhezustand und ihrem aktiven Zustand

Nachdem dies beschrieben wurde, läuft alles auf ein Kosten-Nutzen-Verhältnis hinaus. Die Kosten würden aus drei Parametern bestehen:

• Wie oft würde das Problem auftreten?
• Was wären die Konsequenzen?
• Wie sehr stört es Sie persönlich?

Die ersten beiden sind entscheidend. Wenn es sich um einen Fehler handelt, der sich einmal in einem blauen Mond manifestiert und / oder für den sich niemand interessiert, oder wenn Sie eine einwandfreie und praktische Lösung gefunden haben, können Sie ihn sicher als bekanntes Problem dokumentieren und zu einem anspruchsvolleren und umfangreicheren Problem übergehen wichtige Aufgaben. Wenn der Fehler jedoch dazu führen würde, dass eine Geldtransaktion fehlschlägt oder ein langer Registrierungsprozess unterbrochen wird, was den Endbenutzer frustriert, müssen Sie entsprechend vorgehen. Vom dritten Parameter rate ich dringend ab. Mit den Worten von Vito Corleone:

Es ist nicht persönlich. Es geht ums Geschäft.

Wenn Sie ein Profi sind, lassen Sie die Emotionen beiseite und handeln Sie optimal. Wenn es sich bei der Anwendung, die Sie schreiben, jedoch um ein Hobby von Ihnen handelt, sind Sie emotional involviert, und der dritte Parameter ist so gültig wie jeder andere, um zu entscheiden, ob ein Fehler behoben werden soll oder nicht.

Dieser Fehler bleibt nur bis zu dem Tag unentdeckt, an dem jemand Ihren Player auf einen Lobby-Bildschirm stellt, auf dem eine Firmenpräsentation rund um die Uhr läuft. Es ist also immer noch ein Fehler.

Die Antwort auf Was machst du? ist wirklich eine Geschäftsentscheidung, keine technische:

• Wenn der Fehler nur 1% Ihrer Benutzer betrifft und Ihr Player eine Funktion nicht unterstützt, die von weiteren 20% benötigt wird, liegt die Wahl auf der Hand. Dokumentieren Sie den Fehler und fahren Sie fort.
• Wenn sich der Bugfix in Ihrer Aufgabenliste befindet, ist es oft besser, ihn zu beheben, bevor Sie neue Funktionen hinzufügen. Sie erhalten die Vorteile eines fehlerfreien Softwareentwicklungsprozesses und verlieren nicht viel Zeit, da er sowieso auf Ihrer Liste steht.

Besonders in großen Unternehmen (oder großen Projekten) gibt es eine sehr pragmatische Möglichkeit, um festzulegen, was zu tun ist.

Wenn die Kosten für die Korrektur höher sind als die Rendite, die die Korrektur bringen wird, behalten Sie den Fehler bei. Umgekehrt, wenn der Fix mehr als seine Kosten zurückbringt, dann behebe den Fehler.

In Ihrem Beispielszenario hängt es davon ab, wie viele Benutzer Sie voraussichtlich verlieren und wie viele Benutzer Sie gewinnen, wenn Sie neue Funktionen entwickeln, anstatt diesen teuren Fehler zu beheben.

Dies ist, warum RESOLVED/WONTFIXist eine Sache. Überbeanspruchen Sie es einfach nicht - technische Schulden können sich häufen, wenn Sie nicht vorsichtig sind. Ist dies ein grundlegendes Problem bei Ihrem Design, das in Zukunft wahrscheinlich andere Probleme verursachen wird? Dann beheben Sie es. Andernfalls? Lassen Sie es sein, bis es eine Priorität wird (falls es jemals geschieht).

Es gibt tatsächlich drei Fehler in der von Ihnen beschriebenen Situation:

1. Das Fehlen eines Prozesses zum Auswerten aller protokollierten Fehler (Sie haben den Fehler in Ihrem Ticket / Backlog / auf welchem ​​System auch immer protokolliert, richtig?), Um zu bestimmen, ob er behoben werden sollte oder nicht. Dies ist eine Managemententscheidung.

2. Der Mangel an Fähigkeiten in Ihrem Team, der dazu führt, dass fehlerhafte Lösungen wie diese verwendet werden. Dies muss dringend behoben werden, um zukünftige Probleme zu vermeiden. (Lerne aus deinen Fehlern.)

3. Das Problem, dass das Video nach sehr langer Zeit nicht mehr angezeigt wird.

Von den drei Fehlern muss möglicherweise nur (3) nicht behoben werden.

Hier gibt es viele Antworten, in denen es darum geht, die Kosten für die Behebung des Fehlers zu ermitteln, anstatt ihn zu belassen. Sie alle enthalten gute Ratschläge, aber ich möchte hinzufügen, dass die Kosten eines Fehlers oft unterschätzt, möglicherweise sehr unterschätzt werden. Der Grund dafür ist, dass vorhandene Fehler das Wasser für die weitere Entwicklung und Wartung durcheinander bringen. Wenn Sie Ihre Tester dazu bringen, mehrere Fehler zu erfassen, die nicht behoben werden, während Sie in Ihrer Software navigieren und nach neuen Fehlern suchen , wird ihre Arbeit langsamer und fehleranfälliger. Einige Fehler, die den Endbenutzer wahrscheinlich nicht betreffen, werden die weitere Entwicklung verlangsamen und das Ergebnis wird fehlerhafter sein.

Eine Sache, die ich in meinen Jahren des Codierens gelernt habe, ist, dass ein Fehler zurückkommt. Der Endbenutzer wird es immer entdecken und darüber berichten. Ob Sie den Fehler beheben oder nicht, ist "nur" eine Frage der Priorität und der Frist.

Wir hatten große Fehler (meiner Meinung nach große), die gegen die Behebung in einer Version entschieden wurden, nur um ein Show-Stopper für die nächste Version zu werden, weil der Endbenutzer immer wieder darauf gestoßen ist. Das Gleiche gilt auch umgekehrt: Wir mussten einen Fehler in einer Funktion beheben, die von niemandem verwendet wird, aber es war für das Management praktisch, dies zu sehen.

Hier gibt es drei Dinge:

Prinzipien

Dies ist eine Seite der Medaille. Bis zu einem gewissen Grad, ich fühle es ist gut auf Fehler beheben zu bestehen (oder schlechte Implementierungen, auch wenn sie „arbeiten“), auch wenn niemand es bemerken.

Betrachten Sie es so: Das eigentliche Problem ist nicht unbedingt der Fehler in Ihrem Beispiel, sondern die Tatsache, dass ein Programmierer es für eine gute Idee hielt, die Schleife in dieser Weise zu implementieren. Es war vom ersten Moment an klar, dass dies keine gute Lösung war. Es gibt jetzt zwei Möglichkeiten:

• Der Programmierer merkte es einfach nicht. Nun ... ein Programmierer sollte eine Vorstellung davon entwickeln, wie sein Code läuft. Es ist nicht so, dass Rekursion ein sehr schwieriges Konzept ist. Indem er den Fehler behebt (und durch die zusätzliche Arbeit schwitzt), lernt er möglicherweise etwas und merkt sich es, wenn auch nur, um die zusätzliche Arbeit in der Zukunft zu vermeiden. Wenn der Grund war , dass er einfach nicht genug Zeit hatte, konnte Management erfahren , dass Programmierer haben mehr Zeit benötigen , um eine höhere Qualität Code zu erstellen.

• Der Programmierer bemerkte es, hielt es aber für "kein Problem". Wenn dies so bleibt, entwickelt sich eine Kultur des Laissez-Faire, die letztendlich zu Fehlern führt, bei denen es wirklich weh tut. In diesem speziellen Fall, wen interessiert das? Was aber, wenn dieser Programmierer das nächste Mal eine Bankanwendung entwickelt und entscheidet, dass eine bestimmte Konstellation niemals eintreten wird? Dann ist es so. Schlechte Zeiten.

Pragmatismus

Das ist die andere Seite. Von Natürlich würden Sie in diesem Fall wahrscheinlich, nicht den Fehler beheben. Aber aufgepasst - es gibt Pragmatismus und dann Pragmatismus. Guter Pragmatismus ist, wenn Sie eine schnelle, aber solide und fundierte Lösung für ein Problem finden. Das heißt, Sie vermeiden Überdesigns, aber die Dinge, die Sie tatsächlich implementieren, sind immer noch gut durchdacht. Schlechter Pragmatismus ist, wenn Sie einfach etwas zusammen hacken, was "nur so" funktioniert und bei der ersten Gelegenheit kaputt geht.

Scheitern Sie schnell, scheitern Sie hart

Wenn Sie Zweifel haben, scheitern Sie schnell und scheitern Sie hart.

Dies bedeutet unter anderem, dass Ihr Code die Fehlerbedingung und nicht die Umgebung bemerkt.

In diesem Beispiel können Sie es mindestens so einrichten, dass der Fehler bei der harten Laufzeit ("Stack-Tiefe überschritten" oder ähnliches) nicht auftritt, indem Sie ihn durch eine eigene harte Ausnahme ersetzen. Sie könnten beispielsweise einen globalen Zähler haben und willkürlich entscheiden, dass Sie nach 1000 Videos aussteigen (oder eine beliebige Anzahl, die hoch genug ist, um bei normaler Verwendung nicht vorzukommen, und niedrig genug, um in den meisten Browsern noch zu funktionieren). Geben Sie dieser Ausnahme (die eine allgemeine Ausnahme sein kann, z. B. eine RuntimeExceptionin Java oder eine einfache Zeichenfolge in JavaScript oder Ruby) eine aussagekräftige Nachricht. Sie müssen nicht so weit gehen, um eine neue Art von Ausnahmen zu erstellen, oder was auch immer Sie in Ihrer speziellen Programmiersprache tun.

Auf diese Weise haben Sie

• ... dokumentiert das Problem im Code.
• ... machte es zu einem deterministischen Problem. Sie wissen, dass Ihre Ausnahme eintreten wird. Sie sind nicht an Änderungen der zugrunde liegenden Browsertechnologie interessiert (denken Sie nicht nur an den PC-Browser, sondern auch an Smartphones, Tablets oder zukünftige Technologien).
• ... hat es leicht gemacht, es zu reparieren, wenn Sie es irgendwann einmal reparieren müssen. Die Ursache des Problems ist in Ihrer Nachricht vermerkt. Sie erhalten einen aussagekräftigen Backtrack und das alles.
• ... noch keine Zeit für "echte" Fehlerbehandlung verschwendet (denken Sie daran, dass Sie nie damit rechnen, dass der Fehler auftritt).

Meine Konvention ist es, solchen Fehlermeldungen das Wort "Paranoia:" voranzustellen. Dies ist ein klares Zeichen für mich und alle anderen, dass ich nie damit rechne, dass dieser Fehler auftaucht. Ich kann sie klar von "echten" Ausnahmen trennen. Wenn ich so etwas in einer grafischen Benutzeroberfläche oder in einer Protokolldatei sehe, weiß ich mit Sicherheit, dass ich ein ernstes Problem habe - ich hätte schließlich nie damit gerechnet, dass sie auftreten. An diesem Punkt gehe ich in den Crunch-Modus (mit einer guten Chance, ihn schnell und ziemlich einfach zu lösen, da ich genau weiß, wo das Problem aufgetreten ist, und mich so vor einer Menge fehlerhafter Fehlerbehebung bewahre).

Ein Post-It auf dem Schreibtisch eines älteren Entwicklers an meinem Arbeitsplatz sagt

Hilft es jemandem?

Ich denke, das ist oft ein guter Ausgangspunkt für den Denkprozess. Es gibt immer viele Dinge zu reparieren und zu verbessern - aber wie viel Wert steigern Sie tatsächlich? ... ob es um Benutzerfreundlichkeit, Zuverlässigkeit, Wartbarkeit, Lesbarkeit, Leistung geht ... oder um irgendeinen anderen Aspekt.

Drei Dinge fallen mir ein:

Erstens muss die Auswirkung eines erkannten Fehlers gründlich untersucht werden, bevor die Entscheidung, den Fehler im Code zu belassen, auf verantwortungsvolle Weise getroffen werden kann. (In Ihrem Beispiel habe ich sofort über das Speicherverlust nachgedacht, das der ständig wachsende Stapel darstellt und das Ihren Browser mit jeder Rekursion langsamer und langsamer machen könnte.) Diese gründliche Untersuchung dauert oft länger als die Behebung des Fehlers, daher würde ich die Behebung vorziehen der Bug in den meisten Fällen.

Zweitens haben Bugs eine Tendenz, mehr Auswirkungen zu haben, als man zunächst denkt. Wir sind alle sehr vertraut mit Arbeitscode, da dies der "normale" Fall ist. Bugs sind dagegen eine "Ausnahme". Natürlich haben wir alle viele Fehler gesehen, aber insgesamt haben wir deutlich mehr funktionierenden Code gesehen. Wir haben daher mehr Erfahrung mit dem Verhalten von Arbeitscode als mit dem Verhalten von fehlerhaftem Code. Es gibt unzählige Bücher über Arbeitscode und was er in welchen Situationen bewirken wird. Über das Verhalten von Buggy-Code gibt es so gut wie keine.

Der Grund dafür ist einfach: Bugs sind nicht Ordnung, sondern Chaos . Sie haben oft eine Spur von Ordnung in sich (oder andersherum: Sie zerstören die Ordnung nicht vollständig), aber ihre fehlerhafte Natur ist eine Zerstörung der Ordnung, die der Programmierer wollte. Das Chaos selbst trotzt der korrekten Einschätzung. Es ist viel schwieriger zu sagen, was ein Programm mit einem Fehler bewirkt, als was ein korrektes Programm bewirkt, nur weil es nicht mehr in unsere mentalen Muster passt.

Drittens enthielt Ihr Beispiel den Aspekt, dass das Beheben des Fehlers eine Neugestaltung des Programms bedeuten würde. (Wenn Sie diesen Aspekt streifen, ist die Antwort einfach: Beheben Sie den Fehler, es sollte nicht zu lange dauern, da keine Neugestaltung erforderlich ist. Andernfalls :) In einem solchen Fall würde ich das Vertrauen in das Programm verlieren, wie es derzeit gestaltet ist. Das Redesign wäre eine Möglichkeit, dieses Vertrauen wiederherzustellen.

Alles, was gesagt wird , Programme sind Dinge, die von Menschen verwendet werden, und eine fehlende Funktion oder ein zweiter, wirklich umständlicher Fehler an anderer Stelle kann Vorrang vor der Behebung Ihres Fehlers haben. Nehmen Sie dann natürlich den pragmatischen Weg und machen Sie zuerst andere Dinge. Aber vergessen Sie niemals, dass eine erste schnelle Einschätzung der Auswirkungen eines Fehlers völlig falsch sein kann.

Geringe Wahrscheinlichkeit / leichte Konsequenzen = Geringe Wahrscheinlichkeit

• Wenn die Wahrscheinlichkeit eines Auftretens sehr gering ist
• Wenn die Folgen des Auftretens mild sind
• Dann stellt der Fehler keine Bedrohung dar und ist keine vorrangige Lösung.

Aber das kann keine Krücke für faule Entwickler werden ...

• Was bedeutet "sehr geringes Auftreten" überhaupt?
• Was bedeuten "milde Konsequenzen" überhaupt?

Um festzustellen, dass die Wahrscheinlichkeit eines Auftretens sehr gering und die Folgen gering sind, muss das Entwicklerteam den Code, die Verwendungsmuster und die Sicherheit verstehen.

Die meisten Entwickler sind überrascht, dass Dinge, die sie ursprünglich gelernt haben, nie passieren werden, tatsächlich viel passieren

Unser Bildungssystem lehrt Wahrscheinlichkeit und Logik nicht sehr gut. Die meisten Personen, einschließlich der meisten Softwareentwickler, haben eine kaputte Logik und eine kaputte Proability-Intuition. Erfahrung mit Problemen der realen Welt und Erfahrung mit umfangreichen Simulationen sind die einzige Möglichkeit, dies zu beheben.

Konfrontieren Sie Ihre Intuition mit realen Daten

Es ist wichtig, mehrere Protokolle zu erstellen, um den Verwendungsmustern folgen zu können. Füllen Sie den Code mit Aussagen über Dinge, die Ihrer Meinung nach nicht passieren sollten. Sie werden überrascht sein, dass sie es tun. Auf diese Weise können Sie Ihre Intuition mit harten Daten konfrontieren und verfeinern.

Mein Beispiel für ein mildes Problem und ein Maß an Kontrolle

Auf einer E-Commerce-Site, an der ich vor langer Zeit gearbeitet habe, hat ein anderer Programmierer einen Fehler gemacht: In einem undurchsichtigen Zustand belastete das System den Client mit einem Cent weniger als in den Protokollen registriert. Ich habe den Fehler entdeckt, weil ich Berichte erstellt habe, um Unterschiede zwischen den Protokollen und den Kontoständen zu identifizieren und das Buchhaltungssystem widerstandsfähiger zu machen. Ich habe diesen Fehler nie behoben, da der Unterschied sehr gering war. Die Differenz wurde täglich berechnet und lag unter 2 US-Dollar monatlich. Zufällig haben wir ein völlig neues System entwickelt, das in einem Jahr das jetzige ersetzen soll. Es macht keinen Sinn, Ressourcen von potenziell rentablen Projekten abzuziehen, um etwas zu reparieren, das monatlich 2,00 USD kostet und einer angemessenen Kontrollmaßnahme unterzogen wurde.

Fazit

Ja, es gibt Fehler, die nicht sofort behoben werden müssen und die nicht wichtig genug sind, um die Entwicklung neuer Funktionen zu verzögern. Das System muss jedoch die Kontrolle über das Auftreten dieses Fehlers haben, um sicherzustellen, dass er klein ist, da wir unserer eigenen Intuition nicht vertrauen können.

Ich denke, das ist von Anfang an die falsche Frage.

Die Frage ist nicht "Sollte ich diesen Fehler beheben oder sollte ich diesen Fehler nicht beheben". Jeder Entwickler hat eine begrenzte Zeit. Die Frage ist also: "Was ist das Nützlichste, was ich in einer Stunde, vier Stunden oder einer Woche tun kann?"

Wenn das Beheben dieses Fehlers am nützlichsten ist, weil es die Software für die meisten Leute um den größten Betrag verbessert, dann behebe den Fehler. Wenn Sie an anderer Stelle größere Verbesserungen vornehmen könnten, indem Sie Features hinzufügen, die den Leuten fehlen, oder indem Sie einen wichtigeren Fehler beheben, dann tun Sie diese anderen Dinge. Und zusätzliche Bonuspunkte für alles, was Ihre zukünftige Entwicklung effizienter macht.

Fehlerbehebung ist immer ein Overkill

Lassen Sie uns klassifizieren Bug Teil zuerst.

Ist es ein ehrlicher Fehler , z. B. ein einmaliger Fehler oder eine variable Verschattung, die den Tests entgangen ist? In diesem Fall hoffe ich, dass Sie nicht nur das Problem "behoben", sondern auch neue Komponententests geschrieben haben, sondern auch die Gelegenheit genutzt haben, Code in der Nähe umzugestalten, bei dem alles letztere eine nützliche Arbeit ist .

Wenn es sich jedoch, wie in Ihrem Fall, tatsächlich um einen Konstruktionsfehler handelt, sollten Sie die Konstruktion neu bewerten oder diese Funktion im schlimmsten Fall deaktivieren .

Versuchen Sie also nicht, das Problem einfach zu beheben .

Sie könnten natürlich noch Schlimmeres tun - Sie könnten eine Hack-on-Hack- Methode ausprobieren . Video-Looping ist ein Hack (schlechte Architektur und es ist ein Bruch bekannt). Sie können ein Schleifenlimit hinzufügen , sodass die Schleife nach N Iterationen (die Sie getestet haben und die unterhalb des Browserlimits liegen) beendet wird.

Die Auswirkungen sind offensichtlich, jetzt müssen Sie sowohl den fehlerhaften Code als auch das neue Schleifenlimit unterstützen.

PS entschuldigt sich für die extreme Sicht.

PPS Ein Hinweis zur Terminologie: Sie können einen Fehler nicht "beheben". Na ein Tierarzt könnte das vielleicht, aber lass uns da nicht hingehen ;-). Probleme werden behoben oder "behoben", während Fehler beseitigt oder umgangen werden.