診断して修正する前にすべての欠陥を再現することを主張するのは合理的ですか？

私はソフトウェア製品会社で働いています。当社の製品を実装する大企業のお客様がおり、サポートを提供しています。たとえば、不具合がある場合は、パッチなどを提供します。つまり、かなり典型的なセットアップです。

最近、製品のクラスター化された実装での同時データベースアクセスに関係するログファイルでお客様が発見した例外に関してチケットが発行され、私に割り当てられました。したがって、このバグの発生には、この顧客固有の構成が重要になる可能性があります。顧客から得たのは、ログファイルだけです。

私がチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することでした。ただし、バグを再現する必要はありません。過度に時間がかかり、VM上のサーバークラスターをシミュレートする必要があるため、彼らは私のアプローチに同意しません。私のチームは、単純に「コードをたどって」スレッドおよび/またはトランザクションに対して安全でないコードがどこにあるかを確認し、単純なローカル開発で動作する変更を行うことを提案します。バグの起源。

私にとっては、目に見える形の顕在化（実行時の再現）ではなく、抽象的な設計図（プログラムコード）で作業するのは難しいようです。そのため、一般的な質問をしたいと思いました。

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

または：

私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、マルチスレッドコードを読んで、すべてのユースケースシナリオでそれが何をするかについての心構図を作成できるはずです行ごとにコード？または、私はそのような作業環境を要求するのに貧弱な開発者ですか？

sissisのデバッグはありますか？

私の意見では、インシデントチケットに対応して提出された修正は、可能な限り元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか？それは、エアバッグが実際に機能することを実証するためにダミーで衝突試験することなく、車両の新しいモデルをリリースするようなものです。

最後になりますが、私に同意する場合：

私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか？

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

最善を尽くしてください。私は時々、非常に複雑で正確に再現できない条件や環境があることを知っていますが、できるなら必ず試してみるべきです。

バグを一度も再現せずに自分で見た場合、実際に修正したことを100％確実に確認するにはどうすればよいですか？提案された修正により、元の欠陥を実際に再現しようとしない限り顕在化しない他の微妙なバグが導入される可能性があります。

私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、すべてのユースケースシナリオで（マルチスレッド）コードを読み、それが何をするかを心の中で描くことができますか？コードを行ごとに？または、私はそのような作業環境を要求するのに貧弱な開発者ですか？sissisのデバッグはありますか？

それが彼らの唯一のアプローチであるならば、「頭の中で」コードを実行する誰かを信用しません。始めるには良い場所です。バグを再現し、修正してから、解決策がバグの再発を防ぐことを実証します-それが終了すべき場所です。

私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか？

バグを再現したことがない場合、バグが修正されたことを確実に知ることができないためです。そして、顧客が戻ってきて、バグがまだ残っていると不平を言う場合、それは良いことではありません。結局のところ、彼らはこの問題に対処するためにあなたに大きな$$$（私が推測する）を支払っています。

問題を適切に修正できなかった場合、顧客との信頼をある程度失い、市場に競合他社が存在する場合、顧客が顧客でなくなる可能性があります。

問題のバグが修正されたことをどのように検証するつもりですか？彼らは、テストされていないコードをユーザーに出荷して、彼らにそれを理解させたいですか？エラーを再現することが示されていないテスト設定は、エラーがないことを示すために信頼することはできません。確かに、クライアント環境全体を再現する必要はありませんが、エラーを再現するのに十分な必要があります。

修正する前にすべてのバグを再現しようとするのは理不尽ではないと思います。ただし、それを再現しようとしてもできない場合は、ブラインドパッチが良いアイデアであるかどうかに関するビジネス上の決定になります。

理想的には、各バグを再現できるようにして、少なくとも修正されたことをテストできるようにします。

