デバッグ：特定の修正が機能した理由の詳細を理解していますか？[閉まっている]

デバッグ時に、いくつかの変更を行うことがありますが、これらの変更がプログラムのバグを修正する理由が100％わかりません。いくつかのバグが発生した理由と、特定の変更がそれらのバグを排除した理由について、すべての詳細を理解することが不可欠ですか？それとも、修正がなぜ機能したのかについての詳細を実際に知らずにプログラムを動作させることが開発者の間で一般的ですか？

私はいくつかのバグが発生し、なぜ特定の変更は、これらのバグを排除した理由についてひとつひとつの詳細を理解することが不可欠であることを言うだろう、と本当に修正が働いていた理由の詳細を知らなくても作業プログラムを取得し、それは時々に開発者の間でも一般的です！

バグが消えるまで物事を変える技術は、それを引き起こした原因や変更が修正された理由を理解せずに、「ブードゥープログラミング」と呼ばれることが多く、aめ言葉ではありません。原因を理解していない場合、調査している特定のケースで部分的に修正するのではなく、バグを本当に修正したと確信できる方法は実際にはありません。

最悪の場合、バグを移動する以外は何もしていません：初年度のuniでのコンピューティングでは、多くの学生が初めてCとポインターを学習していたので、物事を変更するとポインターバグが現れなくなることがよくありますこれは、ポインタのバグがメモリの別のビットを踏みつけるのに十分な変更がメモリ内のデータ構造を再配置するためです。明らかに役立っていないことをまったく。

しかし、そうは言っても、プログラミングの商業的現実は、バグを修正するというクライアントを満足させることが、自分自身を満足させるよりも重要であることが多いということです。何が原因なのかわからない場合は、修正済みのものを宣言することはお勧めしませんが、コードに問題があることがわかり、それを修正した場合は、それが特定の原因を「100％確信できない」場合でもバグを明らかにするために、時々、クライアントがあなたの遅い進行について大声で叫ぶ前に、次のバグに移らなければならないことがあります。

バグを修正するのに時間がかかりすぎることにクライアントが怒っていると思うなら、あなたが主張したバグが修正されたと主張するバグ、または何かを悪化させる何かの修正について彼らがどれほど怒っているか想像してみてください。修正が回避策または軽減策に過ぎない場合、顧客は通常、それを歓迎しますが、それが何であるかについて正直であり、実際に修正するために必要なだけログを記録する必要があります。

修正したことが確かであるが、修正が機能する理由がわからない場合は、誰かに尋ねてください。私が知っているほとんどのエンジニアは、その背後にある謎のために、そのような質問をするのが大好きです。

バグがなくなるまでスタッフを変更することは一般的に悪い習慣ですが、残念ながら一部の人々にとっては現実です。

私は、それが何をするのか、なぜそれを行うのかを理解していないコードを書くべきではないという強い意見を持っています。修正する予定のバグを修正したにもかかわらず、他に何も破損していないことをどのようにして確認できますか？

一般に、問題/バグを修正する前に、根本的な原因の評価/分析を行って、問題が発生している理由と再現できるかどうかを判断する必要があります。次に、コードを読んで、コードがバグの原因となっている理由を理解する必要があります。その理解が得られたら、問題をどのように解決するかを検討し、変更が影響する他の領域を特定することができます。ここで単体テストが本当に役立ちます！

私は人々が問題を修正するために行ったコードの変更を数多く見てきましたが（これは素晴らしいことですが）、開発者は変更内容の完全な影響に気付いていなかったため、残念ながら他の問題を導入しました。これらの「修正」の多くは、元の問題の根本的な原因を曖昧にするだけでなく、複雑さやより多くのバグをもたらします。

そうは言っても、純粋に関連付けによってコードの多くの問題を修正しました。何かを変更/リワーク/リファクタリングし、他の未解決のバグを修正しました。もともと何が原因であるかはわかりませんが、危険なコードを見つけて「修正」しました。このような変更を単体テストと統合テストでカバーし、ビジネスの完全性と機能の技術的要件を確認します。

それとも、修正がなぜ機能したのかについての詳細を実際に知らずにプログラムを動作させることが開発者の間で一般的ですか？

それには少なくとも3つの大きな問題があります。

1. それはあなたがコードを理解できるという考えをあきらめ、代わりに問題がなくなることを期待して部品を動かし始める黒魔術の考え方につながります。これは、親があなたの野菜をもっと食べさせないように、夕食が十分に食べられたように見えることを望んで、あなたの皿に食べ物を押し付けるのと同じプログラミングです。

2. バグが実際に修正されたか、a）問題が何であったか、b）変更が問題を解決する方法を理解しない限り、変更によってマスクされていることを知ることはできません。

3. このバグはおそらく修正されておらず、近いうちにまた噛み付くでしょう。

私は2つのシナリオを見ています：あなたは他の何かに取り組んでいて、バグが発生しなくなった、他の何かが他の何かを壊さない限り、あなたはそれを手放す必要があります-あなたは必要な/望まれていたことをしました予期せず説明できない正の副作用。

もう1つは、あなたがこのバグに取り組んでおり、ランダムな変更が物事を機能させることです。それは受け入れられません。古いコードが何を間違えていたのかわからない場合は、おそらく新しいコードが何を間違えているかわからないでしょう。

2番目のケースをチェックインする正当な理由を本当に考えることはできません-それが重大なバグである場合、それを正しくすることが重要です。重大でないバグの場合、少なくとも「修正」で重大なバグを導入していないことを確認できます。

それとも、修正がなぜ機能したのかについての詳細を実際に知らずにプログラムを動作させることが開発者の間で一般的ですか？

私はそれが最近非常に一般的だと思う。これは、GoogleとStackoverflowが原因です。コードに問題があります。グーグルで検索して解決策を見つけ、修正し、次の問題に進みます。