Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert wird, bevor er diagnostiziert und behoben wird?

Ich arbeite für eine Softwareproduktfirma. Wir haben große Unternehmenskunden, die unser Produkt implementieren und die wir unterstützen. Wenn zum Beispiel ein Fehler vorliegt, stellen wir Patches usw. zur Verfügung. Mit anderen Worten, es handelt sich um eine recht typische Konfiguration.

Kürzlich wurde mir ein Ticket ausgestellt und zugewiesen, das sich auf eine von einem Kunden in einer Protokolldatei festgestellte Ausnahme bezieht, die mit dem gleichzeitigen Datenbankzugriff in einer Clusterimplementierung unseres Produkts zu tun hat. Die spezifische Konfiguration dieses Kunden kann daher für das Auftreten dieses Fehlers von entscheidender Bedeutung sein. Alles, was wir vom Kunden bekamen, war die Protokolldatei.

Der Ansatz, den ich meinem Team vorgeschlagen hatte, bestand darin, zu versuchen, den Fehler in einer Konfiguration zu reproduzieren, die der des Kunden ähnelt, und ein vergleichbares Protokoll zu erhalten. Sie stimmen jedoch nicht mit meinem Ansatz überein, dass ich den Fehler nicht reproduzieren muss, da er zu zeitaufwändig ist und die Simulation eines Serverclusters auf VMs erforderlich macht. Mein Team schlägt vor, einfach "dem Code zu folgen", um festzustellen, wo sich der Thread- und / oder Transaktions-unsichere Code befindet, und die Änderung einer einfachen lokalen Entwicklung vorzunehmen, bei der es sich nicht um eine Cluster-Implementierung handelt, wie in der Umgebung, in der das Ereignis auftritt des Fehlers entsteht.

Für mich scheint es schwierig zu sein, einen abstrakten Entwurf (Programmcode) anstelle einer sichtbaren Manifestation (Laufzeitreproduktion) zu verwenden. Deshalb wollte ich eine allgemeine Frage stellen:

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Oder:

Wenn ich ein erfahrener Entwickler bin, sollte ich in der Lage sein, Multithread-Code zu lesen und ein mentales Bild davon zu erstellen, was er in allen Anwendungsszenarien tut, anstatt die Anwendung auszuführen, verschiedene Anwendungsszenarien zu testen und die Schritte durchzuarbeiten Code Zeile für Zeile? Oder bin ich ein schlechter Entwickler, weil ich so ein Arbeitsumfeld fordere?

Debuggen für Weichlinge?

Meiner Meinung nach sollte jeder Fix, der als Antwort auf ein Incident-Ticket eingereicht wird, in einer Umgebung getestet werden, die simuliert wurde, um der ursprünglichen Umgebung so nahe wie möglich zu sein. Woher können Sie sonst wissen, dass das Problem wirklich behoben wird? Es ist, als würde man ein neues Fahrzeugmodell veröffentlichen, ohne es mit einem Dummy einem Crashtest zu unterziehen, um zu demonstrieren, dass die Airbags tatsächlich funktionieren.

Zu guter Letzt, wenn Sie mir zustimmen:

Wie soll ich mit meinem Team sprechen, um sie davon zu überzeugen, dass mein Ansatz vernünftig, konservativ und kugelsicherer ist?

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Du solltest dein Bestes geben. Ich weiß , dass manchmal gibt es Bedingungen und Umgebungen , die so komplex sind , können sie nicht reproduziert werden genau , aber Sie sollten auf jeden Fall versuchen , wenn Sie können.

Wenn Sie den Fehler nie reproduziert und selbst gesehen haben, wie können Sie dann 100% sicher sein, dass Sie ihn wirklich behoben haben? Möglicherweise führt Ihre vorgeschlagene Fehlerbehebung einen anderen subtilen Fehler ein, der erst dann auftritt, wenn Sie tatsächlich versuchen , den ursprünglichen Fehler zu reproduzieren.

Wenn ich ein leitender Entwickler bin, sollte ich in der Lage sein, (Multithread-) Code zu lesen und mir ein Bild davon zu machen, was er in allen Anwendungsszenarien tut, anstatt die Anwendung auszuführen, verschiedene Anwendungsszenarien zu testen und durchzuarbeiten der Code Zeile für Zeile? Oder bin ich ein schlechter Entwickler, weil ich so ein Arbeitsumfeld fordere? Debuggen für Weichlinge?

