Bei der Behebung von Fehlern in bestehendem Code kann man sich leicht angewöhnen, den "Fehler" im Code zu finden und den Code anzupassen, um den Fehler zu vermeiden. Wenn aber die Ursache des Problems ein Designfehler oder ein Problem mit dem Algorithmus war, dann ist es der falsche Ansatz, einfach ein weiteres Flag oder eine goto-Anweisung in den Code einzufügen. Sie haben nicht nur die Ursache des Problems nicht beseitigt, sondern auch den Code für den nächsten Software-Ingenieur, der ihn entschlüsseln muss, schwerer verständlich gemacht.
Trainieren Sie sich zu fragen: "Wie hätte ich dieses Problem gelöst, wenn ich der ursprüngliche Programmierer gewesen wäre?" Betrachten Sie dann den Unterschied zwischen dem "sauberen Blatt Papier" und dem Ansatz, der tatsächlich vor Ihnen liegt. Aber seien Sie pragmatisch. Ich will keineswegs behaupten, dass Sie eine Funktion neu implementieren sollten, nur weil Sie und der Autor einen anderen Ansatz haben. Betrachten Sie diesen Schritt als ein Gedankenexperiment. Sie haben einen Testfall, der fehlschlägt. Der Autor hat diesen Fall übersehen. Was hat sie dazu veranlasst, diesen Fall zu übersehen? Wenn der Autor von diesem Fall gewusst hätte, wie wäre sein Ansatz anders gewesen? Diese Art von Fragen sind von unschätzbarem Wert, wenn man sich mit Code beschäftigt, der im Grunde genommen funktioniert, aber dennoch einige Fehler aufweist.
In unserem Fall wurde mir klar, dass wir den Algorithmus reparieren konnten, indem wir die Reihenfolge der Teilschritte änderten, anstatt einen weiteren Parameter zu einer internen Funktion hinzuzufügen und eine weitere automatische Variable hinzuzufügen, die an drei verschiedenen Eingangspunkten der Hauptprozedur korrekt initialisiert werden musste, und Code hinzuzufügen, um diese neue Variable an einem kritischen Punkt zu testen. Damit entfiel die Notwendigkeit zusätzlicher Variablen und Sonderfälle. Der endgültige Code ist tatsächlich viel leichter zu verstehen als der ursprüngliche Code, ganz zu schweigen vom ersten Reparaturversuch. Das gibt mir die Zuversicht, dass wir auf dem richtigen Weg sind. Der Testfall, der das Problem reproduziert, hat bewiesen, dass sowohl die ursprüngliche (übermäßig komplexe) Lösung als auch die überarbeitete (vereinfachte) Lösung das Problem lösen. Jetzt müssen wir nur noch sicher sein, dass wir nichts anderes kaputt gemacht haben.
Da diese Fehlerbehebung für ein Feldrelease bestimmt ist (d. h. eines, das bereits bei Kunden installiert ist), werden wir auch drei Arten von intensiven Regressionstests durchführen. Zwei davon werden die Einhaltung des POSIX-Standards überprüfen (die Fehlerbehebung befindet sich in einem Code, der eine POSIX-Funktion implementiert), und die dritte Art von Test ist ein allgemeiner Regressionstest auf Systemebene.
Korrigieren Sie zuerst den Algorithmus. Sobald der Algorithmus korrekt ist, können Sie sich mit dem Code befassen.
Unternehmen