«Entre x et y» doit-il être commutatif?

Dans mon application, il existe des modèles d'expression prédéfinis qui peuvent être utilisés pour filtrer les données. L'un d'eux est " between x and y". Un ingénieur QA affirme qu'il y a un défaut dans sa définition, car " between 100 and 200" donne des résultats différents de " between 200 and 100". L'expression est traduite en interne par " value >= x and value <= y", donc il n'y a évidemment aucun résultat lorsque la deuxième limite est inférieure à la première. J'ai vérifié que le même comportement est en SQL - " between x and y" suppose que y> = x ou il n'y a aucun résultat. Cela signifie que l'opérateur n'est pas commutatif, du moins en SQL.

Donc, le QA a-t-il raison de dire que " between x and y" devrait être commutatif?

Si votre spécification actuelle laisse cela indéfini, le comportement est complètement arbitraire, il n'y a pas de définition "correcte" ou "incorrecte". Donc, si votre ingénieur QA ne peut pas vous indiquer le paragraphe exact de la spécification où ce comportement est défini, vous pouvez probablement refuser sa demande (bien que cela ne semble pas être une exigence qui nécessite beaucoup d'efforts pour l'implémenter). Si vous ne parvenez pas tous les deux à trouver un consensus, une personne de votre équipe doit prendre une décision plus importante dans le contexte de la candidature:

• en suivant au plus près le standard SQL
• ne pas le suivre en raison de l'ergonomie, des cas d'utilisation spécifiques ou d'autres exigences

Quelle que soit la décision prise par votre équipe, ce pourrait être une bonne idée de documenter le comportement et la raison pour laquelle la décision a été prise.

Il s'agit d'une question de convivialité ou d'expérience utilisateur. Le comportement de SQL ou de tout autre système est sans importance, la question est de savoir ce qui est le plus logique du point de vue des utilisateurs.

Le comportement actuel n'a pas de sens du point de vue de l'utilisateur. Soit x et y doivent être interchangeables, soit il ne doit pas être autorisé à sélectionner un x plus grand que y. Autoriser x plus grand que y mais renvoyer un ensemble vide introduit une possibilité inutile d'erreurs sans aucun avantage.

Donc l'ingénieur QA a raison il y a un défaut, mais la solution proposée n'est pas forcément la meilleure. Vous devez effectuer des tests d'utilisabilité pour en décider, ou au moins demander à certains utilisateurs représentatifs ce qui leur semble le plus naturel.

Alternativement, vous pouvez poser la question sur /ux// . Les gens là-bas connaissent en fait une chose ou deux sur l'expérience utilisateur.

Il y a quelques choix judicieux, et lequel choisir dépend du reste du système et des attentes de vos utilisateurs.

Comme le souligne l'ingénieur QA, vous pouvez simplement rendre l'expression commutative, puis la traduction serait

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

Vous pouvez restreindre l'utilisation valide à x <= y, ce qui nécessite plutôt que votre interface utilisateur puisse afficher "ce n'est pas une expression valide" le plus tôt possible.

Comme variation de ce qui précède, la restriction x < ysi vous avez une expression equals xet préférez celle à l'évaluationvalue >= x and value <= x

Dans un cadre non interactif, où vos limites sont créées par un script, il est généralement logique de les exiger dans l'ordre. Cela crée une vérification de validation en moins, a plus de sens sémantiquement et est trivial à gérer.

Dans un cadre interactif, vous souhaitez aider l'utilisateur. Si possible, créez une interface graphique qui n'autorise pas la saisie des plages permutées, ou du moins facilite la saisie des plages dans l'ordre. Si vous entrez les plages par texte, prenez une page de vim, ce modèle de convivialité, et invitez l'utilisateur à permuter automatiquement les plages inversées:

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

Si votre ingénieur QA n'avait rien sur le chemin de l'UX pour lui montrer qu'une plage inversée serait indésirable, alors il a fait une hypothèse raisonnable.

Franchement? N'utilisez pas "entre". Du tout.

Premièrement, le terme est incroyablement ambigu, surtout en anglais. Est-ce commutatif? Les termes sont-ils exclusifs? Compris?

Deuxièmement, si vous faites une interface séparée du backend, ne vous inquiétez pas du comportement du backend; et ne laissez pas non plus vos utilisateurs adopter un comportement hérité. Bien sûr, SQL définit son BETWEENcomme inclusif, mais ce n'est presque jamais le comportement souhaité (par exemple - Si vous faites quelque chose comme rows BETWEEN :start and :start + :stridevous allez obtenir des stride + 1lignes).

Au lieu de cela, vous devez répertorier explicitement les comparaisons pour les points de terminaison. "Supérieur ou égal à x". "Avant aujourd'hui". Cela supprime l'ambiguïté. Cela permet également d'écrire du code plus propre et d'éviter certaines erreurs insidieuses. L'exemple de lignes du précédent est essentiellement le post de Djikstra sur l'indexation . Et autoriser SQL à utiliser une limite supérieure inclusive sur certains types peut entraîner la sélection de données incorrectes .

Il n'est pas productif de discuter avec votre AQ pour savoir qui a «raison» et qui a «tort». Vous avez interprété la spécification différemment qu'eux. Cela signifie que la spécification est suffisamment ambiguë pour qu'elle nécessite des éclaircissements.

Si l'interface utilisateur est la spécification et que ce n'est pas le comportement que le contrôle qualité attend, ce ne sera pas le comportement au moins auquel certains utilisateurs s'attendent. Cela indique un problème de convivialité (même si vous voulez argumenter PEBKAC). Travaillez avec votre AQ pour trouver une solution satisfaisante à cela.

En règle générale, faites attention aux mots comme «entre» qui semblent clairs, mais qui ne le sont pas. Mis à part votre désaccord sur l'opportunité de faire la navette, ce sont des problèmes d'inclusivité à chaque extrémité et peuvent signifier intuitivement des choses différentes sur différents domaines (par exemple, "entre vendredi et lundi" signifiera quelque chose de différent pour la plupart des gens que "entre lundi et Vendredi")

Je bifurquerai un principe UNIX qui parle d'interfaces simples.

Partout où il y a une interface que vous offrez au monde extérieur, gardez la chose la moins surprenante possible!

Maintenant que j'ai réduit l'énoncé du problème à un énoncé plus pragmatique, je pense qu'il ne vous faudra que quelques instants pour réaliser que lors de la spécification des plages de nombres, il est évident de *** garder le plus petit comme l'ancien ***. Si c'est encore une énigme, pensez comme ceci - Combien de fois avez-vous utilisé la façon inverse de représenter deux nombres tout en disant aux enfants comment les comparer?

Si votre ingénieur QA appelle cela un bug, dites-lui poliment que vous vous attendez à de vrais bugs, et non à des moyens de transmettre une énergie coûteuse sur des choses triviales.

Faites en sorte que votre code de débogage renvoie une condition d'erreur ou enregistrez un avertissement chaque fois que les valeurs sont transmises dans le mauvais ordre. De cette façon, le code appelant peut vérifier et échanger des paramètres, si nécessaire. De cette façon, les utilisateurs de cette «fonctionnalité» deviendront conscients et feront la bonne chose (que vous ne connaissez pas au préalable).