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

26

В моем приложении есть несколько предопределенных шаблонов выражений, которые можно использовать для фильтрации данных. Одним из них является " 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" должно быть коммутативным?

pkalinow
источник
11
Нет, но, возможно, ваш пользовательский интерфейс должен покраснеть, если кто-то напишет его неправильно.
Эван
3
кроме того, он один из этих> = <= должен быть эксклюзивным, чтобы вы могли связывать 100-> 200 200-> 300 и т. д., не перекрывая друг
Ewan
23
Не ясно, betweenследует ли включать или исключать более низкие и более высокие значения. Специалист по обеспечению качества может быть педантичным, но до тех пор, пока существует неопределенность, кто-то должен прояснить пользовательские истории / требования. Может оказаться, что они так и делают, как и должно быть, но решение должно быть принято.
Бент
11
Это не случай правильного или неправильного. Это случай ... как бизнес хочет, чтобы приложение работало? Ответ - какая функциональность ожидается. Технические дебаты не приводят к необходимой функциональности. Необходимая функциональность ведет технические дебаты и, мы надеемся, вдохновляет лучшее решение для бизнеса.
Брэд Томас
2
Этот вопрос больше о том, что ожидает пользователь, чем о том, что ожидает программист. Как таковая, она будет более подходящей для пользовательского опыта .
Макьен,

Ответы:

32

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

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

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

Док Браун
источник
57
Вы, вероятно, можете отклонить его запрос => Я бы на самом деле сказал, что в первую очередь, поведение должно быть определено. Затем вы можете поблагодарить специалиста по обеспечению качества за указание на проблему и сказать, что теперь она указана для работы <определенным образом> (и убедиться, что код соответствует спецификации).
Матье М.
1
@MatthieuM. Я думаю, что это отдельный ответ, который должен иметь 33 собственных голосов. ;)
jpmc26
1
Преобразуйте ошибку в улучшение и оставьте ее в резерве на неопределенный срок. Спасибо QA за их усердие.
Сэнди Чэпмен
1
@MatthieuM. да, в идеальном мире было бы четкое требование для каждой детали. В таком случае мне не нужно было бы задавать вопросы на Stack Exchange :)
pkalinow
@pkalinow: я думаю, вы не поняли мой комментарий. Моя точка зрения заключалась в том, что перед закрытием ошибки вы должны (1) поблагодарить специалиста по тестированию за то, что он указал на недостаточно заданный фрагмент кода, и (2) сесть вместе с тем, кто заинтересован в том, чтобы на самом деле указать поведение. Это может означать назначение отчета о контроле качества тому, кто отвечает за написание спецификаций, владельцу продукта, если у вас есть такие вещи и т. Д. ... затем, после того, как его поведение должно было быть согласовано, вы можете оценить, нужно ли менять программное обеспечение. или не. Может быть, это будет означать изменение программного обеспечения, может быть, это будет означать закрытие отчета ...
Матье М.
13

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

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

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

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

JacquesB
источник
11

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

Вы можете, как указывает инженер 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

Caleth
источник
Примечание: пожалуйста, не делайте само заявление value >= min(x, y) and value <= max(x, y). Пересчитайте все, что вы можете, чтобы сохранить работу сервера базы данных, особенно если он такой избыточный (вы можете выполнить соответствующие операции один раз и установить оба результата соответственно). Это может не иметь значения, в зависимости от сервера базы данных и конкретных значений, которые вы вводите, но плохо написанный SQL-сервер вполне может выполнить minи maxдля каждой записи, если вы поместите их в where, и если вы сможете отменить это усилие нет причин не делать этого
Фонд Моника судебный процесс
6
Пожалуйста, не слушайте QPaysTaxes - оптимизация вещей без измерения необходимости - это именно то, что Кнут назвал «преждевременной оптимизацией, являющейся корнем всего зла». Скорее всего, в большинстве реальных программ вы не заметите разницы в скорости, если для каждой записи вычислены минимальное и максимальное значения, но предварительный расчет значений (и, следовательно, введение дополнительного кода и дополнительной избыточности) сделает программу гораздо менее удобной для сопровождения.
Док Браун
@DocBrown Я согласен с тем, что мы не должны вносить изменения в потенциальный прирост производительности без измерения, но, вопреки вашему утверждению, я считаю, что предварительно рассчитанные границы будут более удобочитаемыми, чем однострочные, и, следовательно, более удобными в обслуживании.
Джейкоб Райле
@JacobRaihle: это может быть самоуверенным, но на мой вкус value >= min(x, y) and value <= max(x, y)читабельнее, чем value >= minXY and value <= maxXY, где minXYи maxXYявляются предварительно рассчитанными границами. Однако для последнего потребуется написать некоторый код, чтобы добавить эти две новые переменные в систему, заполнить их заранее, не забудьте обновить эти значения при изменении x и y и так далее. Избыточные данные всегда вносят определенный риск ошибок.
Док Браун
5

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

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

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

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

Карл Билефельдт
источник
2

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

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

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

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

Заводной-Muse
источник
Ну, это стоит подумать. И спасибо за ссылки. Пост Дейкстры, вероятно, не очень актуален, но интересен :)
pkalinow
Это на самом деле не отвечает на вопрос ОП, вместо этого оно добавляет путаницы.
Роланд
1

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

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

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

Мартейн
источник
1

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

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

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

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

AN4
источник
0

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

Grimaldi
источник