回答:
適切な入力検証の欠如は、ユーザーがアプリケーションで「悪い」ことを実際に処理する必要があるときに、ユーザーがすぐにアプリケーションに「悪い」ことを行う傾向があることの1つです。
ユーザーが次のようにトレーニングされているレガシーアプリを見てきました。
a-z0-9,emailフィールドに入力されていることを確認してください。そうでない場合、そのユーザーへの後続のメール送信はフィールドにあるものを使用して失敗しますhttp://」がWebアドレスの前にあることを確認してくださいなどなど
上記の問題はすべて、アプリケーション開発者が処理する必要がある問題です。入力検証が本質的に「このフィールドの形式をユーザーが知っていることを確認し、入力した内容が正しいことを信頼する」場合、予期しないことがアプリへの道を見つけることになります。セキュリティへの明らかな影響は別として、ユーザーは間違いを犯します。プログラマーとして、私たちはしばしば、後ろ向きに曲げることによって最高の製品を生産し、ユーザーがどんなに頑張ってもユーザーが間違いを犯さないようにします！
http://検証ポイントについても同様です。例として、ASDFこれを単純な方法で行います。その結果、を使用するドメインでパッケージをホストできなくなりますhttps://。
私のアプリが消えたばかりだったので、私はかつて顧客サポートの電話を受けました。彼らはその上に別のアプリを開いたことが判明しました。
...問題が発生したのはユーザーのコンピューターの非識字率であり、アプリではないため、これが再び発生しないことを保証しないことにしました。私がそれを修正するためにできることは、他の人にとってはユーザーエクスペリエンスの低下につながります。
私が書いたほとんどすべてのプログラムは、厳密にコマンドラインから呼び出されます。また、CLIインターフェースとして始まり、急速に成長して、何よりもシェルのようなものになるような、より奇抜なものをいくつか書いてきました。
ですから、私が知っていることだけを話すことができます。コマンドラインプログラムに関する一般的な問題を次に示します。
あまりにも多くのオプション
コンパイラまたはラインエディタを記述している場合を除き、80x25フレームバッファでは、--helpまたは/?渡すときにオプションを1画面に制限するようにしてください。それより多くのオプションがあるのは完全に問題ありませんが、それらをサブカテゴリに分割します。例えば
foo --help
foo --help option_name
長いオプションはありません
覚えるfoo --attach_to [argument] --volatile --verboseよりも覚える方がずっと簡単foo -a [arg] -v +Vです。これは常に可能とは限りませんが、ほとんどの場合、可能です。
入力検証なし
ほとんどすべてのプラットフォームには、引数の解析と検証に関して、試行、テスト、および検証された複数のライブラリがあります。ほとんどすべてのプラットフォームには、CLIからの入力を検証する、試行され、テストされた真のレクサーがあります。一方、他方、または両方を使用します。ユーザーが提供したものが原因でプログラムがセグメンテーション違反またはゼロで除算された場合、それはただ恥ずかしいことです。
レクサーほど複雑なものは必要ないかもしれません。おそらく、特定の場所にある特定のものと特定の順序のものを期待している場合は、文字列をトークン化することができます。
整数が予想され、誰かf*** my lifeが引用符で入力したところ、実際にバグレポートを受け取りました。私はそのプログラムを書きませんでした、それを継承するという不幸がありました。
「冗長性」ノブなし
経験豊富なユーザーは、ほとんどの人が許容するよりも多くのノイズをプログラムから取り除く方法を簡単に発見できますが、デフォルトでは深刻で重要なもののみを印刷します。straceNULLファイルストリームで動作しているために、セグメンテーション違反が発生したことを認識するために、何度起動する必要があるかはわかりません。
アサーションをラップして、NDEBUGまたはその他の方法でアサーションをオフにしても、ユーザーが検索できるように何かが印刷またはログに記録されるようにすることができます。
ログファイルについて言えば、ログファイルに配置するものはすべて、自分以外の人にとって（少なくとも少し）意味があることを確認してください。すべてのエントリの開始がUNIXエポックの日付である場合、バグの再現を本当に支援したい人に不満を抱かせます。
デバッグモードには「バグバディ」はありません
多くのプログラムは、プログラムで何が起こっているのかに関する余分なチャットを提供する「デバッグ」スイッチのようなものを提供しますが、以下を提供するものはほとんどありません。
または、電話で次のことを読んでいる人を聞くのが好きかもしれません。
ゼロeffで予期せぬ状態が発生したと言っています。
過度に複雑な構成ファイル
たくさんの構文糖衣の話題を得るための口実として設定を解析する必要性を正当化しないでください。構文解析時に余分な作業を意味する場合でも、人々が実際に知っている形式を使用するようにしてください。可能な限り、INIスタイル形式を使用しようとします。単純なkey-> value辞書で何ができるか驚くでしょう。
設定ファイルなし
プログラムを使用するためだけにシェルスクリプトやバッチファイルを作成させないでください。ただし、どちらのタスクのツールであることを目的としていません。私の通常のオプションを含むファイルをポイントし、いくつかの追加の引数を提供する手段を与えてください。
「ぬれた床」の兆候はありません
何らかの機能がユーザーをトラブルに巻き込む可能性がある場合（おそらく上級ユーザー向けです）、明確にそのようにマークしてください。さらに、誰かが太い指で入力したり、何かを忘れたりした場合は、オンラインドキュメントへの非常にわかりやすいリンクをプログラムで印刷してもらいます。KVMを介してプログラムを使用しており、カットアンドペーストできない人に対処している可能性があります。
可能であれば、（これは入力検証と一致します）Googleのアプローチを使用します：
foo --bar FILENMEを意味しますか、foo --barのみを入力しました
破壊的な指示から抜け出す方法を提供する
目標は、なぜ機能しなかったのかをユーザーに伝えて、さらに何回か試してもらい、ユーザーが本当にそれを望んでいるように見えない限り、潜在的に破壊的なことを何もしないようにすることです。たとえば、「しつこい」をオフにするスイッチを許可する-Yか/Y、そうでなければ、単に「太い指」を持っている人のために抜け道を許可します。
私はおそらくいくつかのポインターを忘れています。ほとんどの人が間違いを避けるのに十分な直観的な何かのための「低レベル」インターフェースを作るのは非常に難しいので、私はこれを頻繁に扱います。
「このファイル/レコードを削除してもよろしいですか？はい/いいえ」。[はい]をクリックし、赤い[削除]ボタンを「誤って」クリックしたという呼び出しがあり、そのデータが必要です:)
特定のブレーク/修正例を取得することは、これを実現することほど重要ではないと思います。
その調査を通して彼らが何かを壊すなら、プログラマーとして彼らに危険を警告するか、そもそもそれが起こるのを防ぐのはあなたの仕事です。今どこで見たのか思い出せませんが、心の奥底では常にソフトウェアのユーザーにとって「正しいことを簡単にする」ようにしています。
例にこだわる場合：
これがどこに行くのか見てください？:)
これが今週聞いたものです。ユーザーは、「イベントが発生したときに通知を送信する」機能を要求します。十分にシンプルで、開発者は先に進んで実装します。確かに、最初の質問は「この通知によって何に対処しようとしているのか？」でした。私はそれに行きません。数日後、ユーザーは開発者によって停止し、「この通知を受け取りました。どうすればよいですか？」と尋ねます。
私はこのDilbertコミックを思い出し、開発者に「ユーザーがその通知で何をすべきかを理解するためのアプリを書く」ことを提案しました。
mpetersonが言ったように、ユーザーは専門分野において非常に競争力があります。彼らはソフトウェア開発者やデザイナーのようには考えていません。
ユーザーが愚かであるとは思わない。彼らはあなたやプログラムをまったく使いたくありません。彼らが望むのは、物事を成し遂げることだけです。彼らを助け、途中で彼らに害が及ぶのを防ぎます。
優れたユーザーインターフェイスを備え、適切な学習体験を提供することは、ユーザーが悪いことをするのを防ぐことに大きく役立ちます。
優れたユーザーインターフェイスは、摩擦のないものでなければなりません。
削除を確認し、削除を実行し、元に戻す方法を提供するダイアログボックス（高価な操作であり、しばらくするとユーザーが無視する操作）を表示する代わりに。
優れたユーザーインターフェイスが発見できるはずです。
Microsoft Officeのリボンは、Wordの古いユーザーのやり方を変えることを余儀なくされるため、多くの欠点がありますが、リボンは、インターフェイスを発見可能（つまり、発見しやすい）にする方法の好例です。
優れたコードのような優れたユーザーインターフェイスは、一目瞭然です。
誰もマニュアルを読みません。ユーザーに読んでもらう唯一のマニュアルは、ソフトウェアの段階的な説明を含むPowerPointプレゼンテーションでした。Camtasiaなどのビデオツールを使用してこれらの処理を行ったことがありますが、PowerPointの方が簡単です。ステップを前後に簡単に切り替えることができるからです。
ユーザーは間違いを犯さないでください。間違いは、使用可能なインターフェースの作成に失敗したプログラマーにあります。
リリースごとにユーザビリティテストを行ってください！