web-dev-qa-db-ja.com

「失敗/成功」よりもOK / NOKの方が良い

私のチームは、特定のアクションが成功で終わったかどうかを、ログブックでどのように示すべきかについて話し合っています。入れ始めた

timestamp | action name (fail)    | description
timestamp | action name (success) | description

チームメンバーの1人が、失敗/成功をOK/NOKに置き換えることを提案しました。

timestamp | first action name (OK)    | description
timestamp | 2nd action name (NOK)     | description

読みやすさを向上させると彼が言わなかったとしても、私はそのような詳細を気にしません。疑わしい：

  1. OKとNOKは66％に相関しているため、多くのテキストをすばやく処理すると、NOKとOKが混同される可能性があります。逆に、failはsuccessとの相関が0です。
  2. failにはさまざまな文字の高さがあり、successにはないため、見た目が大きく異なります。

私は正しい方向に考えていますか？そのような詳細について読むことができるリソースはありますか？コックピットや原子力発電所の制御室の設計では、このようなことはよく知られているはずです。

readability
43
texnic

最大の問題は、テキストの大きなグループ内でステータスインジケーターを見つけることができることです。

いくつかの重要な技術的制限を除いて、私はあなたの解決策は各アクションのステータスをそれ自身の列に表示することであるべきだと思います。

これにより、正確な用語についてのあなたの質問は

  • 可視性のために用語の重要性を減らす
  • ステータスを一貫した場所に表示する明確でスキャンしやすい列を提供する

しかし、実際にあなたの質問に答えるために、この情報を表示している正確なコンテキストを考慮せずに、「失敗/成功」のペアを使用します。

24
maxathousand

出力がバイナリ（成功/失敗、OK/NOKなど）の場合、なぜ失敗状態のステータスだけを表示しないのですか？

timestamp | action name           | description
timestamp | action name           | description
timestamp | action name (FAILED)  | description
timestamp | action name           | description

編集：

元の質問に対するコメントの一部では、エラーをすばやくスキャンして見つける機能が望まれていると述べています。その場合、列を追加することをお勧めしますが、それでも失敗したケースのみを表示します。

例えば：

  | timestamp | action name           | description
  | timestamp | action name           | description
! | timestamp | action name (FAILED)  | description
  | timestamp | action name           | description
126
Harrison Paine

調査する必要があるのは、プロジェクトログブックのコンテキスト内でのこれらの用語の使用例です。私はここで推測する必要がありますが、ログブックはプロジェクト管理ツールです-進捗状況をグラフ化したり、問題/ブロッカーを発見したりするのに役立ちます

「NOK」は一般的に理解されている用語ではありません。これは、規模、病気のカバーなどの理由でチームに参加する人、およびプロジェクトを監査するチーム外の人がこの用語を説明する必要があることを意味します。一方、「成功」と「失敗」は、英語を読むことができるすべての人にとって完璧な意味があります。

2つの状態のどちらか一方の可視性を向上させたい場合は、リスト内の失敗したアイテムの横に図形を配置するなど、非言語的な解決策を探すことをお勧めします。

36
Andrew Martin

考慮すべき2つのこと：

コンピューティングでは、単に失敗するのではなく、failureを使用するのが一般的です。それらが最終的に同じ幅になる間隔のフォント（注意：「警告」も同じ文字数です）これに加えて、一部のシステム（Linux/Unixなど）は単語に色を付けます-失敗は通常赤に、成功は通常緑/青に色分けされます。したがって、これらのシステムでは、単語の[類似性]の類似性や、警告やエラーの識別に役立つ同じ文字幅を持っているという事実ではなく、失敗の識別に役立つ色です。

単語の色付けは、コックピットの実際のアビオニクス機器で使用されている航空宇宙産業で見た1つの手法です。

成功、失敗、警告が同じ長さであるということは、ログメッセージが各行の同じ場所から始まることを意味します。例えば：

timestamp | action | FAILURE | message/description
timestamp | action | WARNING | message/description
timestamp | action | SUCCESS | message/description

読みやすさで多くの人を助けることができます。最初の3列がすべて同じ幅であれば、簡単に無視できます。そして、障害/警告を特定したら、人間にとって最も重要な列はおそらくメッセージ/説明です。アクションは重要かもしれませんが、エラーメッセージが表示される場合は、通常、実行されているアクションに関係なく、何をすべきかについての手掛かりが得られます。各ステータスが異なる幅である、この[少し考案された]反例を考えてみましょう：

timestamp | action | fail | message/description
timestamp | action | successful | message/description
timestamp | action | warning | message/description

数十行または数百行でそれを確認することを考えてください。どこに注意を集中する必要があるかを理解するのは困難です。もちろん、ステータスフィールドにスペースを埋め込むという簡単な修正がありますが、ステータス列のWordの幅（現在のジレンマのようです）に基づいて、見分けやすいステータスに陥る可能性があります。

少なくとも航空宇宙業界では、ステータスを示すために「GO/NO-GO」の使用を見てきました。 NO-GOは、NOKに類似したNOGOまたはNGOとして表すこともできます。これははるかに広く知られており、使用されており、初心者にはわかりやすいと私は主張します。そして、それは多くのコメント者の懸念を和らげ、いくつかの回答はより珍しい「NOT OK」/「NOK」で指摘しました。

