「xとyの間」は可換である必要がありますか？

私のアプリケーションには、データのフィルタリングに使用できる定義済みの式テンプレートがいくつかあります。それらの1つは " between x and y"です。QAエンジニアは、「between 100 and 200」とは異なる結果が得られるため、その定義に欠陥があると主張していbetween 200 and 100ます。式は内部的に " value >= x and value <= y"に変換されるため、2番目の境界が最初の境界より低い場合、結果は明らかにありません。同じ動作がSQLにもあることを確認しました-" between x and y"はy> = xであるか、結果がないと仮定しています。これは、少なくともSQLでは演算子が可換ではないことを意味します。

それでは、QAは、「between x and y」が可換であるべきだと思いますか？

現在の仕様でこれが定義されていない場合、動作は完全にarbitrary意的であり、「正しい」または「間違った」定義はありません。したがって、QAエンジニアが、この動作が定義されている仕様の正確な段落を示すことができない場合は、おそらく彼の要求を拒否できます（ただし、それを実装するのに多くの努力を必要とする要件ではないようです）。両方がコンセンサスを見つけられない場合、チームの1人がアプリケーションのコンテキストでより重要なものを決定する必要があります。

• SQL標準に可能な限り従う
• 人間工学、特定のユースケース、またはその他の要件のためにそれに従わない

チームがどのような決定を下しても、その行動と決定が行われた理由を文書化することをお勧めします。

これは、使いやすさまたはユーザーエクスペリエンスに関する質問です。SQLまたは他のシステムの動作は無関係です。ユーザーの観点からすると、問題は何が最も理にかなっていますか。

現在の動作は、ユーザーの観点からは意味がありません。いずれかの XおよびYは互換でなければならないか、yよりも大きいXを選択することが許されるべきではありません。yより大きいxを許可し、空のセットを返すと、メリットが得られずにエラーの不必要な可能性が生じます。

そのため、QAエンジニアは間違いはありませんが、提案されたソリューションが必ずしも最適とは限りません。これを決定するには、ユーザビリティテストを実行するか、少なくとも一部の代表的なユーザーに最も自然なことを尋ねる必要があります。

または、https：//ux.stackexchange.com/で質問をすることができます。向こうの人々は、実際にユーザーエクスペリエンスについて1つまたは2つのことを知っています。

賢明な選択肢がいくつかあり、どちらを選択するかは、システムの残りの部分とユーザーの期待に依存します。

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が一部のタイプで包括的な上限を使用できるようにすると、誤ったデータが選択される可能性があります。

誰が「正しい」のか、誰が「間違っている」のかについてQAと議論するのは非生産的です。仕様を解釈したのとは異なる方法で解釈しました。つまり、仕様は十分に曖昧であるため、明確化が必要です。

ユーザーインターフェイスが仕様であり、QAが期待する動作ではない場合、少なくとも一部のユーザーが期待する動作ではありません。これは、使いやすさの問題を示しています（PEBKACについて議論したい場合でも）。QAと協力して、満足のいく解決策を見つけてください。

一般的なポイントとして、はっきりしているように見えるがそうではない「間」のような言葉には注意してください。通勤すべきかどうかについてのあなたの意見の相違は別として、それらは両端の包括性の問題であり、直感的に異なるドメインで異なることを意味する場合があります（たとえば、「金曜日と月曜日の間」は「月曜日と金曜日"）

単純なインターフェースについて話すUNIXの原則を分岐します。

あなたが外の世界に提供しているインターフェースがあるところはどこでも、できる限り驚くことのないものにしてください！

問題のステートメントをより実用的なものに減らしたので、番号範囲を指定するときに、小さい方を前者として保持することは明らかですが、少し時間がかかると思います。それでも難問である場合は、このように考えてください。2つの数字を逆の方法で表しながら、それらを比較する方法を子供に何回使用しましたか。

QAエンジニアがバグと呼んでいる場合は、些細なことに高価なエネルギーを投じる方法ではなく、実際のバグを期待していることを丁寧に伝えてください。

間違った順序で値が渡されるたびに、デバッグコードでエラー状態をスローしたり、警告をログに記録したりします。このようにして、必要に応じて、呼び出し元のコードがパラメーターを確認および交換できます。このようにして、この「機能」のユーザーは気づき、正しいことを行います（事前に知りません）。