Ich würde niemandem vertrauen, der den Code "im Kopf" laufen lässt, wenn dies der einzige Ansatz ist. Es ist ein guter Anfang . Reproduzieren Sie den Fehler und beheben Sie ihn. Zeigen Sie dann , dass die Lösung verhindert, dass der Fehler erneut auftritt. Hier sollte er enden .

Wie soll ich mit meinem Team sprechen, um sie davon zu überzeugen, dass mein Ansatz vernünftig, konservativ und kugelsicherer ist?

Denn wenn sie den Fehler nie reproduziert haben, können sie nicht sicher sein, dass er behoben ist. Und wenn der Kunde zurückkommt und sich beschwert, dass der Fehler immer noch da ist, ist das keine gute Sache. Immerhin zahlen sie Ihnen viel Geld (nehme ich an), um dieses Problem zu lösen.

Wenn Sie nicht das Problem richtig zu beheben, haben Sie gebrochen Glauben mit dem Kunden (bis zu einem gewissen Grad) , und wenn es Wettbewerber in Ihrem Markt sind, können sie nicht Ihre Kunden bleiben.

Wie wollen sie überprüfen, ob der betreffende Fehler behoben wurde? Möchten sie nicht getesteten Code an den Benutzer senden und ihn herausfinden lassen? Jeder Testaufbau, von dem nie gezeigt wurde, dass er den Fehler reproduziert, kann nicht als Beleg für die Abwesenheit des Fehlers herangezogen werden. Sie müssen sicherlich nicht die gesamte Client-Umgebung reproduzieren, aber Sie benötigen genug, um den Fehler zu reproduzieren.

Ich halte es nicht für unvernünftig, jeden Fehler zu reproduzieren, bevor er behoben wird. Wenn Sie jedoch versuchen, es zu reproduzieren, und Sie können es nicht, dann ist es eher eine geschäftliche Entscheidung, ob Blind Patches eine gute Idee sind oder nicht.

Idealerweise möchten Sie jeden Fehler reproduzieren können, damit Sie zumindest testen können, ob er behoben wurde.

Aber ... Das ist vielleicht nicht immer machbar oder sogar physikalisch möglich. Insbesondere bei Unternehmenssoftware, bei der jede Installation einzigartig ist. Es gibt auch die Kosten-Nutzen-Bewertung. Ein paar Stunden Code durchzusehen und ein paar fundierte Vermutungen über ein nicht kritisches Problem anzustellen, kann weitaus weniger kosten, als wenn ein Team des technischen Supports wochenlang versucht, die Umgebung eines Kunden genau in der Hoffnung einzurichten und zu duplizieren, die Umgebung zu duplizieren Problem. Früher, als ich in der 'Enterprise'-Welt arbeitete, flogen wir oft nur Codierer heraus und ließen sie Fehler vor Ort beheben, da es keine Möglichkeit gab, das Setup des Kunden zu duplizieren.

Also duplizieren Sie, wenn Sie können, aber wenn Sie nicht können, machen Sie sich Ihr Wissen über das System zunutze und versuchen Sie, den Täter im Code zu identifizieren.

Ich denke nicht, dass Sie eine Reproduktion des Fehlers zu einer Bedingung machen sollten, um den Fehler zu untersuchen. Wie Sie bereits erwähnt haben, gibt es verschiedene Möglichkeiten, um das Problem zu beheben - und Sie sollten alle verwenden. Sie sollten sich glücklich schätzen, dass sie Ihnen eine Protokolldatei geben konnten! Wenn Sie oder jemand in Ihrem Unternehmen in der Lage ist, den Fehler zu reproduzieren, großartig! Wenn nicht, sollten Sie dennoch versuchen, die Protokolle zu analysieren und die Umstände zu ermitteln, unter denen der Fehler aufgetreten ist. Wie Ihre Kollegen vorgeschlagen haben, ist es möglicherweise möglich, den Code zu lesen, herauszufinden, unter welchen Bedingungen der Fehler auftreten könnte, und dann zu versuchen, das Szenario selbst neu zu erstellen.

Veröffentlichen Sie jedoch nicht den aktuellen Fix, der noch nicht getestet wurde. Jede Änderung, die Sie vornehmen, sollte die Standardroutine für Entwickler-, Qualitätssicherungs- und Integrationstests durchlaufen. Es kann sich als schwierig erweisen, es zu testen - Sie haben Multithread-Code erwähnt, der notorisch schwer zu debuggen ist. Hier stimme ich Ihrem Ansatz zur Erstellung einer Testkonfiguration oder -umgebung zu. Wenn Sie ein Problem im Code gefunden haben, sollten Sie es viel einfacher finden, die Umgebung zu erstellen, das Problem zu reproduzieren und das Update zu testen.

