欠陥を診断して修正する前に、すべての欠陥を再現するよう主張することは理にかなっていますか？
私はソフトウェア製品会社で働いています。私たちの製品を実装する大企業のお客様がいて、サポートを提供しています。たとえば、不具合がある場合はパッチなどを提供します。つまり、かなり典型的な設定です。
最近、チケットが発行されて、私たちの製品のクラスター化された実装での同時データベースアクセスに関連するログファイルで顧客が見つけた例外に関して私に割り当てられました。したがって、このバグの発生には、この顧客の特定の構成が非常に重要になる可能性があります。顧客から得たのはログファイルだけでした。
私のチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することです。ただし、非常に時間がかかり、VMでサーバークラスターをシミュレートする必要があるため、バグを再現する必要はないと私は言っています。私のチームは、スレッドおよび/またはトランザクションの安全でないコードがどこにあるかを確認するために「コードをフォローする」ことを提案し、発生元の環境のようなクラスター実装ではない、単純なローカル開発から変更を加えることを提案していますバグの起源。
私には、具体的な目に見える兆候（実行時の再現）ではなく、抽象的な青写真（プログラムコード）から作業することは難しいようです。そのため、一般的な質問をしたいと思いました。
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
または：
私が上級開発者である場合、アプリケーションを実行し、さまざまなユースケースシナリオを実際にテストし、ステップスルーする必要はなく、マルチスレッドコードを読み取って、すべてのユースケースシナリオでそれが何をするかについてのメンタルピクチャーを作成できますか？コードを行ごとに？それとも、そのような作業環境を要求する開発者は貧しいのでしょうか？
弱虫のデバッグですか？
私の意見では、インシデントチケットへの応答として提出された修正は、できるだけ元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか？それは、エアバッグが実際に機能することを示すために、ダミーでそれを衝突試験せずに車両の新しいモデルをリリースするようなものです。
最後になりましたが、あなたが私に同意する場合：
私のアプローチが合理的で、保守的で、より防弾であると彼らに納得させるには、どのようにチームと話し合う必要がありますか？
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
あなたはそれに最善を尽くすべきです。時々、非常に複雑で再現できない正確な条件や環境があることは知っていますが、できる場合は必ず試してください。
バグを再現したことがなく、自分で確認した場合、本当に修正したことを100％確実にするにはどうすればよいでしょうか。おそらく、提案された修正により、実際に試行しないと元の欠陥を再現しない限り、顕在化しない他の微妙なバグが発生する可能性があります。
私が上級開発者である場合、アプリケーションを実行し、さまざまなユースケースシナリオを実際にテストし、ステップスルーする必要はなく、（マルチスレッド）コードを読み取って、すべてのユースケースシナリオでそれが何をするかについてのメンタルピクチャーを作成できますか？行ごとのコード？それとも、そのような作業環境を要求する開発者は貧しいのでしょうか？弱虫のデバッグですか？
それが彼らのonlyアプローチである場合、私は「頭の中で」コードを実行する誰かを信頼しません。 startするのに良い場所です。バグを再現し、それを修正してからデモンストレーションソリューションがバグの再発を防止すること-それが本来あるべき場所ですend 。
私のアプローチが合理的で、保守的で、より防弾であると彼らに納得させるには、どのようにチームと話し合う必要がありますか？
彼らがバグを再現したことがなければ、彼らはそれが修正されたことを確実に知ることができないからです。そして、顧客が戻ってきて、バグがまだ残っていると不平を言った場合、それは良いことではありません。結局のところ、彼らはこの問題に対処するためにあなたに多額の$$$（私は推測する）を払っています。
失敗して問題を適切に修正できなかった場合、（ある程度）顧客との信頼を失い、市場に競合他社がいる場合、あなたの顧客のままではないかもしれません。
問題のバグが修正されたことをどのように確認するつもりですか？彼らはテストされていないコードをユーザーに出荷し、それを理解させたいですか？エラーを再現することが示されていなかったテスト設定は、エラーがないことを示すために信頼することはできません。クライアント環境全体を再現する必要はありませんが、エラーを再現するには十分です。
修正する前にすべてのバグを再現しようとすることは不合理ではないと思います。ただし、それを再現しようとしてもできない場合は、ブラインドパッチが適切かどうかのビジネス上の判断が増えます。
少なくとも、バグが修正されていることをテストできるように、各バグを再現できることが理想的です。
しかし...それは常に実現可能であるとは限らず、物理的にも可能であるとは限りません。特に、各インストールが固有である「エンタープライズ」タイプのソフトウェアでは。費用対効果の評価もあります。数時間、コードを調べて、重要ではない問題についていくつかの知識に基づいた推測を行うと、技術サポートチームが何週間もかけて、お客様の環境をセットアップして複製できるようにして、問題。私が「エンタープライズ」の世界で働いていたとき、顧客の設定を複製する方法がなかったため、プログラマーを派遣してバグを現場で修正してもらうことがよくありました。
そのため、可能な場合は複製してください。複製できない場合は、システムの知識を活用して、コードで原因を特定してください。
エラーを再現することをバグを確認するための要件にする必要はないと思います。あなたが述べたように、問題をデバッグするにはいくつかの方法があります-あなたはそれらのすべてを使うべきです。彼らがあなたにログファイルを与えることができたことを幸運に数えるべきです！あなたまたはあなたの会社の誰かがバグを再現できるなら、素晴らしい！そうでない場合でも、ログを解析して、エラーが発生した状況を見つける必要があります。同僚が提案したように、コードを読んで、バグが発生する可能性のある状況を把握し、自分でシナリオの再現を試みることは可能かもしれません。
ただし、実際の修正をテストせずにリリースしないでください。行う変更はすべて、標準の開発、QAテスト、および統合テストルーチンを経由する必要があります。テストするのは難しいかもしれません-デバッグが難しいことで悪名高いマルチスレッドコードについて説明しました。ここで、テスト構成または環境を作成するためのアプローチに同意します。コードに問題を見つけた場合は、環境を作成し、問題を再現し、修正をテストする方がはるかに簡単です。
私にとっては、これはデバッグの問題ではなく、カスタマーサービスの問題です。顧客からバグレポートを受け取りました。あなたは彼らの問題を見つけてそれを修正するためにデューデリジェンスを行う責任があります。
私の意見では、意思決定者として、あなたは自分の立場を正当化できなければなりません。 3行目のサポート部門の目標が、クライアントからの許容できる努力で最短の時間枠でバグを修正することである場合、どのアプローチもその目標に準拠する必要があります。さらに、アプローチが期待される最速の結果をもたらすことが証明できれば、チームを説得するのに問題はないはずです。
私は常にサポートを提供してきましたが、クライアントが一貫してバグを再現するために実行したアクションの「スクリプト」を提供でき、一貫していない場合はバグを生成した候補の例をクライアントが提供できると常に合理的に期待していました。
システムに不慣れで、コードの背景がない場合、最初のステップは、エラーの考えられる原因を特定することです。候補コードを特定するには、ロギングが不十分である可能性があります。クライアントによっては、問題のあるコードの位置についての手掛かりとなるログファイルを提供できるように、デバッグバージョンを提供する傾向があります。
コードブロックをすばやく特定できる場合は、フローを視覚的にマッピングするだけでコードを見つけることができます。そうでない場合は、単体テストベースのシミュレーションで十分な場合があります。特に問題の再現性が高い場合は、クライアント複製環境のセットアップにかかる時間が短くなる可能性があります。
あなたのアプローチは提案されたソリューションの組み合わせである必要があると思うかもしれません。そして、1つをやめて次のステップにいつ移行するかを知ることは、仕事を効率的に行うための鍵です。
チームは、彼らの解決策がバグをより早く見つける可能性があれば、バグの修正にかかる時間にあまり影響を与えないことを証明するための適切な時間枠を彼らに与えるという考えをサポートすると確信していますあなたが取るルート。
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
はい、いくつか注意点があります。
- コードを読んで、問題があると思われる場所を見つけてみても大丈夫だと思います。パッチを作成してクライアントに送信し、問題が解決するかどうかを確認します。このアプローチが引き続き失敗する場合は、他のオプションを調査する必要があるかもしれません。あなたがaバグに対処しているかもしれない一方で、報告されたtheバグではないかもしれないことを覚えておいてください。
- 妥当な範囲内で再現できず、コードに赤信号が見つからない場合は、顧客とのより緊密な調整が必要になる可能性があります。オンサイトデバッグを行う前に、お客様のサイトに足を運びました。これは最良の開発環境ではありませんが、問題が環境である場合は、一貫して再現できると、正確な原因を見つけるのが最も簡単になります。
このシナリオでは、私は顧客側にいます。私は、非常に大規模なOracleデータベースクラスター（数テラバイトのデータと1日に数百万のレコードを処理する）を使用する米国政府機関で働いていました。
非常に簡単に再現できる奇妙な問題が発生しました。私たちはOracleにバグを報告し、何週間も彼らと行き来してログを送信しました。彼らは問題を再現することができなかったと言ったが、希望が問題に対処するかもしれないいくつかのパッチを私たちに送った。それらのどれもしませんでした。
最終的に、彼らは数人の開発者を私たちの場所に飛ばして現場で問題をデバッグしました。そして、それはバグの根本的な原因が発見されたときであり、その後のパッチは問題に正しく対処しました。
問題に前向きではない場合、解決策に前向きになることはできません。少なくとも1つのテストケース状況で問題を確実に再現する方法を知ることで、エラーの原因を知っていることを証明でき、その結果、その後の不足により、問題が解決されたことを裏側で証明できます。修正を適用した後の同じテストケースのエラーの数。
とはいえ、競合状態、同時実行の問題、およびその他の「非決定的」バグは、開発者がこの方法で特定するのが最も難しいものの1つです。プログラムは、タスクが後で同じシステムで再実行されるときに消えます。
多くの場合、元々ランダムなバグのように見えますが、最終的には確定的な原因が発生し、その方法を知った後、バグは確定的に再現可能になります。これに対抗するものは、真のハイゼンバグ（無菌の監視環境でテストしようとするとランダムに見えるバグ）であり、99.9％のタイミングに関連しています。コードの実行中に何か他のものがWordをエッジワイズにした場合に失敗する可能性のあるものをスキャンし、そのような脆弱性を見つけたら、テストでそれを悪用して、再現しようとしている動作を示しているかどうかを確認します。
これらの状況では、通常、かなりの量の詳細なコード検査が必要になります。あなたはコードを見て、コードがどのように動作するかについての先入観を放棄する必要があります想定動作し、クライアントが観察した方法でそれが失敗するシナリオを想像してくださいcould 。シナリオごとに、現在の自動テスト環境内で効率的に実行できるテストを開発してみてください（つまり、このVMスタックを使用する必要はありません）。コードが期待どおりに動作することを証明します（期待した結果に応じて、このコードがクライアントの問題の原因である可能性があることを証明または証明します）。これはソフトウェアエンジニアにとって科学的な方法です。観察、仮定、テスト、反映し、繰り返します。
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
いいえ、そうではありません。それは愚かな政策でしょう。
私があなたの質問とあなたの提案で見る問題は、彼らが両者を区別できないことです
- バグレポート
- 失敗（エラー）
- bugs（errorsと呼ばれることもあります）
バグレポートはバグについてのコミュニケーションです。それは誰かが何かが間違っていると思っていることを伝えます。それは何が間違っていると思われるかについて特定である場合とそうでない場合があります。
バグレポートは失敗の証拠です。
failureは、問題が発生したことを示します。特定の誤動作。ただし、必ずしもその原因を特定する手がかりはありません。
不具合が原因の可能性があります。
bugは失敗の原因です。 （原則として）将来発生する障害を防ぐために変更できるもの。
バグが報告されると、原因がすぐに明らかになることがあります。このような場合、バグの再現は無意味です。他の場合には、原因がまったく明確ではありません。バグレポートに特定の障害が記述されていないか、または障害が原因で何が原因であるかについての手掛かりを提供しないような障害です。そのような場合、あなたの忠告は正当化されると私は感じますが、常にではありません。調査を受け入れる前に2億7,000万ドルの宇宙ロケットを衝突させることを主張するわけではありません 最初の衝突の原因 （特定のバグ制御ソフトウェアで）。
また、その間にはあらゆる種類のケースがあります。たとえば、バグレポートが証明しておらず、すでに知っている潜在的な問題が役割を果たす可能性があることを示唆しているだけの場合、これは、詳細に調査するのに十分なインセンティブになる可能性があります。
したがって、再現性を主張することは、より厳しい場合には賢明ですが、厳密なポリシーとしてそれを強制することは賢明ではありません。
それを極端に考えて、あなたがバグを以前に見つけたと仮定しましょう：あなたがそれを書いていたように、あなたのコードでそしてあなたはそうしませんすぐにそれを修正することに不安を感じています。あなたが書いたばかりのコードにロジックの欠陥が見られますが、それはあなたが望んでいたことをしていません。実際にバグであることを示すために環境全体をセットアップする必要はないと感じます。
バグレポートが届きました。いくつかのことができます。それらの1つは、コードに戻ってそれを再度読み取ることです。今度は、この2回目の読みで、コード内のバグをすぐに見つけたとしましょう。単に意図したとおりに機能せず、作成時に気付かなかったとします。 そして、それはちょうど来たバグを完全に説明しています！あなたは修正を行います。 20分かかりました。
バグレポートの原因となったバグは修正されましたか？あなたは100％確信することはできません（これと同じことを引き起こしている2つバグがあった可能性があります）、それはおそらくそうでした。
あなたができるもう1つのことは、できる限りお客様の構成を再現し（数日の作業）、最終的にバグを再現することです。多くの場合、バグを再現できないことを意味するタイミングと同時実行性の問題がありますが、多くの時間を試すことができ、同じことが起こるのを時々見ることができます。次に、デバッグを開始し、コード内のエラーを見つけて環境に置き、何度も再試行します。バグが発生することはもうありません。
バグレポートの原因となったバグは修正されましたか？それでも100％確実ではありません-1つは、実際に顧客が行った完全に異なるバグを見たことがあるかもしれません、2つは、十分な頻度で試していない可能性があります。このシステムでは修正されていますが、お客様のシステムでは修正されていません。
したがって、どのような場合でも確実に取得することは不可能です。しかし、最初の方法ははるかに高速です（顧客にパッチをより速く与えることもできます）、はるかに安価であり、if明確なコーディングバグを見つける症状を説明しますが、実際には問題を見つける可能性も高くなります。
したがって、状況によって異なります。テスト環境をセットアップするのが安ければ（またはそれ以上：問題を示す自動テスト）、それを実行します。ただし、コストが高い場合や、バグが表示される状況が予測できない場合は、常に最初にコードを読んでバグを見つけることをお勧めします。
エラーが明白で明白なものでなく、非常に具体的なエラーメッセージなどがない限り、ユーザーまたはメンテナがそれを複製できない場合、バグを修正するのは非常に困難です。
また、手順を複製できない場合、バグが修正されたことをどのように彼らに証明しますか？
あなたのケースの問題は、ユーザーがエラーがどのように発生したか、つまりどの操作をどの画面で行ったかがわからないことです。彼らは単にログを持っています。
あなたの主張は妥当だと思います。もしあなたが精神的な力を持っていたなら、あなたはおそらく給与のために働いていないでしょう。
私はあなたが上司にエラーを再現することができないとそれを見つけるのに不明な時間がかかることを教えるべきだと思いますまったく保証なし意志。
問題は、あなたの同僚の誰かがバグを発見したとき運が悪いを見つけて修正するときです。
ソフトウェア開発の他のすべてと同様に、正しい答えは妥協です。
理論的には、バグが存在することを証明できない場合は、バグを修正しようとするべきではありません。これを行うと、最終的に何も解決しないコードに不要な変更を加える可能性があります。そしてそれを証明することは、最初にそれを再現し、次に修正を作成して適用し、それがもはや起こらないことを示すことを意味します。ここであなたの直感は正しい方向にあなたを導きます-あなたがあなたの顧客の問題を解決したことを確信したいのであれば、何が最初にそれを引き起こしたのかを知る必要があります。
実際には、それが常に可能であるとは限りません。おそらく、このバグは、数十人のユーザーが同時にコードにアクセスしている大規模なクラスターでのみ発生します。おそらく、特定のデータセットに対するデータ操作の特定の組み合わせでバグが発生し、それが何であるかがわかりません。おそらく、バグが発生する前に、顧客がプログラムをインタラクティブにノンストップで数百時間実行した可能性があります。
これらのいずれの場合でも、作業を開始する前に、部門がバグを再現するための時間や費用がない可能性が高いです。多くの場合、開発者であるあなたには、コードにポイントするが正しい状況を示すバグがあることははるかに明白です。問題を診断すると、戻って問題を再現できる場合があります。それは理想的ではありませんが、同時に、上級開発者としてのあなたの仕事の一部は、コードの読み取りと解釈の方法を知ること、部分的にはこの種の埋め込まれたバグを見つけることです。
私の意見では、あなたは質問の間違った部分に焦点を当てています。最終的にできない問題のバグを再現するとどうなりますか？ 「そうです、プログラムがクラッシュしたことはわかっていますが、再現することはできないので、バグではありません」と聞くよりも、お客様に不満はありません。お客様がこれを聞くと、「ソフトウェアにバグがあることはわかっていますが、バグを修正して修正するのは面倒なので、指を交差させるだけです」と解釈します。報告されたバグを「再現性がない」としてクローズするか、「再現性がないとしてクローズするほうがよいが、安定性を向上させるために合理的な変更を加えた」か。
より詳細なロギングが必要なように思えます。
ロギングを追加しても、デバッグする必要がない（またはこの場合は状況を再現する）必要がないことは保証できませんが、実際に問題が発生した原因をはるかに詳しく把握できます。
特に、複雑なスレッドの状況、またはデバッガーを使用できない状況では、「printf（）によるデバッグ」に頼るのが唯一の手段です。その場合は、できる限り（必要以上に）ログに記録し、もみ殻から小麦をフィルタリングするための優れたツールを用意してください。
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
誰もまだ明確な言葉でそれを言っていないので：絶対にそうではない！
ソフトウェア開発の他のすべてと同様に、バグ修正は時間、リスク、およびコストを念頭に置くことを意味します。これらのバランスを見つけることは、開発者の仕事の説明の半分です。
バグの中には、2日間を費やすほど重要ではないものの、修正に10分を費やすほど重要なものがあります。他のバグは非決定的であり、テスト環境がそれらが修正されたことを証明できないことはすでに知っています。テスト環境のセットアップに2日かかる場合は、これらのバグのために行う必要はありません。代わりに、2日ではなく5分でテスト環境をセットアップする方法を見つけるなど、よりスマートなことに時間を費やします。
そしてもちろん、あなたがそれらを間違えるとクライアントが$ 100'000 +を失うバグがあります。また、クライアントが1時間ごとに$ 100'000 +を失うバグは修正されていません。あなたはバグを見て決定を下す必要があります。すべてのバグを同じように扱う包括的なステートメントは機能しません。
質問を読んで、私はあなたの立場とあなたのチームの立場の間に根本的な反対を見ることはありません。
はい、クライアント設定で発生する問題を再現するために最善を尽くす必要があります。ただし、ベストエフォートは、そのための時間ボックスを定義する必要があることを意味し、実際に問題を再現するのに十分なデータがログにない可能性があります。
その場合、すべてはこの顧客との関係に依存します。それはあなたが彼から他に何も持っていないことから、診断ツールと障害のあるシステムでそれらを実行する能力を備えた開発者を現場に送ることができるからです。通常、その中間にあり、初期データが十分でない場合は、さらに取得する方法があります。
はい、上級開発者はコードを読み取れるはずであり、ログの内容に従って問題の理由を見つける可能性があります。実際、コードを注意深く読んだ後、問題を示すユニットテストを書くことがしばしば可能です。
このような単体テストの作成を成功させることは、機能的な環境を破壊することとほぼ同じです。もちろん、この方法もあなたが何かを見つけることを保証するものではありません。一部のマルチスレッドソフトウェアで障害の原因となるイベントの正確なシーケンスを理解することは、コードを読むだけでは本当に見つけるのが難しく、ライブデバッグ機能が重要になる可能性があります。
要約すると、私は両方のアプローチを同時に試し、問題が発生している（そして後で修正されていることを示す）ライブシステム、または問題に対するユニットテストの中断（および修正後に修正されていることも示す）のいずれかを要求します。
コードを修正して実際に送信するだけでは、実際には非常に危険に見えます。私に発生したいくつかの同様のケース（内部で欠陥を再現できなかった）で、修正が実際に行われて顧客の問題を解決できなかった場合、またはその他の予期しない悪影響があった場合、提案した人がサポートチームが実際の問題を見つけるのに役立つ必要があります。必要に応じて、お客様との取引を含みます。
とても良い質問です！私の意見では、問題を再現できない場合は、100％で確実に修正を行うことができないとは言えません。
a）実際に問題を修正します。 b）別のバグを作成する
バグが発生して、私がそれを修正し、それをテストする必要がない場合があります。 100％確実に機能することを知っています。しかし、QA部門が機能していると言うまでは、まだバグが存在する可能性があるか、または修正によって作成された新しいバグである可能性があると考えています。
バグを再現できず、新しいバージョンをインストールして、それが修正されていることを確認できない場合、100％の確実性で、バグがなくなったと言うことはできません。
私はあなたが他の人に説明するのに役立つアナロジーを考えるために数分間試しましたが、実際には何も思い浮かびませんでした。精管切除術は面白い例ですが、同じ状況ではありません:-)
[関連するバグ]同時データベースアクセス、クラスター化された実装、マルチスレッド
すべての欠陥の再現を主張し、それを診断して修正する前にデバッグすることは妥当ですか？
再現に時間をかけすぎないようにします。それは同期の問題のように見え、それらを再現する方法を見つけてデバッガーで攻撃する方法を見つけることよりも、（問題が発生するサブシステムを特定する必要があるログから開始する）推論によってより頻繁に発見されます。私の経験では、コードの最適化レベルを下げたり、場合によっては追加のインスツルメンテーションをアクティブ化したりするだけで、十分な遅延を追加したり、同期プリミティブが不足してバグが発生するのを防ぐことができます。
はい、バグを再現する方法がない場合は、バグを確実に修正できません。しかし、顧客がそれを再現する方法を提供していない場合、同じ結果であるが根本的な原因が異なる同様の何かを探している可能性もあります。
両方のアクティビティ（コードレビューとテスト）が必要ですが、どちらも不十分です。
バグを再現するために実験を構築するために何ヶ月も費やすことができ、コードを見て、検索領域を狭めるための仮説を立てなければ、決してどこにも到達できません。コードのバグを視覚化しようとして何ヶ月もおへそを注視し、1回、2回、3回それを見つけたとさえ思うかもしれません。「いいえ、バグはまだあります。 」
一部の開発者は、1つのアクティビティ（コードのレビューとテストの構築）が他のアクティビティよりも比較的優れています。完璧なマネージャーは、バグを割り当てる際にこれらの長所を比較検討します。チームアプローチはさらに実りあるかもしれません。
最終的には、バグを再現するための十分な情報がない可能性があります。しばらくの間、別の顧客が同様の問題を見つけて、構成の問題についてより深い洞察を得られることを期待して、バグをマリネさせる必要があります。バグを見た顧客が本当に修正を望んでいる場合、彼らはあなたと協力してより多くの情報を収集します。この問題が一度だけ発生した場合、顧客が重要であっても、優先度の高いバグではない可能性があります。時には、バグが機能しないことは、十分な情報がなく、本当にあいまいな欠陥を探すために、工数を浪費するよりも賢い場合があります。