しかし...それは常に実現可能ではなく、物理的にも可能ではないかもしれません。特に、各インストールが一意である「エンタープライズ」タイプのソフトウェアの場合。費用/便益の評価もあります。数時間のコードを調べて、重要ではない問題についていくつかの経験に基づいた推測を行うと、テクニカルサポートチームが顧客の環境をセットアップして複製するために数週間を費やして、問題。「エンタープライズ」の世界で働いていたとき、顧客の設定を複製する方法がなかったため、多くの場合、コーダーを飛ばして現場でバグを修正するだけでした。

そのため、可能な場合は複製しますが、できない場合は、システムに関する知識を活用し、コードの犯人を特定してください。

エラーを再現することをバグを見るための要件にするべきではないと思います。あなたが言及したように、問題をデバッグするいくつかの方法があります-そしてあなたはそれらのすべてを使用するべきです。彼らはあなたにログファイルを提供できたことを幸運に思うべきです！あなたまたはあなたの会社の誰かがバグを再現できるなら、素晴らしい！そうでない場合でも、ログの解析を試みて、エラーが発生した状況を見つける必要があります。同僚が提案したように、コードを読んで、バグが発生する可能性のある状況を把握し、自分でシナリオを再作成することもできます。

ただし、テストされていない実際の修正をリリースしないでください。変更する場合は、標準開発、QAテスト、統合テストルーチンを実行する必要があります。テストするのは難しいかもしれません-デバッグが難しいことで有名なマルチスレッドコードについて言及しました。ここで、テスト構成またはテスト環境を作成するあなたのアプローチに同意します。コードに問題が見つかった場合、環境を作成し、問題を再現し、修正をテストする方がはるかに簡単です。

私にとって、これはデバッグの問題ではなく、カスタマーサービスの問題です。顧客からバグレポートを受け取りました; 問題を見つけて修正するためにデューデリジェンスを行う責任があります。

私の意見では...意思決定者として、あなたは自分の立場を正当化できなければなりません。3行目のサポート部門の目標が、クライアントからの許容可能な努力で最短時間でバグを修正することである場合、どのアプローチもその目標に準拠する必要があります。さらに、アプローチが予想される最速の結果をもたらすことが証明できれば、チームを納得させる問題はないはずです。

サポートで働いてきた私は、クライアントがバグを一貫して再現するために実行したアクションの「スクリプト」を提供できることを常に合理的に期待していました。

システムを初めて使用し、コードのバックグラウンドがない場合、最初のステップは、エラーの原因を特定することです。候補コードを特定するにはロギングが不十分である可能性があります。クライアントによっては、問題のあるコードの位置に関するさらなる手がかりを提供するログファイルを返すことができるように、デバッグバージョンを提供する傾向があります。

コードブロックをすばやく識別できる場合、フローを視覚的にマッピングするだけでコードを見つけることができます。そうでない場合は、単体テストベースのシミュレーションで十分です。特に問題の複製可能性が非常に大きい場合、クライアント複製環境のセットアップにかかる時間が短くなる可能性があります。

あなたのアプローチは提案されたソリューションの組み合わせであるべきであり、いつ終了して次のソリューションに進むべきかを知ることが、仕事を効率的に行うための鍵であると思うかもしれません。

チームは、ソリューションがバグをより迅速に発見する可能性がある場合、バグを修正するのにかかる時間にあまり影響を与えないことを証明するために適切な時間枠を与えるという概念をサポートすると確信していますあなたが取るルート。

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

はい、いくつかの注意事項があります。

• コードを読んで問題があると思われる場所を見つけようとしても問題ないと思います。パッチを作成してクライアントに送信し、問題が解決するかどうかを確認します。このアプローチが引き続き失敗する場合は、他のオプションを調査する必要があります。ちょうどあなたが取り組むことかもしれないがことを覚えていたバグを、それはないかもしれないと報告されたバグを修正しました。
• 正当な理由でそれを再現できず、コード内に危険信号が見つからない場合、顧客とのより緊密な調整が必要になる場合があります。サイトのデバッグを行う前に、お客様のサイトに飛びました。これは最高の開発環境ではありませんが、問題が環境的なものである場合は、一貫して再現できる場合、正確な原因を見つけるのが最も簡単になります。