Für mich handelt es sich weniger um ein Debugging-Problem als vielmehr um ein Kundendienstproblem. Sie haben einen Fehlerbericht von einem Kunden erhalten. Sie sind verpflichtet, die erforderliche Sorgfalt zu walten, um das Problem zu finden und zu beheben.

Meiner Meinung nach ... müssen Sie als Entscheidungsträger Ihre Position rechtfertigen können. Wenn das Ziel der 3rd Line Support-Abteilung darin besteht, Fehler in kürzester Zeit mit dem akzeptablen Aufwand des Kunden zu beheben, muss jeder Ansatz diesem Ziel entsprechen. Darüber hinaus sollte es kein Problem geben, das Team zu überzeugen, wenn nachgewiesen werden kann, dass der Ansatz die schnellsten erwarteten Ergebnisse liefert.

Nachdem ich im Support gearbeitet habe, habe ich vernünftigerweise erwartet, dass der Client einige "Skripte" von Aktionen geben kann, die er ausgeführt hat, um den Fehler konsistent zu reproduzieren, und, wenn nicht konsistent, Kandidatenbeispiele, die den Fehler verursacht haben.

Wenn ich neu im System wäre und keinen Hintergrund mit dem Code hätte, würden meine ersten Schritte darin bestehen, die möglichen Fehlerquellen zu identifizieren. Möglicherweise reicht die Protokollierung nicht aus, um einen Kandidatencode zu identifizieren. Je nach Client bin ich möglicherweise geneigt, ihnen eine Debug-Version zu geben, damit sie möglicherweise Protokolldateien zurückgeben können, die weitere Hinweise auf die Position des fehlerhaften Codes geben.

Wenn ich in der Lage bin, den Codeblock schnell zu identifizieren, kann eine visuelle Abbildung des Flusses ausreichen, um den Code zu erkennen. Wenn nicht, kann eine auf Unit-Tests basierende Simulation ausreichend sein. Es kann sein, dass das Einrichten einer Clientreplikationsumgebung weniger Zeit in Anspruch nimmt, insbesondere wenn das Problem in hohem Maße reproduzierbar ist.

Ich denke, Sie werden vielleicht feststellen, dass Ihr Ansatz eine Kombination der vorgeschlagenen Lösungen sein sollte und dass es der Schlüssel ist, um die Arbeit effizient zu erledigen, wenn Sie wissen, wann Sie eine beenden und mit der nächsten fortfahren müssen.

Ich bin mir ziemlich sicher, dass das Team die Vorstellung unterstützen wird, dass, wenn es eine Chance gibt, dass ihre Lösung den Fehler schneller findet, und ihnen dann einen geeigneten Zeitrahmen gibt, um zu beweisen, dass sich dies nicht zu stark auf die Zeit auswirkt, die zur Behebung des Fehlers erforderlich ist, je nachdem, welcher Fall Route, die Sie nehmen.

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Ich sage ja, mit einigen Einschränkungen.

• Ich denke, es ist in Ordnung, den Code durchzulesen und Orte zu finden, die problematisch aussehen. Erstellen Sie einen Patch und senden Sie diesen an den Client, um zu prüfen, ob das Problem dadurch behoben wird. Wenn dieser Ansatz weiterhin fehlschlägt, müssen Sie möglicherweise andere Optionen untersuchen. Denken Sie daran, dass Sie möglicherweise einen Fehler beheben, aber möglicherweise nicht den gemeldeten Fehler.
• Wenn Sie es nicht innerhalb des Rahmens reproduzieren können und keine roten Fahnen im Code finden, ist möglicherweise eine engere Abstimmung mit dem Kunden erforderlich. Ich bin schon früher zu Kunden geflogen, um vor Ort Fehler zu beheben. Es ist nicht die beste Entwicklungsumgebung, aber manchmal, wenn das Problem in der Umgebung liegt, ist es am einfachsten, die genaue Ursache zu finden, wenn Sie sie konsistent reproduzieren können.

Ich war in diesem Szenario auf der Kundenseite. Ich arbeitete in einem US-Regierungsbüro, das einen unglaublich großen Oracle-Datenbankcluster verwendete (mehrere Terabyte Daten und die Verarbeitung von Millionen Datensätzen pro Tag).

