it-swarm.com.de

Sollte "zwischen x und y" kommutativ sein?

In meiner Anwendung gibt es einige vordefinierte Ausdrucksvorlagen, mit denen Daten gefiltert werden können. Einer von ihnen ist "between x and y ". Ein QS-Ingenieur behauptet, dass es einen Fehler in seiner Definition gibt, weil" between 100 and 200 "liefert andere Ergebnisse als" between 200 and 100 ". Der Ausdruck wird intern in" value >= x and value <= y ", daher gibt es offensichtlich keine Ergebnisse, wenn die zweite Grenze niedriger als die erste ist. Ich habe überprüft, dass das gleiche Verhalten in SQL vorliegt -" between x and y "geht davon aus, dass y> = x ist oder keine Ergebnisse vorliegen. Dies bedeutet, dass der Operator zumindest in SQL nicht kommutativ ist.

Ist die Qualitätssicherung also richtig, dass "between x and y "sollte kommutativ sein?

26
pkalinow

Wenn Ihre aktuelle Spezifikation dies undefiniert lässt, ist das Verhalten völlig willkürlich, es gibt keine "richtige" oder "falsche" Definition. Wenn Ihr QS-Techniker Sie also nicht auf den genauen Absatz in der Spezifikation verweisen kann, in dem dieses Verhalten definiert ist, können Sie seine Anfrage wahrscheinlich ablehnen (obwohl dies keine Anforderung zu sein scheint, deren Implementierung viel Aufwand erfordert). Wenn Sie beide keinen Konsens finden, muss eine Person in Ihrem Team eine Entscheidung treffen, was im Zusammenhang mit der Bewerbung wichtiger ist:

  • befolgen Sie den SQL-Standard so genau wie möglich
  • nichteinhaltung aufgrund von Ergonomie, spezifischen Anwendungsfällen oder anderen Anforderungen

Unabhängig davon, welche Entscheidung Ihr Team trifft, ist es möglicherweise eine gute Idee, das Verhalten und den Grund für die Entscheidung zu dokumentieren.

32
Doc Brown

Dies ist eine Frage zur Benutzerfreundlichkeit oder Benutzererfahrung. Wie sich SQL oder ein anderes System verhält, spielt keine Rolle. Die Frage ist, was aus Anwendersicht am sinnvollsten ist.

Das aktuelle Verhalten ist aus Anwendersicht nicht sinnvoll. Entweder x und y sollten austauschbar sein oder es sollte nicht erlaubt sein, ein x größer als y auszuwählen. Wenn x größer als y ist, aber ein leerer Satz zurückgegeben wird, besteht eine unnötige Möglichkeit von Fehlern, ohne dass dies Vorteile bringt.

Der QS-Techniker hat also Recht, dass ein Defekt vorliegt, aber die vorgeschlagene Lösung ist nicht unbedingt die beste. Sie müssen Usability-Tests durchführen, um dies zu entscheiden, oder zumindest einige repräsentative Benutzer fragen, was ihnen am natürlichsten erscheint.

Alternativ können Sie die Frage unter https://ux.stackexchange.com/ stellen. Die Leute dort wissen tatsächlich ein oder zwei Dinge über die Benutzererfahrung.

13
JacquesB

Es gibt einige sinnvolle Möglichkeiten, und die Auswahl hängt vom Rest des Systems und den Erwartungen Ihrer Benutzer ab.

Sie können, wie der QS-Ingenieur betont, den Ausdruck einfach kommutativ machen, und dann wäre die Übersetzung

between x and y => value >= min(x, y) and value <= max(x, y)

Sie können die gültige Verwendung auf x <= y Beschränken. Dies erfordert vielmehr, dass Ihre Benutzeroberfläche so früh wie möglich "Das ist kein gültiger Ausdruck" anzeigt.

Als Variation des oben Gesagten gilt die Einschränkung x < y, Wenn Sie einen Ausdruck equals x Haben und diesen der Auswertung von value >= x and value <= x Vorziehen.

11
Caleth

In einer nicht interaktiven Umgebung, in der Ihre Grenzen durch ein Skript erstellt werden, ist es normalerweise sinnvoll, zu verlangen, dass sie in Ordnung sind. Dies führt zu einer Validierungsprüfung weniger, ist semantisch sinnvoller und trivial zu verwalten.

In einer interaktiven Umgebung möchten Sie dem Benutzer helfen. Erstellen Sie nach Möglichkeit eine grafische Benutzeroberfläche, über die keine vertauschten Bereiche eingegeben werden können, oder machen Sie es zumindest so einfach wie möglich, Bereiche nacheinander einzugeben. Wenn Sie die Bereiche per Text eingeben, nehmen Sie eine Seite aus vim, dem Inbegriff der Benutzerfreundlichkeit, und fordern Sie den Benutzer auf, automatisch invertierte Bereiche auszutauschen:

