Wenn Sie Fehler in bestehendem Code beheben, kann man leicht in die Gewohnheit verfallen, den „Fehler“ im Code zu suchen und den Code anzupassen, um diesen Fehler zu vermeiden. Wenn die Ursache des Problems jedoch ein Designfehler oder ein Problem mit dem Algorithmus war, ist es falsch, einfach nur ein weiteres Flag oder eine Goto-Anweisung in den Code einzufügen. Damit haben Sie nicht nur die Ursache des Problems unberührt gelassen, sondern den Code für den nächsten Softwareentwickler, der ihn verstehen muss, noch schwerer verständlich gemacht.
Trainieren Sie sich darin, sich zu fragen: „Wie hätte ich dieses Problem gelöst, wenn ich der ursprüngliche Programmierer wäre?“ Betrachten Sie dann den Unterschied zwischen dem „unbeschriebenen Blatt“-Ansatz und dem, was tatsächlich vor Ihnen liegt. Aber bleiben Sie pragmatisch. Ich schlage keineswegs vor, dass Sie eine Funktion neu implementieren sollten, nur weil Sie und der Autor unterschiedliche Ansätze verfolgen. Betrachten Sie diesen Schritt als Gedankenexperiment. Sie haben einen Testfall, der fehlschlägt. Der Autor hat diesen Fall übersehen. Was hat ihn dazu veranlasst, diesen Fall zu übersehen? Wenn der Autor von diesem Fall gewusst hätte, wie hätte sich sein Ansatz dann unterschieden? Diese Art von Fragen sind von unschätzbarem Wert, wenn man sich mit Code befasst, der im Grunde genommen funktioniert, aber dennoch einige Fehler aufweist.
In unserem Fall habe ich erkannt, dass wir den Algorithmus reparieren können, indem wir die Reihenfolge ändern, in der die Teilschritte ausgeführt werden, anstatt einen weiteren Parameter zu einer internen Funktion hinzuzufügen, eine weitere automatische Variable, die an drei verschiedenen Einstiegspunkten in die Hauptprozedur korrekt initialisiert werden musste, und Code zum Testen dieser neuen Variable an einem kritischen Punkt hinzuzufügen. Nachdem wir das getan hatten, waren keine zusätzlichen Variablen und Sonderfälle mehr erforderlich. 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 gezeigt, dass sowohl die ursprüngliche (übermäßig komplexe) als auch die überarbeitete (vereinfachte) Korrektur das Problem lösen. Jetzt müssen wir nur noch sicherstellen, dass wir nichts anderes kaputt gemacht haben.
Da diese Korrektur für eine Feldfreigabe vorgesehen ist (d. h. eine, die bereits bei Kunden installiert ist), werden wir außerdem drei Arten von intensiven Regressionstests durchführen. Zwei davon überprüfen die fortgesetzte Einhaltung des POSIX-Standards (die Fehlerbehebung befindet sich im Code, der eine POSIX-Funktion implementiert), und die dritte Art von Test ist ein allgemeiner Regressionstest auf Systemebene.
Behebe zuerst den Algorithmus. Sobald der Algorithmus korrekt ist, kümmere dich um den Code.