Wir stießen auf ein seltsames Problem, das sich für uns sehr leicht reproduzieren ließ. Wir haben Oracle den Fehler gemeldet und sind wochenlang mit ihnen hin und her gegangen und haben ihnen Protokolle gesendet. Sie sagten, sie könnten das Problem nicht reproduzieren, schickten uns aber ein paar Patches, mit denen sie das Problem beheben könnten. Keiner von ihnen tat es.

Sie haben schließlich ein paar Entwickler zu uns geflogen, um das Problem vor Ort zu beheben. In diesem Moment wurde die Ursache des Fehlers gefunden und ein späterer Patch hat das Problem korrekt behoben.

Wenn Sie dem Problem nicht positiv gegenüberstehen, können Sie der Lösung auch nicht positiv gegenüberstehen. Wenn Sie wissen, wie Sie das Problem in mindestens einer Testfallsituation zuverlässig reproduzieren können, können Sie nachweisen, dass Sie wissen, wie der Fehler verursacht wird, und können daher auch auf der anderen Seite nachweisen, dass das Problem aufgrund des nachfolgenden Mangels behoben wurde Fehler im gleichen Testfall nach dem Anwenden des Updates.

Das heißt, Race-Bedingungen, Nebenläufigkeitsprobleme und andere "nicht deterministische" Fehler sind für einen Entwickler am schwierigsten auf diese Weise zu lokalisieren, da sie selten auf einem System mit höherer Auslastung und mehr Komplexität auftreten als die Kopien eines Entwicklers das Programm, und sie verschwinden, wenn die Task zu einem späteren Zeitpunkt auf demselben System erneut ausgeführt wird.

Meistens hat das, was ursprünglich wie ein zufälliger Fehler aussieht, eine deterministische Ursache, die dazu führt, dass der Fehler deterministisch reproduzierbar ist, sobald Sie wissen, wie. Diejenigen, die sich dem widersetzen, die wahren Heisenbugs (scheinbar zufällige Bugs, die verschwinden, wenn Sie versuchen, sie in einer sterilen, überwachten Umgebung zu testen), sind zu 99,9% zeitbezogen, und sobald Sie das verstanden haben, wird Ihr Weg nach vorne klarer. Suchen Sie nach Dingen, die fehlschlagen könnten, wenn während der Ausführung des Codes ein anderes Wort auf den Kopf kommt. Wenn Sie eine solche Sicherheitsanfälligkeit finden, versuchen Sie, sie in einem Test auszunutzen, um festzustellen, ob sie das Verhalten aufweist, das Sie reproduzieren möchten.

