17
診断して修正する前にすべての欠陥を再現することを主張するのは合理的ですか？
私はソフトウェア製品会社で働いています。当社の製品を実装する大企業のお客様がおり、サポートを提供しています。たとえば、不具合がある場合は、パッチなどを提供します。つまり、かなり典型的なセットアップです。 最近、製品のクラスター化された実装での同時データベースアクセスに関係するログファイルでお客様が発見した例外に関してチケットが発行され、私に割り当てられました。したがって、このバグの発生には、この顧客固有の構成が重要になる可能性があります。顧客から得たのは、ログファイルだけです。 私がチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することでした。ただし、バグを再現する必要はありません。過度に時間がかかり、VM上のサーバークラスターをシミュレートする必要があるため、彼らは私のアプローチに同意しません。私のチームは、単純に「コードをたどって」スレッドおよび/またはトランザクションに対して安全でないコードがどこにあるかを確認し、単純なローカル開発で動作する変更を行うことを提案します。バグの起源。 私にとっては、目に見える形の顕在化（実行時の再現）ではなく、抽象的な設計図（プログラムコード）で作業するのは難しいようです。そのため、一般的な質問をしたいと思いました。 すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？ または： 私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、マルチスレッドコードを読んで、すべてのユースケースシナリオでそれが何をするかについての心構図を作成できるはずです行ごとにコード？または、私はそのような作業環境を要求するのに貧弱な開発者ですか？ sissisのデバッグはありますか？ 私の意見では、インシデントチケットに対応して提出された修正は、可能な限り元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか？それは、エアバッグが実際に機能することを実証するためにダミーで衝突試験することなく、車両の新しいモデルをリリースするようなものです。 最後になりますが、私に同意する場合： 私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか？