既存のコードのバグを修正しているとき、コードの中にある「間違い」を見つけて、その間違いを避けるためにコードを調整するという習慣に陥りがちです。しかし、問題の根本原因が設計ミスやアルゴリズムの問題であった場合、コードに別のフラグやgoto文を追加するだけでは、間違ったアプローチになってしまいます。根本的な原因をそのままにしただけでなく、それを理解しなければならない次のソフトウェアエンジニアにとって、コードを理解しにくくしてしまったのです。
"もし自分が元のコーダーだったら、この問題をどうやって解決しただろうか？"と自問自答する訓練をしましょう。そして、「きれいな紙一重」のアプローチと、実際に目の前にあるものとの違いを見てみましょう。しかし、現実的であること。私は確かに、あなたと作者のアプローチが違うからといって、関数を再実装すべきだと提案しているわけではありません。思考実験として、このステップを実行してください。あなたは失敗したテストケースを持っています。著者はこのケースを見逃しました。何が彼女をこのケースを見逃したのでしょうか?著者がこのケースを知っていたら、彼女のアプローチはどのように違っていたでしょうか?このようなタイプの質問は、基本的には動作するが、まだいくつかのバグがあるコードを掘り下げる際に非常に貴重なものです。
私たちの場合、内部関数に別のパラメータを追加し、メインプロシージャに3つの異なる入口ポイントで正しく初期化されなければならない別の自動変数を追加し、重要なポイントでこの新しい変数をテストするコードを追加する代わりに、サブステップが実行される順序を変更することでアルゴリズムを修復できることに気付きました。一度それを実行すると、追加の変数や特殊なケースの必要性がなくなりました。最終的なコードは、修復の最初の試みは言うまでもなく、オリジナルのコードよりも理解しやすくなっています。これで、私たちは正しい道を歩んでいるという確信が持てました。問題を再現したテストケースでは、オリジナルの（複雑すぎる）修正と修正された（単純化された）修正の両方が問題を解決していることが証明されました。あとは、他に何も壊していないことを確認するだけです。
この修正はフィールドリリース(つまり、顧客の場所に既にインストールされているもの)に向けられているので、3種類の集中的なリグレッションテストも実行する予定です。そのうちの二つは POSIX 標準に継続的に準拠しているかどうかをチェックし（バグフィックスは POSIX 関数を実装したコードにあります）、三つ目のタイプのテストは一般的なシステムレベルのリグレッションテストです。
まずアルゴリズムを修正してください。アルゴリズムを修正したら、コードを処理します。