In diesen Situationen ist in der Regel ein erheblicher Umfang eingehender Codeüberprüfungen erforderlich. Sie müssen sich den Code ansehen, alle vorgefassten Vorstellungen davon, wie sich der Code verhalten soll , aufgeben und sich Szenarien vorstellen, in denen der Code in der von Ihrem Client beobachteten Weise fehlschlagen könnte . Versuchen Sie für jedes Szenario, einen Test zu entwickeln, der in Ihrer aktuellen automatisierten Testumgebung effizient ausgeführt werden kann (dh, ohne dass ein neuer VM-Stack für diesen einen Test erforderlich ist), der beweist oder widerlegt, dass sich der Code wie erwartet verhält ( Dies würde, je nachdem, was Sie erwartet haben, beweisen oder widerlegen, dass dieser Code eine mögliche Ursache für die Probleme der Clients ist. Dies ist die wissenschaftliche Methode für Softwareentwickler. beobachten, hypothetisieren, testen, reflektieren, wiederholen.

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Nein, das ist es definitiv nicht. Das wäre eine blöde Politik.

Das Problem, das ich bei Ihrer Frage und Ihrem Vorschlag sehe, ist, dass sie nicht unterscheiden können zwischen

• Fehlerberichte
• Ausfälle ( Fehler )
• Bugs (manchmal auch Fehler genannt )

Ein Fehlerbericht ist eine Mitteilung über einen Fehler. Es sagt dir, dass jemand denkt, dass etwas nicht stimmt. Es kann oder kann nicht spezifisch sein, was falsch sein soll.

Ein Fehlerbericht ist ein Hinweis auf einen Fehler.

Ein Misserfolg ist ein Vorfall, bei dem etwas schief geht. Eine bestimmte Fehlfunktion, aber nicht unbedingt mit Hinweisen darauf, was sie verursacht haben könnte.

Ein Fehler kann durch einen Fehler verursacht werden.

Ein Fehler ist eine Ursache für Fehler. Etwas, das (im Prinzip) geändert werden kann, um zu verhindern, dass die von ihm verursachten Fehler in der Zukunft auftreten.

Wenn ein Fehler gemeldet wird, ist die Ursache manchmal sofort klar. In einem solchen Fall wäre es unsinnig, den Fehler zu reproduzieren. In anderen Fällen ist die Ursache überhaupt nicht klar: Der Fehlerbericht beschreibt keinen bestimmten Fehler, aber der Fehler gibt keinen Hinweis darauf, was die Ursache sein könnte. In solchen Fällen halte ich Ihren Rat für berechtigt - aber nicht immer: Man besteht nicht darauf, eine zweite 370-Millionen-Dollar-Weltraumrakete zum Absturz zu bringen, bevor man sich bereit erklärt, zu untersuchen, was den ersten zum Absturz gebracht hat (ein bestimmter Fehler in der Steuerungssoftware).

Und dazwischen gibt es auch alle möglichen Fälle; Wenn beispielsweise ein Fehlerbericht nicht beweist, sondern nur andeutet, dass ein potenzielles Problem, dessen Sie sich bereits bewusst waren, eine Rolle spielen könnte, ist dies möglicherweise ein Anreiz genug, es sich genauer anzusehen.

Das Beharren auf Reproduzierbarkeit ist für die härteren Fälle zwar ratsam, es ist jedoch nicht ratsam, es als strenge Richtlinie durchzusetzen.

Wie bei allem anderen in der Softwareentwicklung ist die richtige Antwort ein Kompromiss.

Theoretisch sollten Sie niemals versuchen, einen Fehler zu beheben, wenn Sie nicht nachweisen können, dass er existiert. Dies kann dazu führen, dass Sie unnötige Änderungen an Ihrem Code vornehmen, die letztendlich nichts lösen. Und es zu beweisen bedeutet, es zuerst zu reproduzieren, dann einen Fix zu erstellen und anzuwenden und dann zu demonstrieren, dass es nicht mehr passiert. Ihr Bauch ist es, Sie in die richtige Richtung zu lenken. Wenn Sie sicher sein möchten, dass Sie das Problem Ihres Kunden gelöst haben, müssen Sie zunächst wissen, was es verursacht hat.

In der Praxis ist das nicht immer möglich. Möglicherweise tritt der Fehler nur in großen Clustern auf, in denen Dutzende Benutzer gleichzeitig auf Ihren Code zugreifen. Möglicherweise gibt es eine bestimmte Kombination von Datenoperationen für bestimmte Datensätze, die den Fehler auslösen, und Sie haben keine Ahnung, was das ist. Vielleicht hat Ihr Kunde das Programm 100 Stunden lang interaktiv ohne Unterbrechung ausgeführt, bevor der Fehler aufgetreten ist.

In all diesen Fällen besteht die große Wahrscheinlichkeit, dass Ihre Abteilung nicht die Zeit oder das Geld hat, um den Fehler zu reproduzieren, bevor Sie mit der Arbeit beginnen. In vielen Fällen ist es für Sie als Entwickler viel offensichtlicher, dass der Code einen Fehler enthält, der Sie auf die richtige Situation hinweist . Sobald Sie das Problem diagnostiziert haben, können Sie es möglicherweise wiederholen. Es ist nicht ideal, aber gleichzeitig gehört es zu Ihrer Aufgabe als leitender Entwickler, zu wissen, wie man Code liest und interpretiert, zum Teil, um diese Art von vergrabenen Fehlern zu lokalisieren.

Meiner Meinung nach konzentrieren Sie sich auf den falschen Teil der Frage. Was ist, wenn Sie den betreffenden Fehler letztendlich nicht reproduzieren können ? Für einen Kunden ist nichts frustrierender, als zu hören: "Ja, wir wissen, dass Sie das Programm zum Absturz gebracht haben, aber wir können es nicht reproduzieren, es ist also kein Fehler." Wenn Ihr Kunde dies hört, interpretiert er es als "Wir wissen, dass unsere Software fehlerhaft ist, aber wir können uns nicht die Mühe machen, die Fehler zu beheben, also drücken Sie einfach die Daumen." Wenn es besser ist, einen gemeldeten Fehler als "nicht reproduzierbar" oder als "nicht reproduzierbar" zu schließen, wir aber einige sinnvolle Änderungen vorgenommen haben, um die Stabilität zu verbessern?

Sofern der Fehler nicht offensichtlich, offensichtlich und trivial ist, mit einer sehr spezifischen Fehlermeldung usw., ist es oft sehr schwierig, einen Fehler zu beheben, wenn der Benutzer oder der Betreuer ihn nicht replizieren kann.

Wie würden Sie ihnen auch beweisen, dass der Fehler behoben ist, wenn Sie die Schritte nicht replizieren können?

Das Problem in Ihrem Fall ist, dass der Benutzer auch nicht weiß, wie der Fehler aufgetreten ist, dh auf welchem ​​Bildschirm, um welche Operation auszuführen. Sie haben einfach das Protokoll.

Ich denke, Ihr Standpunkt ist vernünftig. Wenn Sie psychische Kräfte hätten , würden Sie möglicherweise nicht für ein Gehalt arbeiten.

Ich denke, Sie sollten Ihren Vorgesetzten sagen, dass es eine unbekannte Zeit dauern würde, bis Sie den Fehler gefunden haben, ohne ihn reproduzieren zu können, und es gibt überhaupt keine Garantie dafür.

Das Problem wird sein, wenn ein Mitarbeiter von Ihnen den Fehler aus reinem Glück findet und ihn behebt.

Nehmen wir es auf das Äußerste und nehmen wir an, dass Sie den Fehler viel früher gefunden haben: in Ihrem Code, als Sie ihn geschrieben haben. Dann hätten Sie keine Bedenken, es genau dort zu reparieren - Sie sehen einen logischen Fehler im Code, den Sie gerade geschrieben haben, er tut nicht das, was Sie wollten. Sie würden nicht das Bedürfnis verspüren, eine ganze Umgebung einzurichten, um zu zeigen, dass es sich tatsächlich um einen Fehler handelt.

Jetzt kommt ein Fehlerbericht. Sie können verschiedene Dinge tun. Eine davon ist, zum Code zurückzukehren und ihn erneut zu lesen. Nehmen wir nun an, dass Sie bei dieser zweiten Lesung den Fehler sofort im Code finden - er tut einfach nicht das, was Sie beabsichtigt haben, und Sie haben es nicht bemerkt, als Sie ihn geschrieben haben. Und es erklärt perfekt den Fehler, der gerade reinkam! Sie machen das Update. Du hast zwanzig Minuten gebraucht.

Hat das den Fehler behoben, der den Fehlerbericht verursacht hat? Sie können sich nicht zu 100% sicher sein (es gab möglicherweise zwei Fehler, die dasselbe verursacht haben), aber wahrscheinlich hat es das getan.

Eine andere Möglichkeit besteht darin, die Konfiguration des Kunden so gut wie möglich zu reproduzieren (einige Arbeitstage) und den Fehler schließlich zu reproduzieren. In vielen Fällen gibt es Zeit- und Parallelitätsprobleme, die bedeuten, dass Sie den Fehler nicht reproduzieren können, aber Sie können viel Zeit versuchen und manchmal sehen, dass das Gleiche passiert. Jetzt beginnen Sie mit dem Debuggen, finden den Fehler im Code, stellen ihn in die Umgebung und versuchen es häufig erneut. Sie sehen den Fehler nicht mehr.

Hat das den Fehler behoben, der den Fehlerbericht verursacht hat? Sie können sich immer noch nicht hundertprozentig sicher sein - erstens haben Sie möglicherweise einen völlig anderen Fehler gesehen als der Kunde, zweitens haben Sie es möglicherweise nicht oft genug versucht, und drittens ist die Konfiguration möglicherweise immer noch ein wenig anders auf diesem System behoben, aber nicht die des Kunden.

Gewissheit ist also auf keinen Fall zu bekommen. Aber die erste Methode ist viel schneller (Sie können dem Kunden auch einen Patch schneller geben), ist viel billiger und, wenn Sie einen klaren Codierungsfehler finden, der das Symptom erklärt, ist es tatsächlich wahrscheinlicher, dass Sie das Problem auch finden.

Es kommt also darauf an. Wenn es billig ist, eine Testumgebung einzurichten (oder besser: ein automatisierter Test, der das Problem aufzeigt), dann tun Sie dies. Aber wenn es teuer ist und / oder die Umstände, unter denen der Fehler auftritt, nicht vorhersehbar sind, ist es immer besser, zuerst den Code zu lesen, um den Fehler zu finden.

Wenn ich die Frage lese, sehe ich keinen grundsätzlichen Widerspruch zwischen Ihrer Position und der Ihres Teams.

• Ja, Sie sollten sich nach besten Kräften bemühen, das in der Clienteinstellung auftretende Problem zu reproduzieren. Nach besten Kräften sollten Sie jedoch eine Zeitbox dafür definieren, und das Protokoll enthält möglicherweise nicht genügend Daten, um das Problem tatsächlich zu reproduzieren.

  Wenn ja, hängt alles von der Beziehung zu diesem Kunden ab. Es kann sein, dass Sie nichts anderes von ihm haben, um einen Entwickler mit Diagnosewerkzeugen und der Fähigkeit, sie auf dem fehlerhaften System auszuführen, vor Ort zu schicken. Normalerweise sind wir irgendwo dazwischen und wenn die anfänglichen Daten nicht ausreichen, gibt es Möglichkeiten, mehr zu bekommen.

• Ja, ein erfahrener Entwickler sollte in der Lage sein, den Code zu lesen und den Grund für das Problem wahrscheinlich anhand des Protokollinhalts zu ermitteln. In der Tat ist es oft möglich, einen Komponententest zu schreiben, bei dem das Problem auftritt, nachdem der Code sorgfältig gelesen wurde.

  Das erfolgreiche Verfassen solcher Komponententests ist fast so gut wie die Reproduktion der brechenden Funktionsumgebung. Natürlich ist diese Methode auch keine Garantie dafür, dass Sie etwas finden. Das Verständnis der genauen Abfolge von Ereignissen, die in einigen Multithread-Programmen zu Fehlern führen, kann sehr schwierig sein, wenn Sie nur den Code lesen. Die Fähigkeit, Live-Fehler zu beheben, wird wahrscheinlich kritisch.

Zusammenfassend würde ich für beide Ansätze gleichzeitig versuchen und nach einem Live-System fragen, das das Problem aufweist (und zeigt, dass es anschließend behoben wird), oder nach einem Test einer Unterbrechungseinheit, die das Problem unterbricht (und auch zeigt, dass es nach dem Beheben behoben wird).

Der Versuch, den Code einfach zu reparieren und in freier Wildbahn zu senden, sieht in der Tat sehr riskant aus. In einigen ähnlichen Fällen (in denen der Defekt intern nicht reproduziert werden konnte) habe ich klargestellt, dass der vorgeschlagene Mitarbeiter das Kundenproblem nicht gelöst hat, wenn ein Fix in die Luft ging oder andere unerwartete negative Konsequenzen hatte Es müsste dem Support-Team helfen, das eigentliche Problem zu finden. Einschließlich des Umgangs mit dem Kunden, falls erforderlich.

Klingt für mich nach einer detaillierteren Protokollierung.

Das Hinzufügen weiterer Protokolle kann zwar nicht garantieren, dass Sie keine Fehlerbehebung durchführen müssen (oder in diesem Fall die Situation reproduzieren müssen), gibt Ihnen jedoch einen weitaus besseren Einblick in das, was tatsächlich schief gelaufen ist.

Besonders in komplizierten / Threading-Situationen oder in Situationen, in denen Sie keinen Debugger verwenden können, kann das Zurückgreifen auf "debug by printf ()" Ihre einzige Möglichkeit sein. In diesem Fall sollten Sie so viel wie möglich protokollieren (mehr als Sie voraussichtlich benötigen) und ein paar gute Werkzeuge zum Filtern der Spreu vom Weizen haben.

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Da hat es noch niemand klar gesagt: Absolut nicht!

Wie alles in der Softwareentwicklung bedeutet Bugfixing, Zeit, Risiko und Kosten zu berücksichtigen. Ein Gleichgewicht zwischen diesen zu finden, ist die Hälfte der Aufgabenbeschreibung eines Entwicklers.

Einige Fehler sind nicht wichtig genug, um 2 Tage damit zu verbringen, aber wichtig genug, um 10 Minuten damit zu verbringen, sie zu beheben. Andere Fehler sind nicht deterministisch und Sie wissen bereits, dass eine Testumgebung nicht nachweisen kann, dass sie behoben wurden. Wenn das Einrichten der Testumgebung 2 Tage dauert, tun Sie dies bei diesen Fehlern nicht. Stattdessen verbringen Sie die Zeit mit intelligenteren Dingen, z. B. der Suche nach Möglichkeiten zum Einrichten einer Testumgebung in 5 Minuten anstelle von 2 Tagen.

Und natürlich gibt es Fehler, bei denen ein Kunde über 100'000 $ verliert, wenn er sie falsch versteht. Und Fehler, bei denen der Kunde für jede Stunde, in der der Fehler nicht behoben ist, mehr als 100.000 US-Dollar verliert. Sie müssen sich den Fehler ansehen und eine Entscheidung treffen. Pauschalaussagen, um alle Fehler gleich zu behandeln, funktionieren nicht.

Sehr gute Frage! Wenn Sie das Problem nicht reproduzieren können, können Sie meiner Meinung nach nicht zu 100% sicher sagen, dass die von Ihnen vorgenommene Fehlerbehebung nicht zu Folgendem führt:

a) Beheben Sie das Problem tatsächlich. b) Erstellen Sie einen weiteren Fehler