このシナリオでは、私はテーブルの顧客側にいました。私は、信じられないほど大規模なOracleデータベースクラスター（1日に数テラバイトのデータを処理し、数百万のレコードを処理する）を使用している米国政府のオフィスで働いていました。

私たちは非常に簡単に再現できる奇妙な問題に遭遇しました。私たちはバグをOracleに報告し、ログを送って数週間それらを行き来しました。彼らは問題を再現することはできないと言ったが、希望が問題に対処するかもしれないいくつかのパッチを送った。それらのどれもしませんでした。

最終的に、彼らは数人の開発者を私たちの場所に送り出し、現場で問題をデバッグしました。そして、それはバグの根本原因が発見され、その後のパッチが問題に正しく対処したときでした。

問題について肯定的でない場合、解決策について肯定的であることはできません。少なくとも1つのテストケースの状況で問題を確実に再現する方法を知っていると、エラーの原因を知っていることを証明できます。修正を適用した後の同じテストケースでのエラーの数。

とはいえ、競合状態、同時実行性の問題、およびその他の「非決定的」バグは、開発者がこの方法で特定するのが最も難しいものです。プログラムは、後で同じシステムでタスクを再実行すると消えます。

多くの場合、もともとランダムなバグのように見えていたものが、決定論的な原因になり、その方法がわかれば、バグは決定論的に再現可能になります。これに反するもの、真のハイゼンバグ（無菌の監視された環境でテストしようとすると消える一見ランダムなバグ）は、99.9％のタイミング関連であり、それを理解すると、今後の道がより明確になります。コードの実行中に他の何かがエッジワイズで単語を取得した場合に失敗する可能性のあるものをスキャンし、そのような脆弱性を見つけたら、テストでそれを悪用して、再現しようとしている動作を示すかどうかを確認します。

これらの状況では、通常、かなりの量の詳細なコード検査が必要です。あなたは、コードがされる方法のいずれかの先入観放棄し、コードを見ているはず振る舞うようにし、そしてそれがどのシナリオを想像することができ、あなたのクライアントが観察している方法で失敗することがあります。シナリオごとに、現在の自動テスト環境内で効率的に実行できる（つまり、この1つのテストだけに新しいVMスタックを必要としない）テストを開発し、コードが期待どおりに動作することを証明または反証します（これは、予想した内容に応じて、このコードがクライアントの問題の原因である可能性があることを証明または反証します）。これはソフトウェアエンジニアにとっての科学的手法です。観察、仮説、テスト、反映、繰り返し。

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

いいえ、そうではありません。それは愚かな政策でしょう。

あなたの質問とあなたの提案で私が見る問題は、彼らが間で区別をしないということです

• バグレポート
• 失敗（エラー）
• バグ（エラーとも呼ばれます）

バグレポートは、バグに関するコミュニケーションです。誰かが何かが間違っていると思うことを伝えます。それは、何が間違っていると思われるのかについて具体的である場合とそうでない場合があります。

バグレポートは失敗の証拠です。

失敗は間違って何かの事件です。特定の誤動作。ただし、必ずしもそれが原因である可能性のある手がかりがあるわけではありません。

障害はバグが原因である可能性があります。

バグは、失敗の原因です。将来的に発生する障害を防ぐために（原則的に）変更できるもの。

バグが報告されると、原因がすぐに明らかになる場合があります。そのような場合、バグを再現することは無意味です。それ以外の場合、原因はまったく明確ではありません：バグレポートには特定の障害が記述されていないか、または障害はありますが、障害は原因が何であるかについての手がかりを提供しないようなものです。そのような場合、あなたのアドバイスは正当であると感じますが、常にそうではありません：最初のものがクラッシュする原因を調査するために受け入れる前に、2つ目の3億7千万ドルの宇宙ロケットのクラッシュを主張しません（制御ソフトウェアの特定のバグ）。

