バグを再現する責任
私は別のプログラマー（彼は同じ会社で働いています）が作成したライブラリーを使用してプログラムを開発しています。最近、ライブラリでリークが発見されました。これは、特定のネットワーク条件下で数時間実行した後に発生します。このリークを発生させる条件の説明をバグとして提出しました。その開発者は「これで十分ではない」、「バグを再現するのは彼の責任ではない」と答え、このバグを再現するには単体テストを作成する必要があります。そうでない場合、彼は何もしません。
- 彼は正しいですか？
- この状況で何ができますか？単体テストの作成は、ランダムなネットワークタイミングに依存するため、不可能です。
彼が正しいかどうかは、おそらくあなたの会社を知らなければ答えられない質問でしょう。しかし、彼は確かにあまり役立っていません。
私は彼と一緒にバグを提起します（あなたがしたことです）、それがあなたのプロジェクトで問題を引き起こしているなら、私はプロジェクトマネージャーと一緒にブロッカーとしてそれを提起し、あなたが適切にバグを提起したことを非常に明確にします人がそれがすぐに修正されない場合、それはあなたのプロジェクトに影響を与えます。
私はまた、開発者と話して、ユニットテストを作成することが実行不可能である理由を説明しますが、それをあなたのマシンで見せていただければ幸いです（それが可能であるとしたら？）。
彼は、バグを再現できるようにするために十分な情報を提供する必要があるという100％の権利を持っています。
しかし-彼はこれがユニットテストの形でなければならないという100％間違っている私見です。 （少なくとも妥当な時間内に高い確率で、または手動テストによって）失敗を再現できるような方法でテストシナリオを説明できる場合、問題が存在する証拠があり、これにより同僚を設定する必要があります。それを修正する責任があります。もちろん、バグをより迅速に再現するシナリオを作成できれば、それは彼にとって役立つでしょう。理想的には、それから自動テストを行うことができます。これは、これを担当する組織に依存します。
双方とも努力する必要があります。
ライブラリ開発者は、単体テストでは再現できない問題があるため、単体テストがなくても追加の作業を行う必要があります。時々それはハードウェアであり、時々それはライブラリが悪い結果を生み出すようにする残りのプログラムからの正しいアクションの特定のシーケンスです。
結局のところ、これはライブラリのバグではないが、残りのプログラムからのincorrectアクションの結果であるため、追加の作業を行う必要があります（たとえば、ヒープの破損により、ライブラリが奇妙に動作する場合があります）。そのため、バグの再現に関与するライブラリ以外のコードを可能な限り減らすことが理にかなっています。そして、あなたはあなたのアプリケーションのコードに不慣れな人よりも速くそしてよりきれいにこれを行うでしょう。
ライブラリの作者があなたの報告に基づいてバグを再現できない場合、彼がそれを修正することはもちろん、それに多くの時間を費やすことを期待するのは不合理です。
ただし、関心のある製品の開発に費やす時間も限られています。残念ながら、これはバグが引き続き存在することを意味し、それを解決するための作業は行われません。
幸いなことに、これは必ずしも災害ではありません。理想的な世界では、すべてのソフトウェアにバグがないため、そうではありません。そのため、米国で発生する問題に基づいて優先順位を付ける必要があります。
つまり、修正したい場合、再現可能なテストケースを作成するのは、実際にあなたの責任です。あなたはそれが修正されるかどうか気にしないかもしれません、そしてその場合、あなたはあなたが期待することができる、そして期待されるべきであるすべてをしました。あなたはそれを修正したいと思うかもしれませんが、現時点でそれを再現可能にするために時間を費やすには十分ではありません。それは完全に許容できます。
バグを報告しなければならないときにできる限りバグを報告することは、単に市民としてよいことであり、プログラムで必要でない限り、それを超える必要はありません。それでも、そうしたくない場合は、使用できる別のライブラリーがあるか、妥当な時間内に独自のライブラリーをロールバックできる可能性があります。基本的に、自分にとってどのような努力をする価値があるか、どのような努力をするかはあなた次第です。
私は今のところ、眠っている犬を寝かせたいと思うでしょう-あなたは問題を提起し、彼に割り当てられています。おそらく、未解決のバグを追跡し、それらを追いかけるためのプロセスが整っているでしょうか？
これを積極的にさらに進めたい場合は、上司に相談して、問題を確実に再現できるテストツールがあるかどうかを確認することをお勧めします。
開発者の側から-必要な情報を提供したとしても、何もしないことは真剣に不活性です。ただし、ワークロードが非常に大きいため、問題の追跡に必要な時間を費やすことができない可能性があります。
あなたはバグを発見し、あなたはそれを報告しました、そして彼はそれについてジャークです。
あなたの2人が親しい友人であったなら、彼は何か手助けをするでしょうが、彼はむしろ問題を押し戻したいと思っていました。
詳細を報告し、メモリリークが発生しているという主張をサポートすることで、さらに多くのことができます。それでも、あなたにはあなた自身の責任があり、あなた自身の仕事を終える必要があります。
できるだけ多くの情報をバグトラッカーに記録し、次に進んでください。
将来この人に会ったら。友好的になり、共通の関心事について話し合い、良い関係が物事を修正するためのはるかに効果的な方法であることを理解してください。
多くの場合、私が同じような状況で遭遇したのは、すべてのバグが修正されるべきであるという仮定であり、それは立派なものですが、それは間違いなく素晴らしい目標です（バグを書くつもりはありません！）、最終的には非現実的ですそれがバグであるという理由だけでバグを修正するためのまともなサイズのプロジェクト（それを見つけることができる場合！）それが私たちがプロジェクト管理とコーディング方法、パターンと実践などを持っている理由です。
したがって、私が図書館の所有者の弁護で言えることの1つは（そして、いくつかの大規模なプロジェクトに取り組んだときはそうでした）、開発時間は費用がかかり、有限のリソースであるため、レポートの処理方法に関する決定です、誰が調査するか、どのテストが作成/必要とされるか、そして最終的に修正が行われるかどうか（行われる場合はいつか）は、純粋にビジネスへの影響に基づいています。長時間実行されているプロセスが失敗した場合に再起動することによる影響は何ですか？代わりに簡単に自動化できます（そして、おそらく防御的プログラミングの手段としてすでにそうであるべきではありませんか？）それはちょうど時間かそれ以上です？
また、非常にまれにしか発生しない、ユーザーのコードからの予測不能な問題に関する1人のユーザーからのバグレポート、彼らのコードとの関連でのみ、おそらく1台のマシンでのみ、一連の異常なタイミングでのみ、それを彼らの視点から見てください。条件は、たとえそれが可能でさえあれば、見つけて修正するための開発時間の大きな塊を正当に正当化することはできません。しかし、そのユーザーが時間をかけて徹底的に調査し、信頼できるテストケース/アプリケーション、または根本的で詳細な問題の説明を最初の問題よりも提供したい、または必要とする十分強いビジネスケースである場合、それはまったく別の球技になる可能性があります。 。
これはおそらくライブラリの所有者がそのように考えることを考慮していないコミュニケーションの問題であり、強力なビジネスケースがある場合（コードがビジネスにコストがかかる、法的コンプライアンス要件がある、セキュリティホールがある、または他の主要なノックオン効果）次に、それを経営陣に向けてキックアップし、彼らに戦わせる時が来ました。