バグのクラスを修正することを目的とする

バグを修正すると気分が良くなることがあります。 むしろ、自分が事態を悪化させてしまったような気がします。 バグを修正すると、コードが少し読みにくくなり、理解するのが少し難しくなることがよくあります。 さらに悪いことに、バグを修正すると、誤ってさらに多くのバグが発生する可能性があります。
ほとんどの場合、バグはプログラマがプログラムの実行時の動作をすべて想定できないために発生します。 これらの未処理の動作は、エッジ ケースと呼ばれることがあります。 通常、エッジケースには簡単な方法で簡単に対処できます。 if ステートメント: このケースに遭遇したら、別のことをしてください。 ただし、そうすると、読者は頭の中で複数のコード パスを視覚化する必要があるため、プログラムを理解することがさらに難しくなる可能性があります。 複数のエッジケースが積み重なると事態はさらに悪化します if 発言。 関連するコードをリファクタリングするときは、これらの ifリファクタリングを実行する必要があるため、回帰の可能性が高くなります。
積み重なっていることに気づいたとき if バグを修正するためのステートメントを作成する際、プログラムをさらに理解しにくくすることなく、またさらなるバグを引き起こす可能性もなく、問題に対処するより良い方法はないかと自問します。 存在する場合は、通常、データのモデル化と処理方法のリファクタリングが必要になります。 以下はそのときの一つの回想です。
Rescale では、ユーザーはクラウドでデスクトップ インスタンスを起動できます。 これらのデスクトップは、 not_started, starting, running, stoppingまたは stopped 州。 デスクトップとその最新の既知の状態は、デスクトップをユーザーに表示するときにポーリングした API エンドポイントから返されます。
デスクトップのローカル UI 状態に関するバグがありました。 デスクトップの状態は楽観的に次のように設定されます。 stopping ユーザーがデスクトップの停止を要求したとき。 これは、デスクトップを停止するタスクをキューに入れるメッセージを送信する停止要求が成功したかどうかに関係なく設定されるため、楽観的です。
ユーザーがデスクトップのリストを再度リクエストすると、API が返すまでの時間枠がありました。 running デスクトップを停止するタスクがまだキューに入れられており、まだ実行されていないため、停止を要求されたばかりのデスクトップの場合。 UI は最新のステータスで更新され、ユーザーはデスクトップが元の状態になったことを確認します。 stopping 〜へ running。 最終的に停止タスクが実行されると、ユーザーには次の状態からの移行が表示されます。 running 〜へ stopping。 見る stopping その後 running その後 stopping これはユーザーにとって不快な体験となるため、これを修正する必要がありました。
これを修正するアプローチは、デスクトップが次の場所にあるかどうかを確認することです。 stopping 状態をローカルに変更し、その場合はステータスの更新をスキップします。 running。 これが「山積み」です。 if ステートメント」アプローチ。
代わりに、デスクトップごとに一連のステータスを保持することにしました。 その後、デスクトップのリスト API 応答が返されるたびに、各デスクトップの最新のステータスをそれぞれのステータス セットに追加します。 一連のステータスを取得し、ユーザーに適切なステータスを表示する関数があります。 たとえば、次の場合 running & stopping がセット内にある場合は、表示されるだけです stoppingただし、この関数には処理ルールもあります。 starting & running.
これにより、表示されるステータスはステータス セットの内容に純粋に依存し、ステータスが到着した順序には依存しないため、ステータスが到着する順序は問題ではなくなりました。 つまり、見ることができなくなった stoppingをタップし、その後、 running、次に戻る stopping.
これの素晴らしい点は、私が忘れていた同様の問題が修正されたことです。ユーザーがデスクトップを起動すると、UI はデスクトップが次の場所にあることを楽観的に示します。 starting 状態ですが、次の API 呼び出しでは次のように応答する可能性があります。 not_startedとなり、ユーザーはデスクトップが次の場所に移動したことがわかります。 starting 〜へ not_started、そして最終的には元に戻ります starting。 この問題は事実上無料で修正されました。
結論として、バグを修正する任務を負った場合、最初は単純な解決策で問題ないように見えますが、その解決策が将来的にさらに複雑になるかどうかを考慮する必要があります。 たとえば、前の例では、単純な方法で両方のケースを解決できたはずです。 if 発言。 ただし、ステータスが次から変更されることに問題があった場合は、 stopped 〜へ stopping、その後、別のプログラマが別のプログラマを積み重ねることを奨励される可能性があります。 if 声明。 場合によっては、バグだけでなく、問題が表す一連のバグの解決についてもう少し時間をかけて考える価値があります。