「マンデルバグ」の存在をチームメンバーに納得させる方法

アプリケーションを開発しています。別のコーダーによって開発されたライブラリが含まれ、このライブラリは複数のネットワーク接続を介してサーバーと通信し、これには複数のスレッドが連携して動作する必要があります。サーバー側のコードは非常に複雑であり、ソースコードにはアクセスできません。

最近、時々アプリケーションをクラッシュさせるマンデルバグを発見しました。一度再現してスタックトレースを取得したので、バグレポートを開きました。バグ自体は簡単に修正できます（バックグラウンドスレッドの1つでキャッチされないWeb例外により、CLRはプログラムを終了します）。

問題は、開発者がバグを修正することを拒否していることです。「彼はそれが存在することを確信していない」からです。残念ながら、上司は彼の側にいて、バグの存在を証明するための「堅実なテストケース」を作成し、ユニットテストでそれがなくなったことを確認しない限り、このバグは修正できないと言います。バグの性質上、基本的に不可能なこと。

何かアドバイス？

可能であれば、アプリケーションコードにスリープまたはブロックを設定することで、この欠陥を再現できるかどうかを確認するために時間をかけることができます。しかし、時間をかけすぎないでください。この問題はマルチヘッドによるものであるため（また、あなたが観察したように）、まれにしか発生しません。

私のアドバイスは、これにあまり汗をかかないことです。作業を続けます。このクラッシュに遭遇したときはいつでも、バグレポートをスタックトレースで更新し、これが繰り返し発生していることを伝え、所有者をライブラリ開発者に変更します。管理者/リードに、頻度に応じて修正するかどうかを決定させます。

また、開発者の考え方を理解するようにしてください。「キャッチされていないWeb例外」と言いました。この段階での開発者は、これを捕まえることによる他の影響が何であるか完全にはわからないかもしれません。そのため、彼/彼女はコードに触れたがらないかもしれません。

だから、あなたの多かれ少なかれ明確なコメントから、私はそれをこのように得ました：

単純な追加の例外処理が欠落しているだけで、libのどのコード行に問題があるか、libをどのように修正できるかはすでにわかっています。

それでは、自分でライブラリに不足している数行のコードを追加するだけで、チームに親切にその変更を加えてライブラリをテストするよう依頼してみませんか？それが低リスクの変更であることを確認し、ライブラリを担当する開発者が理解しやすいようにします。起こりうる最悪の事態は、修正によって何らかの予期しない動作が発生した場合に、VCSの変更を元に戻す必要があるということです。

ほとんどの人は、作業がすでに完了していると納得しやすくなります。また、「このコードは間違っていますが、どうにかして修正してください」とは対照的に、「ここに改善されたソリューションがあります」に対してよりよく反応します。

編集：開発者がまだその変更の追加を拒否している場合、最良のオプションは、ネットワークエラーをシミュレートする分離されたテストハーネス内で問題のあるコードを動作させることです。レガシーコードを効果的に使用するには、この種の問題に対処する方法に関する多くのテクニックを説明します。たとえば、問題のあるモジュールと機能のみを含むライブラリのテストバージョンを作成し、制御された条件下で「ネットワーク例外」をシミュレートできる「モック環境」を作成できます。それは一見、あまりにも多くの努力のように思えるかもしれませんが、そのような環境ができたら、多くの追加のテストを追加できます（そして、ライブラリの作者が行方不明の追加を拒否するとき一箇所での例外処理、

このようなバグの場合、自動ファズテスト（ランダムテストとも呼ばれます）は、再現を試みる際に役立つ場合があります。これは、テストするものに固定された一連のパラメーター（または入力）をランダム化することにより、バグを見つけるプロセスを自動化します。各テストの実行、パラメーターはタイムスタンプなどを含むログファイルに記録されるため、クラッシュが発生した場合、同じパラメーターを使用して（理論的に）テストを再生し、再現することができます。

テストプロセスは自動化されているため、短時間で多くのテストを実行できます。多くの場合、一晩実行したままにしておくことができ、午前中にログファイルをチェックして、クラッシュを再現したかどうかを確認できます。

悪魔の擁護者は別の道を提案します。

他の開発者は、そこにはバグはないと断言しています。

存在しないとされる彼のバグから地獄を強調し、それをより頻繁にクラッシュさせる方法を思いつくことができますか？

スタックトレースは、バグが存在するか、少なくとも特定のビルドに存在したという明確な証拠です。持っていないのは、バグが修正された証拠です。彼らはそれを無視するのは愚かです。顧客のシステムで毎回トリガーされる複数のシステムでの数十万回の自動試行の後に、「再現不可能な」バグが発生しました。

スタックトレースの恩恵さえほとんど受けずに、毎年そのようなバグが2つ発生します。ほとんどすべての場合、事前に再現することはできませんでしたが、修正後は簡単に自動テストを行うことができました。

たとえば、数か月前に、ユーザーが1分あたり96単語よりも速く入力したときにのみ発生するバグを修正しました。修正する前は、バグが「ときどき」発生したことしか知りませんでした。高速タイピングのためのユニットテストを書くことは決してありません。しかし、根本原因を知った後、それをテストするのは簡単でした。

バグを修正した後でも再現できないまれな場合でも、コード検査でバグを閉じることができます。