Es gibt Zeiten, in denen ein Fehler auftritt und ich ihn behebe und mich nicht darum kümmere, ihn zu testen. Ich weiß zu 100%, dass es funktioniert. Aber bis unsere QA-Abteilung sagt, dass es funktioniert, halte ich es immer noch für möglich, dass noch ein Fehler vorliegt ... oder ein neuer Fehler, der aus dem Fix erstellt wurde.

Wenn Sie den Fehler nicht reproduzieren und dann die neue Version installieren und bestätigen können, dass er behoben ist, können Sie nicht mit 100% iger Sicherheit sagen, dass der Fehler behoben ist.

Ich habe ein paar Minuten lang versucht, mir eine Analogie auszudenken, mit der Sie anderen erklären können, aber mir ist nichts eingefallen. Eine Vasektomie ist ein lustiges Beispiel, aber es ist nicht die gleiche Situation :-)

[Fehler in Bezug auf] gleichzeitiger Datenbankzugriff, Cluster-Implementierung, Multithreading

Ist es sinnvoll, darauf zu bestehen, dass jeder Fehler reproduziert und behoben wird, bevor er diagnostiziert und behoben wird?

Ich würde nicht zu viel Zeit damit verbringen, es zu reproduzieren. Dies scheint ein Synchronisationsproblem zu sein, und diese werden häufiger durch Überlegungen (ausgehend von Protokollen wie dem, in dem Sie das Subsystem bestimmen müssen, in dem das Problem auftritt) als durch die Möglichkeit, es zu reproduzieren und mit einem Debugger anzugreifen, gefunden . Nach meiner Erfahrung kann es ausreichen, die Optimierungsstufe des Codes zu reduzieren oder manchmal zusätzliche Instrumente zu aktivieren, um eine ausreichende Verzögerung oder das fehlende Synchronisationsprimitiv hinzuzufügen, um zu verhindern, dass sich der Fehler manifestiert.

