Beheben andere Leute Fehler, wenn sie sie sehen, oder warten sie, bis es zu Abstürzen / Datenverlust / zum Tod kommt, bevor sie sie beheben?
Beispiel 1
Customer customer = null;
...
customer.Save();
Der Code ist eindeutig falsch und es führt kein Weg daran vorbei - er ruft eine Methode für eine Nullreferenz auf. Es kommt nicht zum Absturz, weil Saveauf keine Instanzdaten zugegriffen wird. Es ist also so, als würde man eine statische Funktion aufrufen. Aber jede kleine Änderung an einem beliebigen Ort kann plötzlich zu einem fehlerhaften Code führen, der nicht abstürzt.
Es ist aber auch nicht unvorstellbar, dass der Code korrigiert wird:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
könnte einen Absturz einführen ; man nicht durch Unit-Tests mit vollständiger Abdeckung und manuelle Benutzertests entdeckt.
Beispiel 2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
Leute, die sich mit Physik auskennen, werden erkennen, dass es sich um R 2 im Nenner handelt.
Der Code ist falsch, es ist absolut falsch. Und wenn Sie die Geschwindigkeit überschätzen, werden die Retro-Raketen zu früh abgefeuert und alle Insassen des Raumfahrzeugs getötet.
Es ist aber auch möglich, dass die Geschwindigkeit überschätzt wird, was ein anderes Problem überdeckt: Die Airbags können nicht ausgelöst werden, während sich das Shuttle zu schnell bewegt. Wenn wir den Code plötzlich reparieren:
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
Jetzt ist die Geschwindigkeit genau und plötzlich werden Airbags ausgelöst, wenn sie nicht sollten.
Beispiel 3
Hier ist ein Beispiel, das ich kürzlich hatte, um zu überprüfen, ob eine Zeichenfolge ungültige Zeichen enthält:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
Was ist, wenn sich herausstellt, dass es einen Fehler in der Do somethingBranche gibt? Behebung des offensichtlich falschen Codes:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Behebt den Code, führt aber einen Fehler ein.
Aus meiner Sicht gibt es zwei Möglichkeiten:
- Korrigieren Sie den Code und lassen Sie sich beschuldigen, ihn gebrochen zu haben
- Warten Sie, bis der Code abstürzt, und erhalten Sie die Schuld für einen Fehler
Was machst du politisch?
Beispiel 4 - Heutiger Fehler in der realen Welt
Ich konstruiere ein Objekt, rufe aber den falschen Konstruktor auf:
Customer customer = new Customer();
Es stellt sich heraus, dass der "parameterlose" Konstruktor tatsächlich ein parametrisierter Konstruktor von weiter hinten in der Vererbungskette ist:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
Das Aufrufen ist ein Fehler, da alle nachfolgenden Konstruktoren umgangen werden.
Ich könnte die Herkunft des Objekts ändern, um einen so gefährlichen Konstruktor nicht zu entlarven, aber jetzt muss ich den Code ändern in:
Customer customer = new Customer(depends);
Aber ich kann nicht garantieren, dass diese Änderung nichts kaputt macht. Wie mein Beispiel 1 oben, hängt vielleicht jemand, irgendwo, irgendwie, unter bestimmten esoterischen Bedingungen, davon ab, ob das Konstrukt Customerungültig und voll von Müll ist.
Vielleicht ermöglicht das CustomerObjekt, das jetzt ordnungsgemäß erstellt wurde , das Ausführen von Code, der zuvor noch nie ausgeführt wurde, und jetzt kann es zu einem Absturz kommen.
Ich kann das Leben Ihrer Frau nicht darauf wetten.
Und ich kann es von hier bis Dienstag testen. Ich kann nicht schwören, dass ich keine Regression eingeführt habe.
Mache ich:
- Den Code reparieren und beschuldigt werden, ihn gebrochen zu haben? oder
- Den Bug verlassen und beschuldigt werden, wenn der Kunde ihn findet?
quelle
Antworten:
Dies hängt stark von der Situation, dem Fehler, dem Kunden und dem Unternehmen ab. Es gibt immer einen Kompromiss zwischen der Korrektur der Implementierung und der möglichen Einführung neuer Fehler.
Wenn ich eine allgemeine Richtlinie für die Festlegung der zu treffenden Maßnahmen geben würde, würde dies meiner Meinung nach in etwa so aussehen:
Dies gilt allerdings nur, wenn Sie kurz vor einer Veröffentlichung stehen. Wenn Sie sich im vollständigen Entwicklungsmodus befinden, protokolliere ich den Fehler einfach, damit er nachverfolgt, behoben und als erledigt bezeichnet werden kann. Wenn das Reparieren und Überprüfen länger als beispielsweise eine halbe Stunde dauert, gehe ich zum Manager / Teamleiter und überprüfe, ob der Fehler in den aktuellen Release-Zyklus passt oder für einen späteren Zeitpunkt geplant ist.
quelle
Kunden werden IMMER Fehler finden . Es gibt keine versteckten Fehler vor Kunden. Am Ende werden die von Ihnen eingeführten Bugs immer wieder auf Sie zurückkommen. Sie nicht zu reparieren ist einfach eine schlechte professionelle Praxis. Profis machen das nicht.
Wenn Kunden Fehler finden, sieht das Unternehmen schlecht aus und kein einzelner Entwickler. Das ist viel schlimmer für das Unternehmen, also ist es Ihre Sache, die Änderung vorzunehmen. Wenn Sie sich wirklich nicht sicher sind, ob Sie diese Änderung vornehmen können, weil Sie andere Fehler befürchten, sprechen Sie mit einem erfahreneren Entwickler, einem technischen Projektleiter oder einem anderen Mitarbeiter, der in der Lage ist, eine Entscheidung über eine solche Änderung zu treffen und anschließend die Konsequenzen zu bewältigen.
quelle
Beheben Sie den Fehler
Wir sind Profis hier. Wenn Sie im Code einen fehlerhaften Pfad finden, der einen Absturz oder ein falsches Verhalten verursacht, müssen Sie ihn beheben. Abhängig von den Vorgehensweisen Ihres Teams müssen Sie wahrscheinlich einen Defekt einreichen, möglicherweise einen Regressionstest schreiben und den Fix zum richtigen Zeitpunkt des Schiffszyklus einchecken. Wenn es sich um einen Fehler mit niedriger Priorität handelt, ist das Einchecken des Fixes am Anfang eines Meilensteins immer eine gute Zeit, da Sie den Veröffentlichungszyklus des Meilensteins nicht beeinflussen, wenn Sie eine Regression verursachen.
Verwechseln Sie dies nicht mit Umgestaltungen oder Leistungsverbesserungen, die nicht mit einem Leistungsfehler zusammenhängen.
Ein verteiltes Versionsverwaltungssystem, in dem Sie ein separates Repository mit 'kleinen Fehlerkorrekturen' aufbewahren und dann zu Beginn eines Meilensteins problemlos zusammenführen können, ist hier eine große Hilfe.
quelle
Was würde der Kunde sagen?
So stelle ich mir das vor:
Ja. Beheben Sie den Fehler. Sie ersparen dem Kunden ein erschwerendes Erlebnis und müssen es beheben, bevor es zum Notfall wird.
Und wenn Sie glauben, dass Ihr Fix tatsächlich zu einem Absturz führen könnte, haben Sie noch keinen Fix gefunden.
quelle
Alle Beispiele, die Sie angegeben haben, scheinen einen gemeinsamen Thread zu haben. Sie scheinen einen Fehler beheben zu wollen, den Sie nicht vollständig verstehen. Ich sage das, weil Sie die Möglichkeit unbeabsichtigter Konsequenzen für jeden einzelnen zur Kenntnis nehmen.
Ich würde sagen, es ist wahrscheinlich ein großer Fehler, und während Ben Laurie schreibt , behebe keinen Fehler, den du nicht verstehst . In diesem berühmten Beispiel hat das Debian-Team die Verschlüsselung für OpenSSL für Debian und Derivate wie Ubuntu gebrochen, als sie die Ergebnisse eines Analyse-Tools verfolgten.
Wenn Sie glauben, dass ein Fehler vorliegt, überprüfen Sie anhand des Codes, ob Sie den Fehler auf eine Weise reproduzieren können, die der Kunde sehen kann. Wenn Sie nicht in der Lage sind, Ihre Ressourcen für die Reparatur von etwas anderem aufzuwenden, warum nicht?
quelle
Beginnen Sie, Ihre technischen Schulden so schnell wie möglich abzubauen .
Ihre Beispiele sehen definitiv wie Legacy-Code aus , haben viele technische Schulden und ich spüre, dass es die Angst vor Veränderungen gibt (übrigens, dies ist keine Kritik oder ein Urteil). Ihr gesamtes Team muss anerkennen, dass Sie diese technische Schuld haben (damit Sie nicht allein dafür verantwortlich gemacht werden), und dann können Sie entscheiden, wie Sie damit umgehen.
Wenn in Beispiel 1
Save()nicht auf Instanzdaten zugegriffen wird, welche Kundendaten werden genau gespeichert? Beginnen Sie, das zu beheben und zu testen.In Beispiel 2 ist es einfach, den Geschwindigkeitsrechner mit Tests zu belegen und sicherzustellen, dass das Ergebnis in allen wichtigen Beispielen korrekt berechnet wird.
In Beispiel 3 besteht die Gefahr, dass toter Code wieder zum Leben erweckt wird. Sollte dieser Code insgesamt beseitigt werden? Was ist die Absicht der Booleschen Bedingung, wenn? Soll sichergestellt werden, dass die Zeichenfolge keine ungültigen Zeichen enthält? Oder um sicherzustellen, dass es "PO BOX" enthält? Je früher Sie beginnen, solche Fragen zu beantworten, desto besser.
Nachdem Sie eine Reihe solcher Probleme behoben haben, führen Sie eine Art Retrospektive / Post-Mortem mit Ihrem Team durch. Es ist wichtig, aus den Erfahrungen zu lernen, damit Sie Ihre Defektinjektionsrate in Zukunft reduzieren können.
quelle
Sie haben bereits gute Antworten. Ich möchte nur etwas über das Problem hinzufügen, Angst zu haben, dass etwas abstürzt.
Erstens ist die Software im Idealfall modular aufgebaut, richtig aufgebaut und es besteht eine gute Trennung der Anliegen. In diesem Fall werden die von Ihnen vorgenommenen Änderungen höchstwahrscheinlich nichts kaputtmachen, da Sie die Kontrolle über den gesamten zugehörigen Code haben und es keine versteckten Überraschungen gibt.
Leider ist die ideale Situation fiktiv. Unabhängig davon, inwieweit die Kupplung locker ist, kommt es zu einer Kupplung und damit zu einem Bruch von etwas anderem.
Die Lösung hierfür ist zweifach:
Um den Code gut zu strukturieren, muss nicht der gesamte Code auf ein neues Architekturdesign umgeschrieben werden. Das von Tests geleitete Refactoring ist hier Ihr Freund. In diesem Schritt ändern Sie die Funktionalität nicht.
Der zweite Schritt ist, dass Sie den Fehler beheben.
Einige Punkte sind relevant:
Das sind schon mehr als ein paar Punkte, also werde ich hier wohl aufhören.
quelle
Sie müssen zuerst die Definition eines Fehlers berücksichtigen:
Sie scheinen sich auf # 1 zu konzentrieren, wo # 2 der beste Platz zum Sitzen ist. Sicher, wir Programmierer möchten, dass unser Code stimmt (Nr. 1), aber die Leute bezahlen uns dafür, dass er funktioniert (Nr. 2).
Was Sie möglicherweise mit der Codebasis machen oder nicht, das könnte versehentlich neue Fehler hervorrufen, ist für die Ansicht von Nummer 2 der aktuellen Software irrelevant. Die Nummer 1 ist jedoch für Sie selbst oder den nachfolgenden Wartungsprogrammierer von Bedeutung. Es ist manchmal schwierig, sich zu entscheiden, aber wenn es zu Konflikten zwischen # 2 und # 1 kommt, muss man wissen, dass # 2 eindeutig wichtiger ist.
quelle
Weder. Es gibt einen dritten Weg: Finden Sie einen Weg, um zu beweisen, dass "der problematische Code" tatsächlich Probleme aus geschäftlicher Sicht verursacht. Bestätigen Sie, was Sie mit BA / QA oder mindestens Ihrem Manager finden. Planen Sie dann den Fix, wenn allen das Problem bekannt ist.
In den von Ihnen genannten Fällen gibt es mehr mögliche Szenarien als einen gültigen Fehler:
Wenn ich ein Manager bin, möchte ich auf keinen Fall, dass ein Entwickler sein Urteilsvermögen einsetzt und den "Fehler" behoben. Das Beheben des Fehlers kann in den meisten Fällen Abhilfe schaffen, aber wenn ein Fehler auftritt, kann dies mehr Probleme verursachen als die guten Absichten.
quelle
Sie beheben den Fehler und starten die Komponententests und checken Ihren Fix ein, wenn sie erfolgreich sind.
(Wenn Ihre Komponententests sehr lange dauern, überprüfen Sie zuerst Ihren Fix und warten dann, ob Ihr CI-Tool Ihnen eine E-Mail sendet, weil Ihr Commit etwas gebrochen hat.)
quelle
Beheben Sie sie, wenn es sich um Absturz- / Datenverlust-Fehler handelt. Das Versenden eines Programms mit einem bekannten Datenverlust-Fehler ist ausgesprochen böswillig und unentschuldbar.
Wenn der Fehler kosmetisch oder nicht kritisch ist (vermieden werden kann), sollte er dokumentiert und eine Problemumgehung bereitgestellt werden. Idealerweise sollte es repariert werden, aber manchmal ist es zu teuer, es für die aktuelle Version zu reparieren.
Beachten Sie, dass jedes größere Softwareprojekt in der ReadMe-Datei den Abschnitt „Bekannte Probleme“ enthält, in dem normalerweise genau Folgendes aufgeführt ist: Bekannte Fehler.
Bugs zu kennen und NICHT mitzuteilen ist meiner Meinung nach nur für wirklich kleinere / kosmetische Bugs akzeptabel.
quelle
Repariere es und lass es testen. Wenn Sie sich entscheiden, bekannte Fehler beizubehalten, nur weil Sie Angst haben, mehr Fehler zu finden, wird Ihr Programm zu einem Minenfeld von tickenden Zeitbomben, die so schnell sind, dass sie schneller nicht mehr reparabel sind, als Sie denken.
Da Sie der Master und der Code der Untergebene sind, haben Sie möglicherweise keine Angst, ihn zu ändern, wenn Sie sehen, dass er falsch ist. Die Angst vor dem Code ("es könnte sich rächen, wenn es woanders kaputt geht") ist einfach inakzeptabel.
quelle
Wenn es eindeutig einen Crasher gibt oder etwas nicht stimmt , sollten Sie ihn beheben. Wenn die Spezifikation mehrdeutig ist, dh wenn Sie der Meinung sind, dass "der Kunde dies gut erwartet", wird dies möglicherweise der Fall sein ein Fehler sein“ oder ein Problem in der Spezifikation, wie „wir haben gefragt , dies zu tun aber es ist scheiße "dann musst du herausfinden, was zu tun ist. Es ist schlecht, den Code über die Wand zu werfen und auf Kundenfeedback zu warten. Möglicherweise fragen Sie einen Produktmanager, ob Sie einen haben, oder fragen Sie den Kunden, bevor Sie das Produkt bereitstellen.
Denken Sie daran: "Wir kennen dieses Problem und werden es in einer zukünftigen Version beheben" ist gleichbedeutend mit "Wir kennen dieses Problem, aber kümmern uns nicht genug um Sie, um zu vermeiden, dass Sie sich damit befassen".
quelle
Die richtige Vorgehensweise besteht weder darin, den Fehler zu ignorieren, noch ihn vor Ort zu "reparieren". aus genau den Gründen, die Sie in Ihrer Frage identifiziert haben.
Ich denke, Sie sollten zuerst versuchen, den Code zu verstehen . Wenn der Code, den Sie sehen, in einem gewissen Alter ist und noch niemand den "Bug" bemerkt hat, gibt es wahrscheinlich einen Grund dafür. Versuchen Sie diesen Grund zu finden. Folgendes möchte ich mir ansehen, bevor ich eine Entscheidung treffe:
Verlauf : Beantworten Sie die Fragen mit Ihrer Versionskontrollsoftware: Wer hat den Code berührt? Was haben sie geändert? Und mit welchen Commit-Nachrichten haben sie es eingecheckt? Können Sie einen Grund ableiten, warum der Code so aussieht?
Verwendung : Welcher Code verwendet den fehlerhaften Code? Und wie? Ist der Code tot? Gibt es einen anderen Code, der auf dem fehlerhaften Verhalten beruht?
Autor : Wenn Sie mit den obigen Informationen nicht schnell zu einer Schlussfolgerung gelangen können, fragen Sie den Autor des Codes (zumindest, wenn dies möglich ist), warum der Code so aussieht, wie er aussieht. Normalerweise bekommst du entweder ein "Oups, das sollte behoben sein!" oder ein "Nein! Verändere es nicht !!! Es wird so gebraucht!" jetzt sofort.
quelle