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?