Ja, wenn Sie keine Möglichkeit haben, den Fehler zu reproduzieren, können Sie nicht sicher sein, dass Sie ihn beheben. Wenn Ihr Kunde Ihnen jedoch nicht die Möglichkeit gibt, diese zu reproduzieren, suchen Sie möglicherweise nach etwas Ähnlichem mit der gleichen Konsequenz, aber einer anderen Ursache.

Beide Aktivitäten (Codeüberprüfung und Testen) sind notwendig, beide reichen nicht aus.

Sie könnten Monate damit verbringen, Experimente zu erstellen, um den Fehler zu korrigieren, und kommen nie weiter, wenn Sie sich den Code nicht ansehen und eine Hypothese aufstellen, um den Suchraum einzugrenzen. Sie könnten monatelang in Ihren Nabel blicken und versuchen, einen Fehler im Code zu visualisieren. Sie könnten sogar denken, Sie hätten ihn einmal, zweimal, dreimal gefunden, nur um den immer ungeduldiger werdenden Kunden sagen zu lassen: "Nein, der Fehler ist immer noch da. "

Einige Entwickler sind in einer Aktivität (Codeüberprüfung im Vergleich zum Erstellen von Tests) relativ besser als in der anderen. Ein perfekter Manager wägt diese Stärken beim Zuweisen von Fehlern ab. Ein Teamansatz kann sogar noch fruchtbarer sein.

Letztendlich sind möglicherweise nicht genügend Informationen vorhanden, um den Fehler erneut zu beheben, und Sie müssen eine Weile warten, bis ein anderer Kunde ein ähnliches Problem feststellt, sodass Sie einen besseren Einblick in das Konfigurationsproblem erhalten. Wenn der Kunde, der den Fehler gesehen hat, wirklich möchte, dass er ihn behebt, wird er mit Ihnen zusammenarbeiten, um weitere Informationen zu sammeln. Wenn dieses Problem nur einmal aufgetreten ist, ist es wahrscheinlich kein Fehler mit hoher Priorität, auch wenn der Kunde wichtig ist. Manchmal ist es klüger, einen Fehler nicht zu beheben, als stundenlang nach einem wirklich undurchsichtigen Defekt mit nicht genügend Informationen zu suchen.