Backwards range given, OK to swap (y/n)?

Wenn Ihr QS-Techniker UX nichts im Wege hätte, um ihm zu zeigen, dass ein invertierter Bereich unerwünscht wäre, hat er eine vernünftige Annahme getroffen.

5
Karl Bielefeldt

Offen? Verwenden Sie nicht "zwischen". Überhaupt.

Erstens ist der Begriff unglaublich mehrdeutig, insbesondere auf Englisch. Ist es kommutativ? Sind die Bedingungen exklusiv? Inklusive?

Zweitens: Wenn Sie eine vom Backend getrennte Schnittstelle verwenden, machen Sie sich keine Sorgen über das Backend-Verhalten. Lassen Sie Ihre Benutzer auch kein ererbtes Verhalten annehmen. Sicher, SQL definiert sein BETWEEN als inklusive, aber dies ist fast nie das gewünschte Verhalten (zum Beispiel - Wenn Sie so etwas wie rows BETWEEN :start and :start + :stride Tun, erhalten Sie stride + 1 Zeilen ).

Stattdessen sollten Sie die Vergleiche für die Endpunkte explizit auflisten. "Größer als oder gleich x". "Gestern". Dies beseitigt die Mehrdeutigkeit. Es hilft auch dabei, saubereren Code zu schreiben und heimtückische Fehler zu vermeiden. Das Zeilenbeispiel von früher ist im Wesentlichen Djikstras Beitrag über die Indizierung . Und SQL kann für einige Typen eine inklusive Obergrenze verwenden kann dazu führen, dass die falschen Daten ausgewählt werden .

2
Clockwork-Muse

Ich werde ein UNIX-Prinzip entwickeln, das sich mit einfachen Schnittstellen befasst.

Wo immer es eine Schnittstelle gibt, die Sie der Außenwelt anbieten, halten Sie das Ding so wenig überraschend wie möglich!

Nachdem ich die Problemstellung auf eine pragmatischere reduziert habe, werden Sie wahrscheinlich nur wenige Augenblicke brauchen, um zu erkennen, dass es bei der Angabe von Zahlenbereichen nur offensichtlich ist, die kleinere als die erstere beizubehalten. Wenn es immer noch ein Rätsel ist, denken Sie so: Wie oft haben Sie die umgekehrte Darstellung von zwei Zahlen verwendet, während Sie Kindern gesagt haben, wie sie diese vergleichen sollen?

Wenn Ihr QS-Ingenieur es einen Fehler nennt, sagen Sie ihm höflich, dass Sie einige echte Fehler erwarten und keine Möglichkeiten, kostspielige Energie auf triviale Dinge zu übertragen.

1
an4

Es ist nicht produktiv, mit Ihrer Qualitätssicherung darüber zu streiten, wer "richtig" und wer "falsch" ist. Sie haben die Spezifikation anders interpretiert als sie. Dies bedeutet, dass die Spezifikation so vieldeutig ist, dass eine Klärung erforderlich ist.

Wenn die Benutzeroberfläche die Spezifikation ist und es nicht das Verhalten ist, das die Qualitätssicherung erwartet, wird es nicht das Verhalten sein, das zumindest einige Benutzer erwarten. Dies weist auf ein Usability-Problem hin (auch wenn Sie PEBKAC argumentieren möchten). Arbeiten Sie mit Ihrer Qualitätssicherung zusammen, um eine zufriedenstellende Lösung dafür zu finden.

Seien Sie im Allgemeinen vorsichtig mit Wörtern wie "zwischen", die klar erscheinen, aber nicht klar sind. Abgesehen von Ihrer Uneinigkeit darüber, ob es pendeln soll, gibt es Probleme mit der Inklusivität an beiden Enden und kann intuitiv unterschiedliche Dinge auf verschiedenen Domänen bedeuten (zum Beispiel bedeutet "zwischen Freitag und Montag" für die meisten Menschen etwas anderes als "zwischen Montag und Montag" Freitag")

1
Martijn

Lassen Sie Ihren Debug-Code eine Fehlerbedingung auslösen oder protokollieren Sie eine Warnung, wenn die Werte in falscher Reihenfolge übergeben werden. Auf diese Weise kann der aufrufende Code bei Bedarf Parameter überprüfen und austauschen. Auf diese Weise werden Benutzer dieser 'Funktion' darauf aufmerksam und tun das Richtige (was Sie vorher nicht wissen).

0
Grimaldi