データベースを読み取り、満たされていない依存関係にアラートを出力するアプリケーションがあります。この問題についての私の考えは、「ユーザーに問題を指摘するための最小限の情報を提供すること」です。私は同僚から、「フィールド1はフィールド2よりも小さい必要がある」という最小限のメッセージを与える詩に言及する各フィールドのデータベースフィールドの値を印刷して、できるだけ詳細にする必要があると言われました。
コンパイラのエラーと警告を思い出させるので、この問題には何らかの規則または標準が必要であることを私は知っています。コンパイラメッセージがどのように選択されるか知っている人はいますか？
コミュニティはこの問題についてどのような提案をしていますか？
重要なのは簡潔にすることだと思います。警告が通知される理由に必要なだけ詳細を入力し、それ以上は何も入力しないでください。
書くときは、聴衆を知ってください。
自分で消費するために警告/エラーメッセージをログに記録している場合、それはかなり簡単です。何か問題が発生したときに何を知る必要がありますか？
他の誰かへの警告/エラーメッセージをログに記録している場合、物事はトリッキーになります。彼らは何を知っていますか？システムの彼らのメンタルモデルはどのように見えますか？彼らはどのような問題を解決でき、それらを解決するためにどのような情報が必要ですか？
データの最後のスクラップをすべてメッセージにプッシュすることはパントです-せいぜい、読者は彼らが必要とするものを見つけるために無関係な情報を通り抜けなければならないでしょう。最悪の場合、彼らは混乱し、間違ったデータに基づいて決定を下すことになります。
コンパイラの例えは適切です。すべての警告とともにシンボルテーブル全体がダンプされた場合、それがどれほど迷惑になるかを考えてください...
通常の日常業務では、ユーザーが問題を修正できるように十分な情報を提供するデータ検証メッセージを提供して、データを検証します。たとえば、2 つのフィールド (fieldA と fieldB) があり、そのうちの 1 つが他のフィールドよりも大きくなければならない場合、検証出力で、どのフィールドが問題のフィールドであるかを指定します。
たとえば、A が B よりも大きくなければならず、B よりも小さい回答を提供する場合、メッセージは「fieldA は fieldB より高くする必要があります」となります。
とは言うものの、私はアプリケーション (特に Web アプリケーション) にデバッグ モードをプログラムし、詳細モードを備えており、すべてで何が起こっているかを正確に伝えます。これがオンになっている場合、ユーザー フレンドリーなエラーと、「FieldA=XX and FieldB=YY: XX is not greater than YY」という 2 つのメッセージが表示されます。
これは単純化されていますが、一般的な考え方です。
両方のモードを実装することをお勧めします。通常の操作では、役立つが短いメッセージが必要です。しかし、場合によっては問題が発生する可能性があります。この場合、ユーザーにすべての可能な情報を提供する「ダンプ」モードは、命の恩人です。
3 つの典型的なユーザー グループのエラー メッセージの詳細には 3 つのレベルがあると思います。
ログの内容の詳細については議論することができますが、冗長性のレベルはストレス テスト中にすぐに判断されるというのが私の経験です。
システムが正常に機能しない場合、それは次の理由によるものです。
Atwood : 私たちは、ログ呼び出し中のログが別のログ呼び出しをトリガーするような方法でログを記録していました。これは通常は問題ありませんが、私たちが持っている負荷では、最終的には非常に接近して発生し、ロックも発生します. つまり、そこには 2 つのロックがかかっています。
Spolsky : [...] あなたはすべてをログに記録したい傾向があります。しかし、ユーザーごとに 100 メガバイトのログが取得され、1 分間に 30 のログが取得され、適切な方法で分析または保存できない可能性があります。したがって、次に行う必要があるのは、ログの選別を開始するか、さまざまなレベルのデバッグを行うことです。高デバッグ モードではすべてがログに記録され、低デバッグ モードでは何もログに記録されません。そして... ログに本当に必要なものを理解するのはちょっと難しいです。
Atwood : 皮肉なことに、ロギングが原因であることが判明したこのハングをトラブルシューティングするために、さらにロギングを追加していたのです。
スポルスキー：（笑）
アトウッド: ジョークはただ書いているだけです。冗談はそれ自体を書くだけですよね...
要点は、システムを本番環境のような環境で実行する場合、選択した冗長性のレベルが持続可能かどうかをすぐに判断できるはずだということです。
エラーへの対処対。最初の警告：エラーは、標準に違反するものに対するものである必要があります。警告は許可されているものに対して行う必要がありますが、作成者が意図したものではない可能性があります。
たとえば、W3C Markup Validatorは、HTMLドキュメントでの構文<br/>の使用について警告します。XHTMLでは、これは「改行」を意味しますが、HTMLドキュメントでは、許可されている間は、実際には「改行の後に大なり記号が続く」ことを意味します（ほとんどのブラウザーがこれを尊重しない場合でも）。
冗長性に関しては、誰がシステムを使用しているかによって、何が最善かによって異なります。一部のユーザーは、ざっと目を通すことができる短いメッセージを使用したほうがよいでしょうが、他のユーザー（おそらくあまり進んでいないユーザー）は、追加情報が役立つと思うでしょう。彼らが誰であるかをもっと知らなくても、私はフラグ（-vは伝統的です）を使用して、ユーザーが好みのバージョンを選択できるようにする傾向があります。