だから、私はおそらくすべてのことを少しずつ行うでしょう-Andrew Martinの answer を取り、記号を使用し、文字に色を付け、スペースを埋めて、あなたが（人間として）読んでほしい実際のメッセージをすべて揃っています。もちろん、これはすべて、私たちが話しているUI /フォーマットの種類に依存します-ターミナル？テキストファイル？リッチテキストファイル？ HTML？等

18
Shaz

合格/不合格を使用できます。これは、単語の見た目を変えるという条件を満たしますが、文字数が同じになるという利点があります。

timestamp | action name (fail) | description
timestamp | action name (pass) | description
3
BlueMeanie

私はこのスレッドが古いことを知っていますが、誰かがこれが便利だと思った場合は、どこから来たのか、どの分野で働いているのかわかりませんが、私の分野（産業オートメーション）では、OK/NOKが事実上の標準ですヨーロッパ。同僚が自動化で働いていた場合、それは彼が慣れていることかもしれません。ただし、これらは主にカラー画面に表示され、通常は緑/赤の色を伴うことを指摘しておきます。プレーンテキストログでは、顧客が特に指定しない限り、私は間違いなく別の方法を選択します。おそらくハリソンペインが提案したもの-OK結果のテキストなし、およびOK結果の必要なもの。

1
user3449440

おそらく、あなたの同僚は冗長性のために読みやすさについて話していると思います。つまり、彼は成功を望んでいない/説明を読みにくくすることに失敗している

それでは、(!)失敗の場合、成功の場合は何もない

timestamp | first action name       | description
timestamp | 2nd action name (!)     | description

説明する必要があるため、これは初めてのユーザーには使用できません。ただし、これはログファイルなので、基本的なユーザーがそれを見るとは思わないでしょうが、開発者はこれを理解し、一度知らされたらすぐに覚えておいてください。

少なくとも、これにより同僚がNOKから外れる可能性があり、途中でバイトを節約できます。

編集：これは、これが @ Andrew Martinの回答に多少似ていることを発見しました

1
icc97

その理由は心理的で、読みやすさとは関係ないと思います。

NOKではなく、NOKは、FAIL、FAILURE、またはERRORよりもはるかに厳しい音ではありません。これは、これらの「否定的な」言葉を使わなくてもよい方法の1つにすぎません。

私の意見では、あなたはびくびくすべきではありません。

1
Pieter B

さらなる検討事項として、「OK/NOK」は明らかにバイナリであり、2つの可能性のみを許可します。 「成功」と「失敗」により、さらに明確な可能性が生まれます-「警告」はすでに3番目の状態として説明されています。前提条件が間違っている場合は「実行できませんでした」、テストが開始されたが「通信エラー」が発生した場合データを取り戻すことができなかった、または...

1
Graham

ログファイルを確認する場合、2つの非常に重要な点があります。最初に問題（または情報）をすばやく見つけ、その情報を検索できるようにします。

timestamp STATUS Action Details of the log entry 
timestamp STATUS Action Details of the log entry
timestamp STATUS Action Details of the log entry

それはかなりうまくいくはずです。タイムスタンプとステータスが最も残されていることが重要です。 1つ目は整列が簡単なため、2つ目は最も重視するものだからです。 「午後6時頃の失敗」から始めます。したがって、午後6時のタイムスタンプまでスクロールして、障害を探し始めます。

次の問題は、ログファイルを検索する機能です。本当に悪い日がない限り、誰も/ var/log/syslogを読むことはありません。代わりに、tail itまたはgrep itのどちらかです。これを念頭に置いて、FAILとOKの外観を大きく変えたいと考えています。私は-OK-とFAILを好みます。繰り返しますが、これは些細なことではありませんが、より重要なのは、2つの違いが急速に変化した場合、それらの違いを目で確認できることです。それはtail -f /some/log/fileにとって重要です

また、grepingでうまく動作しますcat /some/log/file | grep FAILは非常にうまく動作します。 NOKとOKはできません。どちらも「OK」に一致します。

簡単に言えば、-OK-とFAILの管理者であれば、どこでも管理者に感謝します。

0
coteyr

「FAIL」の苛酷さを置き換えるだけの場合は、GO/NO GOをお勧めします。

「成功/失敗」に代わるものを提供することに加えて、それはあなたの会議に彼らにNASAのような感じを与えます。

0
Bob Stout

出力デバイスが色をサポートしている場合は、ステータスメッセージを横に表示するだけでなく、テキストを色分けすることもできます。そうすれば、実際にどのテキストが使用されていても、成功したものと失敗したものを簡単に確認できます。色情報をログファイルに保存する必要はありませんが、ログが表示されるときに動的に追加できます（これは、ログファイルがテキストビューアに表示されるか、カスタムのログビューアに表示されるかによって異なります）。

ただし、色覚異常のユーザーは赤と緑をはっきりと見ることができない場合があるので、使用する色を設定したり、代替の白黒バージョンを提供したりする方法があることを確認してください（つまり、ステータスメッセージだけでなく、色）。

0
Micheal Johnson