「xとyの間」は可換である必要がありますか？
私のアプリケーションには、データのフィルタリングに使用できる定義済みの式テンプレートがいくつかあります。それらの1つは「between x and y」です。 「between 100 and 200」は「between 200 and 100」とは異なる結果をもたらすため、QAエンジニアはその定義に欠陥があると主張しています。式は内部的に "value >= x and value <= y"に変換されるため、2番目の境界が最初の境界よりも低い場合、結果は明らかにありません。同じ動作がSQLでも発生することを確認しました-「between x and y」はy> = xであるか、結果がないと想定しています。つまり、少なくともSQLでは、演算子は可換ではありません。
それで、「between x and y」は可換的であるべきというQAの権利は正しいのでしょうか？
現在の仕様でこれが未定義のままの場合、動作は完全に恣意的であり、「正しい」または「間違った」定義はありません。したがって、QAエンジニアがこの動作が定義されている仕様の正確な段落を指摘できない場合は、おそらく彼の要求を拒否できます（ただし、それを実装するために多くの労力を必要とする要件ではないようです）。両方が合意を見つけることができない場合、チームの1人がアプリケーションのコンテキストで何がより重要であるかを決定する必要があります。
- sQL標準にできる限り厳密に従う
- 人間工学、特定の使用事例、またはその他の要件のためにそれに従わない
チームがどのような決定を下しても、行動とその決定がなされた理由を文書化しておくとよいでしょう。
これは、ユーザビリティまたはユーザーエクスペリエンスの質問です。 SQLやその他のシステムの動作は重要ではありませんが、問題はユーザーの観点から最も意味のあるものです。
現在の動作は、ユーザーの観点からは意味がありません。 Eitherxとyは交換可能にする必要があります。または、yより大きいxを選択することはできません。 xがyより大きくても空のセットが返されるようにすると、不必要なエラーが発生する可能性があり、メリットはありません。
したがって、QAエンジニアは正解です。欠陥はありますが、提案されたソリューションが必ずしも最良であるとは限りません。これを決定するユーザビリティテストを実行する必要があります。または、少なくとも一部の代表的なユーザーに、彼らにとって最も自然に見えるものを尋ねます。
または、 https://ux.stackexchange.com/ で質問することもできます。そこにいる人々は実際にユーザーエクスペリエンスについて少し知っています。
いくつかの賢明な選択があり、どちらを選択するかは、システムの残りの部分とユーザーの期待に依存します。
QAエンジニアが指摘するように、式を可換式にすれば、翻訳は次のようになります。
_between x and y_ => value >= min(x, y) and value <= max(x, y)
有効な使用を_x <= y_に制限できます。これは、UIが「有効な式ではない」をできるだけ早く表示できることを要求します。
上記のバリエーションとして、式_x < y_があり、それが_equals x_の評価よりも優先される場合の制限_value >= x and value <= x_
境界がスクリプトによって作成される非インタラクティブな設定では、通常、境界が正しいことを要求するのが理にかなっています。これにより、実行する必要がある検証チェックが1つ少なくなり、意味的に理解しやすくなり、管理が簡単になります。
インタラクティブな設定では、ユーザーを支援する必要があります。可能であれば、入れ替えた範囲の入力を許可しないGUIを作成するか、少なくとも順番に範囲を入力することを可能な限り簡単にします。テキストで範囲を入力する場合は、vimからページを取得します。これは使いやすさのパラゴンであり、反転した範囲を自動的に入れ替えるようにユーザーに指示します。
Backwards range given, OK to swap (y/n)?
QAエンジニアがUXの方法で反転範囲が望ましくないことを示すものがなかった場合、彼は合理的な仮定を行いました。
率直に言って？ 「間」を使用しないでください。全然。
まず、特に英語では、この用語は非常にあいまいです。それは可換ですか？条件は排他的ですか？含む？
次に、バックエンドから切り離されたインターフェイスを使用している場合、バックエンドの動作について心配する必要はありません。また、ユーザーに継承された動作を想定させないでください。確かに、SQLはそのBETWEENを包括的に定義していますが、これはほとんど望ましい動作ではありません（たとえば、rows BETWEEN :start and :start + :strideを取得しますstride + 1行）。
代わりに、エンドポイントの比較を明示的にリストする必要があります。 「x以上」。 「今日の前」。これにより、あいまいさが取り除かれます。また、よりクリーンなコードを記述し、陰湿なエラーを回避するのにも役立ちます。以前の行の例は基本的に Djikstraのインデックスに関する投稿 です。また、SQLで一部の型に包括的な上限を使用できるようにする 誤ったデータが選択される可能性があります 。
シンプルなインターフェースについて語るUNIXの原則をフォークします。
外の世界に提供しているインターフェイスがある場合は常に、できるだけ驚かないようにしてください！
問題のステートメントをより実用的なものに減らしたので、数値の範囲を指定するときに、小さい方を前者として***保持することは明らかですが、少し時間がかかると思います***。それでも難問である場合は、次のように考えてください。子供にそれらを比較する方法を教えながら、2つの数値を表す逆の方法を何回使用しましたか？
QAエンジニアがバグと呼んでいる場合は、いくつかのrealバグを予期していることを丁寧に伝えてください。
誰が「正しい」か、誰が「間違っている」かについてQAで議論することは非生産的です。あなたは彼らがしたのとは異なって仕様を解釈しました。つまり、仕様が曖昧であるため、明確にする必要があります。
ユーザーインターフェイスが仕様であり、それがQAが期待する動作ではない場合、少なくとも一部のユーザーが期待する動作になることはありません。これは、（PEBKACについて議論したい場合でも）ユーザビリティの問題を示しています。 QAと協力して、それに対する満足のいく解決策を見つけてください。
一般的なポイントとして、明確に見えるが明確ではない「間」のような単語には注意してください。通勤する必要があるかどうかについてのあなたの意見の相違は別として、それらはどちらかの側での包括性の問題であり、異なるドメインで異なる意味を直感的に意味する場合があります（たとえば、「金曜日と月曜日の間」は、「月曜日と月曜日の間」とは異なるものを意味します金曜日"）
誤った順序で値が渡されるたびに、デバッグコードにエラー条件をスローさせるか、警告をログに記録させます。このようにして、呼び出しコードは、必要に応じてパラメーターを確認および交換できます。このようにして、この「機能」のユーザーは気づき、正しいことを実行します（これは事前にわかりません）。