プログラミングのバグを修正するための 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』の中で、「バグによって多大な時間がかかる場合は、その理由を調べなければならない」と指摘しています。さらに、将来同じような問題に遭遇しないように、経験や教訓からどのように学ぶかを考える必要もあります。また、使用する方法やツールに改善できる点はあるでしょうか?これらのバグの影響と深刻度。

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

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

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

発見/修復 修理時間<=5日 修理時間>5日

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

再現するのは難しいか不可能 5.9% 3.2%

それで賭ければ、バグはすぐに修正されます, そしてほとんどの場合、あなたは正しいです。しかし、賭けに負けたときは、ふふ、それはあなたが窮地に陥っていることを意味します。

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

LAMP BrothersオリジナルPHPチュートリアルCD/『Essential PHP inDetails』を無料でプレゼント 詳細は公式サイトカスタマーサービスまでお問い合わせください: http://www.lampbrother.net

PHPCMS二次開発 http://yun.itxdl.cn/online/phpcms/index.php?u=5

WeChat開発

モバイルインターネットサーバーサイド開発 http:// yun.itxdl.cn/online/server/index.php?u=5

Javascriptコース http://yun.itxdl.cn/online/js/index.php?u=5

CTOトレーニングキャンプ 5