Должно ли «между x и y» быть коммутативным?

В моем приложении есть несколько предопределенных шаблонов выражений, которые можно использовать для фильтрации данных. Одним из них является " between x and y". Инженер QA утверждает, что в его определении есть дефект, потому что " between 100 and 200" дает результаты, отличные от " between 200 and 100". Выражение внутренне переводится на « value >= x and value <= y», поэтому, очевидно, нет результатов, когда вторая граница ниже первой. Я проверил, что такое же поведение в SQL - " between x and y" предполагает, что y> = x или нет результатов. Это означает, что оператор не является коммутативным, по крайней мере, в SQL.

Итак, верно ли, что QA " between x and y" должно быть коммутативным?

Если ваша текущая спецификация оставляет это неопределенным, поведение совершенно произвольное, нет «правильного» или «неправильного» определения. Поэтому, если ваш инженер по обеспечению качества не может указать вам точный абзац в спецификации, где это поведение определено, вы, вероятно, можете отклонить его запрос (хотя это не является требованием, которое требует больших усилий для его реализации). Если вы оба не можете найти консенсус, один человек в вашей команде должен принять решение, что является более важным в контексте заявки:

• следуя стандарту SQL как можно точнее
• не следуйте ему из-за эргономики, конкретных случаев использования или других требований

Независимо от того, какое решение принимает ваша команда, было бы неплохо задокументировать поведение и причину, по которой это решение было принято.

Это вопрос юзабилити или пользовательского опыта. Как ведет себя SQL или любая другая система, не имеет значения, вопрос в том, что имеет смысл с точки зрения пользователей.

Текущее поведение не имеет смысла с точки зрения пользователя. Либо x и y должны быть взаимозаменяемыми, либо нельзя разрешить выбирать x больше y. Разрешение x больше чем y, но возвращение пустого набора приводит к ненужной возможности ошибок без предоставления какой-либо выгоды.

Таким образом, инженер QA является правильным, есть дефект, но предлагаемое решение не обязательно является лучшим. Вы должны выполнить юзабилити-тесты, решить это или, по крайней мере, спросить некоторых типичных пользователей, что кажется им наиболее естественным.

Кроме того, вы можете задать вопрос по адресу /ux// . Люди там действительно кое-что знают об опыте пользователя.

Есть несколько разумных вариантов, и выбор зависит от остальной системы и ожиданий ваших пользователей.

Вы можете, как указывает инженер QA, просто сделать выражение коммутативным, и тогда перевод будет

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

Вы можете ограничить допустимое использование x <= y, что, скорее, требует, чтобы ваш пользовательский интерфейс отображал «это недопустимое выражение» как можно раньше.

В качестве варианта вышеизложенного, ограничение, x < yесли у вас есть выражение equals xи предпочитаете это для оценкиvalue >= x and value <= x

В неинтерактивной среде, где ваши границы создаются скриптом, обычно имеет смысл требовать, чтобы они были в порядке. Это создает одну менее проверочную проверку, имеет больше смысла семантически и тривиально для управления.

В интерактивной обстановке вы хотите помочь пользователю. Если возможно, создайте графический интерфейс, который не позволяет вводить измененные диапазоны или, по крайней мере, упрощает ввод диапазонов по порядку. Если вы вводите диапазоны по тексту, возьмите страницу из vim, этот образец удобства и предложите пользователю автоматически поменять местами инвертированные диапазоны:

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

Если у вашего инженера по контролю качества не было ничего на пути UX, чтобы показать ему, что инвертированный диапазон был бы нежелателен, то он сделал разумное предположение.

Откровенно? Не используйте «между». Вообще.

Во-первых, термин невероятно двусмысленный, особенно в английском. Это коммутативно? Являются ли условия эксклюзивными? Inclusive?

Во-вторых, если вы делаете интерфейс, оторванный от бэкэнда, не беспокойтесь о его поведении; и не позволяйте своим пользователям принимать унаследованное поведение, либо. Конечно, SQL определяет его BETWEENкак включающий, но это почти никогда не является желаемым поведением (например, если вы делаете что-то подобное, rows BETWEEN :start and :start + :strideвы получаете stride + 1строки).

Вместо этого вы должны явно перечислить сравнения для конечных точек. «Больше или равно х». "До сегодня". Это устраняет двусмысленность. Это также помогает писать более чистый код и избежать некоторых коварных ошибок. Пример строк из более раннего, по сути , пост Джикстры об индексации . А разрешение SQL использовать верхнюю границу для некоторых типов может привести к неправильному выбору данных .

Бесполезно спорить с вашим QA о том, кто «прав», а кто «неправ». Вы интерпретировали спецификацию иначе, чем они. Это означает, что спецификация достаточно неоднозначна, что требует уточнения.

Если пользовательский интерфейс - это спецификация, и это не то поведение, которого ожидает QA, то оно не будет таким, как ожидают некоторые пользователи. Это указывает на проблему с удобством использования (даже если вы хотите спорить с PEBKAC). Работайте со своим QA, чтобы найти удовлетворительное решение для этого.

В целом, будьте осторожны со словами типа «между», которые кажутся ясными, но не являются очевидными. Помимо вашего разногласия по поводу того, стоит ли добираться до города, это проблемы с инклюзивностью с обеих сторон, и они могут интуитивно означать разные вещи в разных доменах (например, «между пятницей и понедельником» будет означать нечто иное для большинства людей, чем «между понедельником и пятница ")

Я раскошелюсь на принцип UNIX, который говорит о простых интерфейсах.

Везде, где есть интерфейс, который вы предлагаете внешнему миру, сделайте это как можно менее удивительным!

Теперь, когда я сократил формулировку задачи до более прагматичной, я думаю, что вам понадобится всего несколько минут, чтобы понять, что при указании диапазонов чисел очевидно, что *** оставит меньшее как прежнее ***. Если это все еще головоломка, подумайте так: сколько раз вы использовали обратный способ представления двух чисел, рассказывая детям, как их сравнивать?

Если ваш инженер по контролю качества называет это ошибкой, вежливо скажите ему, что вы ожидаете каких-то реальных ошибок, а не способов потратить дорогостоящую энергию на тривиальные вещи.

Сделайте так, чтобы ваш код отладки выдавал состояние ошибки или регистрировал предупреждение, когда ему передаются значения в неправильном порядке. Таким образом, вызывающий код может проверять и обмениваться параметрами, если это необходимо. Таким образом, пользователи этой «функции» узнают и поступят правильно (чего вы не знаете заранее).