Sollte "zwischen x und y" kommutativ sein?

26

In meiner Anwendung gibt es einige vordefinierte Ausdrucksvorlagen, die zum Filtern von Daten verwendet werden können. Einer von ihnen ist " between x and y". Ein QS-Ingenieur behauptet, dass es einen Defekt in seiner Definition gibt, weil " between 100 and 200" andere Ergebnisse liefert als " between 200 and 100". Der Ausdruck wird intern in " value >= x and value <= y" übersetzt, sodass es offensichtlich keine Ergebnisse gibt, wenn die zweite Grenze niedriger als die erste ist. Ich habe überprüft, dass das gleiche " between x and y" Verhalten in SQL vorliegt - " " vorausgesetzt, 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" kommutativ sein sollte?

pkalinow
quelle
11
Nein, aber vielleicht sollte deine Benutzeroberfläche rot werden, wenn jemand sie falsch ausfüllt.
Ewan
3
es sollte auch eines dieser> = <= exklusiv sein, damit Sie 100-> 200 200-> 300 usw. verketten können, ohne dass es zu Überschneidungen kommt
Ewan
23
Es ist nicht klar, ob betweendie niedrigeren und höheren Werte eingeschlossen oder ausgeschlossen werden sollen. Die QS-Person mag pedantisch sein, aber solange es Unsicherheiten gibt, muss jemand die User Stories / Anforderungen klären. Es könnte sich herausstellen, dass es so ist, wie es sein soll, aber eine Entscheidung muss getroffen werden.
Bent
11
Es geht nicht um richtig oder falsch. Es geht um Folgendes: Wie soll sich die Anwendung im Unternehmen verhalten? Die Antwort ist, welche Funktionalität erwartet wird. Technische Debatten treiben nicht die erforderliche Funktionalität voran. Die erforderliche Funktionalität treibt technische Debatten voran und inspiriert hoffentlich die beste Lösung für das Unternehmen.
Brad Thomas
2
Diese Frage bezieht sich mehr auf die Erwartungen des Benutzers als auf die Erwartungen eines Programmierers. Als solches wäre es für die Benutzererfahrung angemessener .
Makyen

Antworten:

32

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 Anforderung 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 entscheiden, was im Zusammenhang mit der Bewerbung wichtiger ist:

  • Befolgen Sie den SQL-Standard so genau wie möglich
  • Nicht befolgen 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.

Doc Brown
quelle
57
Sie können wahrscheinlich seine Bitte ablehnen => Ich würde eigentlich sagen, dass in erster Linie das Verhalten definiert werden sollte. Dann können Sie dem QA-Mitarbeiter dafür danken, dass er auf das Problem aufmerksam gemacht hat, und sagen, dass es jetzt so spezifiziert ist, dass es auf <bestimmte Weise> funktioniert (und stellen Sie sicher, dass der Code mit der Spezifikation übereinstimmt).
Matthieu M.
1
@MatthieuM. Ich denke, das ist eine separate Antwort, die 33 eigene Upvotes haben sollte. ;)
jpmc26
1
Konvertieren Sie Bug in Verbesserung und belassen Sie es für immer im Backlog. Vielen Dank für Ihre Sorgfalt.
Sandy Chapman
1
@MatthieuM. Ja, in einer idealen Welt würde es eine klare Anforderung für jedes Detail geben. In einem solchen Fall müsste ich keine Fragen zu Stack Exchange stellen :)
pkalinow
@pkalinow: Ich denke du hast meinen Kommentar falsch verstanden. Mein Punkt war, dass Sie vor dem Schließen des Fehlers (1) dem QA-Mitarbeiter dafür danken sollten, dass er auf einen nicht genau festgelegten Code hingewiesen hat, und (2) mit dem zusammensitzen sollten, der daran interessiert ist, das Verhalten tatsächlich zu spezifizieren. Dies kann bedeuten, dass Sie den QS-Bericht demjenigen zuweisen, der für das Verfassen der Spezifikationen zuständig ist, dem Product Owner, wenn Sie solche Dinge usw. haben. Sobald das Verhalten vereinbart wurde, können Sie bewerten, ob sich die Software ändern muss oder nicht. Vielleicht heißt es, die Software zu ändern, vielleicht heißt es, den Bericht zu schließen ...
Matthieu M.
13

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

