バグを修正するための 12 の重要な手順

上司: それで、このバグを修正するのにどれくらい時間がかかりますか?

経験の浅いプログラマー: 1 時間ほどいただけますか?せいぜい２時間くらいでしょうか？すぐにできるよ！

経験豊富なプログラマー: こう言ってみませんか、魚を捕まえるのにかかる時間と同じくらい時間がかかりますか? ！

バグの修正にどれくらいの時間がかかるかを事前に知るのは難しく、特にコードに慣れていない場合、状況はさらに混乱するでしょう。 James Shore は、著書「The Art of Agile」の中で、問題を解決したい場合は、まず問題が何であるかを知る必要があると明確に指摘しています。時間を正確に見積もることができない理由は、核心を見つけるのにどれくらいの時間がかかるかがわからないためです。これを知ることによってのみ、バグの修正にかかる時間を合理的に見積もることができます。しかし、この時期、ニッコウキスゲはもう寒いのではないかと思います。 Steve McConnell はかつてこう言いました:

「問題を見つける - 問題を理解する - これがプログラマーの仕事の 90% です

多くのバグはコードの特定の行を変更するだけで済みます。」しかし、多くの時間がかかるのは、何が正しいのかを後で理解する必要があることです。釣りをするときと同じように、どこに餌を置くか、いつ魚が餌を取りやすいかなどを知る必要があります。バグには 4 つのタイプがあると言われています。1 つ目は見つけやすく修正しやすいもの、2 つ目は見つけにくく修正しやすいもの、3 つ目は見つけやすく修正しにくいもの、4 つ目は見つけやすく修正しやすいものです。タイプは見つけるのが難しく、修正するのが困難です。最も悲劇的なのは最後のタイプで、「探しても探しても、荒れ果てて荒れ果てている」だけでなく、苦労の末にようやく石を突き破ったとしても、無意識のうちにそこを引っ掻くだけで、 「道は長い、長い」と力なくため息をつきます。リリースされたばかりのコードでない限り、バグを探すことは、目の見えない人が象を探しているようなものであると言えます。混乱して、どのバグのタイプに属しているのかわかりません。

バグの発見と修正

「バグの発見と修正」の意味を知っていますか?そうだ、デバッグだ！絶え間ないデバッグ、無数のデバッグ! Paul Butcher は広範な研究を通じて、次の構造化された手順を要約しました:

1. 目的を明確にする。例外レポートを注意深く確認してバグかどうかを判断し、さまざまな有益な情報を見つけて問題の核心を見つけて再現します。レポートとの重複がないか再度確認してください。重複が発生した場合は、関係者がどのように対処したかを確認してください。

2. 準備 - 正しいコードを見つけて、消去法で作業領域をクリーンアップします。

3. テスト環境に合わせます。お客様がコンピュータの設定を行っている場合は、このプロセスを省略できます。

4. コードの目的を明確にし、既存のテストツールですべてが適切に動作することを確認します。

5. さて、釣りに行きましょう - エラーを再現して診断します。再現できない場合は、修理作業を行ったことを証明できません。

6. テストケースを書くか、既製のテストケースを通じてバグをキャッチします。

7. 修復モードに入ります - 他の部分に影響を与えないことを確認してください。ただし、修正を開始する前に、リファクタリングを実行すると、恐れることなくコードをいじることができるため、リファクタリングを実行することをお勧めします。また、回帰後のテストにより、新しいバグが追加されないことを確認することもできます。

8. コードを整理します。段階的なリファクタリングにより、コードをより理解しやすく、より安全にします。

9. 他の人を見つけて検討してください。そうすれば当局は混乱し、傍観者は理解するでしょう。

10. この修復プロセスをもう一度確認してください。

11. これらのバグが他のブランチに影響を与えるかどうかを確認するために、メインラインから始めないようにしてください。これらの変更をマージし、コードの相違点を処理し、すべてのレビューとテストを確認します。

12. 考える。何がうまくいかなかったのか、そしてその理由をよく考えてください。なぜ修正が機能するのでしょうか?この種のバグは他にどこに現れるでしょうか?アンディ・ハント氏とデイブ・トーマス氏も、著書『The Pragmatic Programmer』の中で、「バグによって多大な時間がかかる場合は、必ずその理由を突き止めてください」と指摘しています。さらに、将来同じような問題に遭遇しないように、経験や教訓からどのように学ぶかを考える必要もあります。また、私たちが使用する方法やツールに改善できる点はあるでしょうか?これらのバグの影響と深刻度。

バグの発見と修正ではどちらの方が時間がかかりますか?

おそらく、テスト環境をセットアップし、問題を再現し、バグをテストするのに必要な時間は、バグを見つけてバグを修正する時間よりもはるかに長いでしょう。ただし、明らかなバグが少数であれば、見つけるのは簡単ですが、修正するのは理想的ではない可能性があります。

『ソフトウェアの作成』という本の中で、主に「ほとんどのソフトウェアの脆弱性の原因」について議論している章があり、ドウェイン・ペリーは、修復に比べてバグの発見（バグの理解とバグの再現を含む）にかかる時間が長いと分析しました。調査によると、ほとんどのバグ (ほぼ 3/4) は見つけやすく、修正も簡単であることが示されています。所要時間は 5 日以内です (これは、強力な SDLC、広範なレビューとテストによる大規模なリアルタイム システムに基づいています)。しかし、たとえ簡単に捕まえることができたとしても、それを修正するのに苦労する必要がある非常に不快なバグもあります。

発見/修復 修理時間5日

問題を再現できる 72.5% 18.4%

再現が難しいまたは不可能 5.9% 3.2%

つまり、あなたは間違いなくバグをすぐに修正し、ほとんどの場合あなたが正しいときは。しかし、賭けに負けたとき、それはあなたが大きな問題に直面していることを意味します。

それでは、次回、上司にいつバグが修正されるのかと尋ねられたら、愚かにも「すぐに修正されます」と答えないでください。