また、間にはあらゆる種類のケースがあります。たとえば、バグレポートが証明されていないが、既に認識している潜在的な問題が役割を果たしている可能性があることを示唆している場合、これを詳しく見るための十分なインセンティブになります。

そのため、再現性を主張することはより厳しい場合には賢明ですが、厳密なポリシーとしてそれを実施することは賢明ではありません。

ソフトウェア開発の他のすべてと同様に、正しい答えは妥協です。

理論的には、バグが存在することを証明できない場合は、バグを修正しようとしないでください。そうすることで、最終的には何も解決しないコードに不必要な変更を加える可能性があります。そして、それを証明するということは、まずそれを再現し、次に修正を作成して適用し、それがもはや起こらないことを実証することを意味します。ここでのあなたの直感は正しい方向にあなたを導くことです-あなたがあなたの顧客の問題を解決したと確信したいなら、あなたはそもそもそれを引き起こしたものを知る必要があります。

実際には、それは常に可能とは限りません。おそらくバグは、多数のユーザーが同時にコードにアクセスしている大規模なクラスターでのみ発生します。おそらく、バグをトリガーする特定のデータセットに対するデータ操作の特定の組み合わせがあり、それが何であるかわからない可能性があります。おそらく、バグが発生する前に、顧客が数百時間にわたって対話なしでプログラムを対話的に実行した可能性があります。

これらのいずれの場合でも、作業を開始する前に、あなたの部門がバグを再現するための時間やお金を持たない可能性が高くなります。多くの場合、開発者であるあなたには、コードにバグがあり、正しい状況を示していることが明らかです。問題を診断したら、戻って問題を再現できる場合があります。それは理想的ではありませんが、同時に、上級開発者としての仕事の一部は、コードの読み方と解釈方法を知って、部分的にこの種の埋められたバグを見つけることです。

私の意見では、あなたは質問の間違った部分に焦点を合わせています。最終的に問題のバグを再現できない場合はどうなりますか？「ええ、あなたがプログラムをクラッシュさせたのは知っていますが、再現できないので、バグではありません」と聞くことほど、顧客をイライラさせるものはありません。顧客はこれを聞いたとき、「ソフトウェアにバグがあることはわかっていますが、バグを修正して修正することはできませんので、指を交差させるだけです」と解釈します。報告されたバグを「再現性がない」として閉じる、または「再現性がないが、安定性を改善するために合理的な変更を加えた」として閉じる方が良い場合は？

エラーが明確で明白であり、非常に具体的なエラーメッセージなどがある場合を除き、ユーザーまたはメンテナーがそれを複製できない場合、バグを修正することは非常に困難です。

また、手順を再現できない場合、バグが修正されたことをどのように証明しますか？

この場合の問題は、エラーがどのように発生したか、つまり、どの画面でどの操作を行っているかがユーザーにわからないことです。彼らは単にログを持っています。

あなたの主張は合理的だと思います。もしあなたが超能力を持っていたら、あなたはおそらく給料のために働いていないでしょう。

私はあなたがエラーを再現できず、それが取るであろうと、あなたの上司に伝えるべきだと思い時間のにUnknown量を、それを見つけるために、そしてありません全くgaranteeその必要になりますが。

問題は、同僚の何人かが純粋な運からバグを見つけて修正するときです。

極端に考えてみましょう。バグをもっと早く見つけたと仮定しましょう。作成中のコードで。そうすれば、すぐに修正することに何の不安もありません-書いたばかりのコードに論理的な欠陥があり、望んでいたことをしません。環境全体をセットアップして、それが実際にバグであることを示す必要はありません。