Das aktuelle Verhalten ist aus Benutzersicht nicht sinnvoll. Entweder sollten x und y austauschbar sein, oder es sollte nicht erlaubt sein, ein x größer als y auszuwählen. Das Zulassen von x größer als y, aber das Zurückgeben eines leeren Satzes führt zu einer unnötigen 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 für sie am natürlichsten erscheint.

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

JacquesB
quelle
11

Es gibt ein paar sinnvolle Entscheidungen, die vom Rest des Systems und den Erwartungen Ihrer Benutzer abhängen.

Sie können, wie der QS-Ingenieur betont, einfach den Ausdruck 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 beschränken x <= y , was eher erfordert, dass Ihre Benutzeroberfläche so früh wie möglich "das ist kein gültiger Ausdruck" anzeigt.

Als Abwandlung des oben Gesagten gilt die Einschränkung, x < ywenn Sie einen Ausdruck haben equals xund diesen der Auswertung vorziehenvalue >= x and value <= x

Caleth
quelle
Hinweis: Bitte geben Sie die Erklärung nicht selbst ab value >= min(x, y) and value <= max(x, y). Berechnen Sie vorab, was Sie können, um Ihrem Datenbankserver die Arbeit zu ersparen, insbesondere wenn sie so redundant ist (Sie können die relevanten Vorgänge einmal ausführen und beide Ergebnisse entsprechend einstellen). Es spielt möglicherweise keine Rolle, abhängig vom Datenbankserver und den von Ihnen eingegebenen spezifischen Werten, aber ein schlecht geschriebener SQL-Server führt möglicherweise das minund maxfür jeden Datensatz aus, wenn Sie sie in das whereeinfügen und wenn Sie diesen Aufwand reduzieren können Es gibt keinen Grund, dies nicht zu tun.
Fund Monica's Lawsuit
6
Bitte hören Sie nicht auf QPaysTaxes - die Optimierung von Dingen, ohne jemals die Notwendigkeit zu messen, ist genau das, was Knuth als "vorzeitige Optimierung, die Wurzel allen Übels" bezeichnet hat. In den meisten realen Codes ist die Wahrscheinlichkeit hoch, dass Sie keinen Geschwindigkeitsunterschied bemerken, wenn Min und Max für jeden Datensatz berechnet werden. Durch die Vorberechnung von Werten (und die Einführung von zusätzlichem Code und zusätzlicher Redundanz) ist das Programm jedoch weitaus weniger wartbar.
Doc Brown
@DocBrown Ich bin damit einverstanden, dass wir keine Änderungen für potenzielle Leistungssteigerungen vornehmen sollten, ohne zu messen, aber entgegen Ihrer Behauptung würde ich vorberechnete Grenzen besser lesbar finden als einen Einzeiler und daher besser wartbar.
Jacob Raihle
@JacobRaihle: das mag meinungsbildend sein, ist aber für meinen geschmack value >= min(x, y) and value <= max(x, y)so lesbar wie value >= minXY and value <= maxXY, wo minXYund maxXYsind die vorberechneten grenzen. Für letztere muss man jedoch Code schreiben, um diese beiden neuen Variablen zum System hinzuzufügen. Füllen Sie diese zuvor aus, und vergessen Sie nicht, diese Werte zu aktualisieren, wenn sich x und y ändern, und so weiter. Redundante Daten bergen immer ein gewisses Fehlerrisiko.
Doc Brown
5

In einer nicht interaktiven Umgebung, in der Ihre Grenzen durch ein Skript erstellt werden, ist es in der Regel sinnvoll, deren Reihenfolge zu fordern. Dies führt zu einer einzigen Überprüfung, die semantisch sinnvoller und trivial zu handhaben ist.

