debugging - エラーを再現するために必要な手順を「再現」する

Question

数百人のコンサルタントが使用する典型的なビジネス アプリケーションを作成します。通常、コンサルタントには標準テキストのエラー メッセージが表示されます。アプリケーションは常に多くの変更が加えられる複雑なものになるため、次のことを希望します。

エラー メッセージが表示された場合、ユーザーはエラー メッセージを開発者に「送信」することができます。開発者は、受信ファイルを Eclipse などで開き、最後の 10 分間の作業のステップを段階的に (必要に応じて一度に 1 行ずつ) デバッグできる必要があります。すべてが透過的である必要があります。つまり、たとえば、データベースへの呼び出しの戻り値を確認できる必要があります。

今日、そのような機能を提供するソリューションはありますか。私の好みの言語は Python または Java です。このような機能が原因でパフォーマンスが大幅に低下することはわかっていますが、この種のソフトウェアはパフォーマンスに敏感ではないため、許容範囲内です。

アプリケーションで特定のコード行が実行され、バグにつながる正確な時間に存在する値をデータベースに照会できるように、データベースにも年表があれば非常に便利です。

Answer 1

ロギングを使用するようにしてください。たとえば、DBからのログのコミットや、アプリケーションとのユーザーインタラクションのロギングなどです。Webアプリケーションの場合は、Webサーバーのログファイルから開始できます。ログファイルには、パラメータを含む完全なGET URLやエンティティ本体を含むPOSTなど、送信されたすべてのデータが含まれていることを確認してください。必要に応じてこのようなログを生成するようにWebサーバーを構成できます。

次に、ログファイルを解析し、問題が発生する原因となったすべてのユーザー操作を再作成できるテストクライアントを構築します。競合状態が疑われる場合は、高精度（msの解像度）でログに記録し、テストクライアントが同じシーケンスを何度も実行して、これらの重要な部分にストレスをかけることができることを確認する必要があります。

（タイトルが示すように）リプレイはエラーを再現するための最良の方法です。特定の状態/状況を生成した入力を再現するために必要なすべてのデータを収集するだけです。内部構造と戻り値に焦点を当てないでください。エラーやバグを追跡する場合は、フォレンジックモードで作業するべきではありません。たとえば、難破船を分析してクラッシュの原因を分析しようとすると、飛行機をクラッシュさせてもう一度繰り返して、ログを追加するか、問題が発生することがわかるまでデバッガーを使用します。