バグレポートが届きました。できることはいくつかあります。それらの1つは、コードに戻って再読み取りすることです。この2回目の読み取りで、コードのバグをすぐに見つけたとします。意図したとおりの動作をしないため、コードを書いたときに気付かなかったとします。そして、それは入ったばかりのバグを完全に説明しています！修正します。20分かかりました。

バグレポートの原因となったバグは修正されましたか？100％確信は持てません（これと同じことを引き起こす2つのバグがあった可能性があります）が、おそらくそうでした。

もう1つできることは、できる限り顧客の構成を再現し（数日間の作業）、最終的にバグを再現することです。多くの場合、バグを再現できないというタイミングと並行性の問題がありますが、多くの時間を試すことができ、同じことが起こることもあります。ここで、デバッグを開始し、コード内のエラーを見つけて環境に配置し、何度も再試行します。バグはもう発生していません。

バグレポートの原因となったバグは修正されましたか？あなたはまだ100％確信することはできません-1つは、あなたが実際に顧客が行った完全に異なるバグを見たことがあるかもしれません、2つは多分あなたは十分に試行しなかったかもしれません、そして3つは多分設定がまだ少し異なっていてそれがこのシステムで修正されましたが、顧客のものではありません。

いずれにしても、確実性を得るのは不可能です。しかし、最初の方法ははるかに高速で（お客様にパッチを迅速に提供することもできます）、はるかに安価であり、症状を説明する明確なコーディングバグを見つけた場合、実際には問題も発見する可能性が高くなります。

依存します。テスト環境のセットアップが安価な場合（または、問題を示す自動化されたテスト）、それを実行します。しかし、それが高価であり、かつ/またはバグが示す状況が予測できない場合、最初にコードを読んでバグを見つけようとする方が常に良いです。

質問を読んで、私はあなたの立場とあなたのチームの間に根本的な対立を見ません。

• はい、クライアント設定で発生する問題を再現するために最善を尽くす必要があります。ただし、最善の努力をすると、そのためのタイムボックスを定義する必要があり、ログに実際に問題を再現するのに十分なデータがない可能性があります。

  その場合、すべてはこの顧客との関係に依存します。それはあなたが彼から他に何も持っていないことから、診断ツールと故障システムでそれらを実行する能力を備えた開発者を現場に送るかもしれません。通常、私たちはその中間のどこかにいます。初期データが十分でない場合は、さらに取得する方法があります。

• はい、上級開発者はコードを読むことができ、ログの内容に続いて問題の理由を見つける可能性が高いです。本当に、コードを注意深く読んだ後に問題を示すユニットテストを書くことはしばしば可能です。

  このような単体テストを書くことは、破壊的な機能環境を再現するのとほぼ同じくらい優れています。もちろん、この方法は何かを見つけることを保証するものでもありません。一部のマルチスレッドソフトウェアで障害を引き起こすイベントの正確なシーケンスを理解することは、コードを読み取るだけでは見つけるのが非常に難しく、ライブデバッグ機能が重要になる可能性があります。

要約すると、両方のアプローチを同時に試して、問題が発生している（そしてその後修正されていることを示す）ライブシステムか、問題を破る単体テストを破壊する（そして修正後に修正されていることを示す）ことを求めます。

ただコードを修正して、それを野生で送信しようとすると、実際には非常に危険に見えます。私が発生したいくつかの同様のケース（内部で欠陥を再現できなかった場合）で、修正が野生に行き、顧客の問題を解決できなかった場合、または他の予期しない負の結果があった場合、提案した人サポートチームが実際の問題を見つけるのを支援する必要があります。必要に応じて顧客との取引を含む。

より詳細なログが必要なようです。

ロギングを追加しても、デバッグ（または、この場合は状況を再現）する必要がないことを保証することはできませんが、実際に何が失敗したかについてのより良い洞察を提供します。

特に複雑な/スレッドの状況、またはデバッガを使用できない場合は、「printf（）によるデバッグ」に頼ることが唯一の頼みかもしれません。その場合、できるだけ多くのログを記録し（必要以上に）、もみ殻から小麦をフィルタリングするための優れたツールを用意します。

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