In einer interaktiven Umgebung möchten Sie dem Benutzer helfen. Erstellen Sie nach Möglichkeit eine GUI, die die Eingabe vertauschter Bereiche nicht zulässt, oder machen Sie die Eingabe von Bereichen in der angegebenen Reihenfolge zumindest so einfach wie möglich. Wenn Sie die Bereiche als Text eingeben, nehmen Sie eine Seite von vim, dem Vorbild für Benutzerfreundlichkeit, und fordern Sie den Benutzer auf, invertierte Bereiche automatisch auszutauschen:

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

Wenn Ihr QS-Techniker UX nichts im Wege hätte, um ihm einen invertierten Bereich anzuzeigen, wäre dies unerwünscht, und er ging von einer vernünftigen Annahme aus.

Karl Bielefeldt
quelle
2

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

Erstens ist der Begriff unglaublich vieldeutig, insbesondere in 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 Verhalten des Backends. und lassen Sie Ihre Benutzer auch kein geerbtes Verhalten annehmen. Sicher, SQL definiert es BETWEENals inklusive, aber dies ist fast nie das gewünschte Verhalten (zum Beispiel - Wenn Sie so etwas tun, werden rows BETWEEN :start and :start + :strideSie stride + 1Zeilen bekommen ).

Stattdessen sollten Sie die Vergleiche für die Endpunkte explizit auflisten. Msgstr "Größer als oder gleich x". "Gestern". Dies beseitigt die Mehrdeutigkeit. Es hilft auch dabei, saubereren Code zu schreiben und einige heimtückische Fehler zu vermeiden. Das Beispiel aus früheren Zeilen ist im Wesentlichen der Beitrag von Djikstra zur Indizierung . Wenn Sie SQL erlauben, für einige Typen eine inklusive Obergrenze zu verwenden, werden möglicherweise die falschen Daten ausgewählt .

Uhrwerk-Muse
quelle
Nun, es lohnt sich darüber nachzudenken. Und danke für die Links. Die Dijkstra 'Post ist wahrscheinlich nicht sehr relevant, aber interessant :)
pkalinow
Dies beantwortet die OP-Frage nicht wirklich, sondern trägt zur Verwirrung bei.
Roland Tepp
1

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 es sich bei der Benutzeroberfläche um die Spezifikation handelt und es sich nicht um das Verhalten handelt, das von der Qualitätssicherung erwartet wird, werden zumindest einige Benutzer dies nicht erwarten. Das deutet auf ein Usability-Problem hin (auch wenn Sie PEBKAC argumentieren möchten). Arbeiten Sie mit Ihrer Qualitätssicherung zusammen, um eine zufriedenstellende Lösung zu finden.

Seien Sie generell vorsichtig mit Worten wie "zwischen", die klar erscheinen, es aber nicht sind. Abgesehen von Ihrer Meinungsverschiedenheit darüber, ob pendeln soll, gibt es Probleme mit der Inklusivität an beiden Enden und möglicherweise intuitiv unterschiedliche Bedeutungen in verschiedenen Bereichen (z. B. bedeutet "zwischen Freitag und Montag" für die meisten Menschen etwas anderes als "zwischen Montag und Montag" Freitag")

Martijn
quelle
1

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

Überall dort, wo Sie eine Schnittstelle zur Außenwelt anbieten, halten Sie das Ding so wenig überraschend wie möglich!

Jetzt, da ich die Problemstellung auf eine pragmatischere reduziert habe, werden Sie wahrscheinlich in wenigen Augenblicken feststellen, dass es bei der Angabe von Zahlenbereichen offensichtlich ist, die kleinere als die erstere zu belassen. Wenn es immer noch ein Rätsel ist, denken Sie wie folgt: Wie oft haben Sie die umgekehrte Art der Darstellung von zwei Zahlen verwendet, während Sie den Kindern gesagt haben, wie sie diese vergleichen sollen?

Wenn es sich bei Ihrem QS-Techniker um einen Fehler handelt, sagen Sie ihm höflich, dass Sie einige echte Fehler erwarten und nicht, wie Sie kostspielige Energie auf triviale Dinge übertragen können.

an4
quelle
0

Lassen Sie Ihren Debug-Code eine Fehlerbedingung auslösen oder eine Warnung protokollieren, 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).

Grimaldi
quelle