誰もまだ明確な言葉でそれを言っていないので：絶対にそうではありません！

ソフトウェア開発の他のすべてと同様に、バグ修正とは、時間、リスク、コストを念頭に置くことです。これらのバランスを見つけることは、開発者の職務記述書の半分です。

バグの中には、2日間を費やすほど重要ではないものもありますが、10分間を費やすほど重要なバグもあります。他のバグは非決定的であり、テスト環境がそれらが修正されたことを証明できないことを既に知っています。テスト環境のセットアップに2日かかる場合、これらのバグに対しては行いません。代わりに、2日ではなく5分でテスト環境をセットアップする方法を見つけるなど、よりスマートなことに時間を費やします。

そしてもちろん、あなたがそれらを間違えた場合、クライアントが$ 100'000 +を失うバグがあります。また、クライアントが1時間ごとに$ 100'000 +を失うバグは修正されていません。バグを見て決定する必要があります。すべてのバグを同じように扱う包括的なステートメントは機能しません。

とても良い質問です！私の意見では、問題を再現できない場合、100％修正しても修正しないとは絶対に言えません。

a）実際に問題を修正します。b）別のバグを作成する

バグが発生し、それを修正することがありますが、テストすることはありません。100％確実に機能することを知っています。しかし、QA部門が機能していると言うまでは、バグがまだ存在する可能性があると考えています...または修正から作成された新しいバグです。

バグを再現できず、新しいバージョンをインストールし、修正されたことを確認した場合、100％の確実性でバグがなくなったと言うことはできません。

他の人に説明するのに役立つ類推を数分間考えましたが、何も思いつきませんでした。精管切除は面白い例ですが、同じ状況ではありません:-)

[関連バグ]同時データベースアクセス、クラスター化された実装、マルチスレッド

すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？

私はそれを再現しようとしてあまり時間をかけません。それは同期の問題のように見え、それらを再現する方法を見つけたり、デバッガーで攻撃したりするよりも、推論（問題が発生するサブシステムを特定する必要があるようなログから開始）により多くの場合発見されます。私の経験では、コードの最適化レベルを下げるか、場合によっては追加のインストルメンテーションをアクティブ化するだけで、バグが現れるのを防ぐのに十分な遅延または同期プリミティブの不足を追加できます。

はい、バグを再現する方法がない場合、それを修正したかどうかを確認することはできません。ただし、顧客がそれを再現する方法を提供していない場合は、同じ結果で根本的な原因が異なる類似のものも探している可能性があります。

両方のアクティビティ（コードレビューとテスト）が必要ですが、どちらも十分ではありません。

バグを再現しようとする実験を構築するのに数ヶ月費やすことができ、コードを見て、検索スペースを狭める仮説を立てないと、どこにも到達できません。コードのバグを視覚化しようとしておへそを数ヶ月吹き飛ばし、1回、2回、3回見つけたと思うかもしれませんが、せっかちな顧客に「いいえ、バグはまだあります。 」

一部の開発者は、一方のアクティビティ（コードレビュー対テストの構築）が他方よりも比較的優れています。完璧なマネージャーは、バグを割り当てる際にこれらの長所を比較検討します。チームアプローチはさらに実り多い場合があります。

最終的には、バグを再現するのに十分な情報がない可能性があり、別の顧客が同様の問題を見つけて、構成の問題についてより多くの洞察を得ることができることを期待してしばらくバグをマリネートさせる必要があります。バグを見た顧客が本当にそれを修正したい場合、彼らはあなたと協力してより多くの情報を収集します。この問題が一度しか発生しなかった場合、顧客が重要であっても、おそらく優先度の高いバグではありません。バグを処理しないことは、十分な情報のない本当に目立たない欠陥を探すために工数を費やすよりも賢い場合があります。