Чи має бути "між x і y" комутативним?

26

У моїй програмі є деякі заздалегідь задані шаблони виразів, які можна використовувати для фільтрації даних. Один з них - " between x and y". Інженер із контролю якості заявляє, що в його визначенні є дефект, оскільки " between 100 and 200" дає інші результати, ніж " between 200 and 100". Вираз внутрішньо перекладається на " value >= x and value <= y", тому очевидно немає результатів, коли друга межа є нижчою за першу. Я перевірив, що така ж поведінка є в SQL - " between x and y" передбачає, що y> = x або немає результатів. Це означає, що оператор не комутативний, принаймні у SQL.

Отже, чи правильно право на якість, що " between x and y" має бути комутативним?

requirements

— 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 мають бути взаємозамінними, або не слід дозволяти вибирати х, більший за y. Якщо дозволити x більше, ніж y, але повернути порожній набір, це створює непотрібну можливість помилок, не надаючи жодної користі.

Отже, інженер із контролю якості відповідає правильності, дефект є, але запропоноване рішення не обов'язково є найкращим. Ви повинні виконати тести на юзабіліті, щоб це вирішити, або, принаймні, запитати у представницьких користувачів те, що їм здається найбільш природним.

Ви також можете задати це питання на веб- сайті /ux// . Люди там насправді знають щось про роботу користувачів.

— ЖакБ
джерело

11

Є кілька розумних варіантів, і вибрати, які залежать від решти системи та очікувань користувачів.

Ви можете, як зазначає інженер із контролю якості, просто зробити вираз комутативним, і тоді був би переклад

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

Ви можете обмежити дійсне використання x <= y, що швидше вимагає, щоб ваш інтерфейс користувача відображав "це не допустимий вираз" якомога раніше.

Як варіант вищезазначеного, обмеження, x < yякщо ви маєте вираз equals xі вважаєте за краще оцінюватиvalue >= x and value <= x

— Калет
джерело

Примітка. Будь ласка, не робіть заяву самостійно value >= min(x, y) and value <= max(x, y). Попередньо підрахуйте, що ви можете зберегти на роботі сервера вашої бази даних, особливо якщо це зайве (ви можете виконати відповідні операції один раз і встановити обидва результати відповідно). Це може не мати значення, в залежності від сервера бази даних та конкретних значень, якими ви живитесь, але погано написаний SQL-сервер цілком може виконувати minі maxдля кожного запису, якщо ви помістите їх у where, і якщо ви зможете зняти це зусилля , немає причини цього не робити.

— Фонд позову Моніки

6

Будь ласка, не слухайте QPaysTaxes - оптимізація речей, не змінюючи ніколи необхідності, - це саме те, що Кнут назвав "передчасним оптимізацією, корінням всього зла". Швидше за все, у більшості реальних кодів світу ви не помітите різниці в швидкості, якщо Min та Max розраховуються для кожного запису, але попередньо підрахунок значень (і, таким чином, введення додаткового коду та зайвої надмірності) зробить програму набагато менш рентабельною.

— Doc Brown

@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)?

Якщо вашому інженеру з питань QA нічого не було на шляху до UX, щоб показати йому перевернутий діапазон, було б небажано, то він зробив обґрунтоване припущення.

— Карл Білефельдт
джерело

2

Відверто? Не використовуйте "між". Зовсім.

По-перше, термін неймовірно неоднозначний, особливо в англійській мові. Це комутативно? Чи виключні умови? Включно?

По-друге, якщо ви робите інтерфейс, відірваний від бекенда, не турбуйтеся про поведінку бекенда; і не дозволяйте вашим користувачам приймати успадковану поведінку. Звичайно, SQL визначає його BETWEENяк інклюзивне, але це майже ніколи не є бажаною поведінкою (наприклад, - якщо ви робите щось на кшталт rows BETWEEN :start and :start + :strideтого, що збираєтеся отримувати stride + 1рядки).

Натомість вам слід чітко вказати порівняння кінцевих точок. "Більше або рівне х". "До сьогоднішнього дня". Це знімає неоднозначність. Це також допомагає писати чистіший код і уникати деяких підступних помилок. Приклад рядків з попереднього по суті - повідомлення Джикстра про індексацію . І дозволити SQL використовувати включену верхню межу для деяких типів може призвести до вибору неправильних даних .

— Годинник-муза
джерело

Що ж, варто подумати. І дякую за посилання. Повідомлення Dijkstra, мабуть, не дуже актуальне, але цікаве :)

— pkalinow

Це насправді не відповідає на питання ОП, натомість додає плутанини.

— Роланд Тепп

1

Сперечатися з вашим QA про те, хто "правильний", а хто "неправильний", непродуктивно. Ви інтерпретували специфікацію інакше, ніж вони. Це означає, що специфікація є досить неоднозначною, що потребує уточнення.

Якщо користувальницький інтерфейс є специфікацією, а це не поведінка, яку очікує QA, це не буде поведінкою, принаймні деякі користувачі очікують. Це вказує на проблему зручності використання (навіть якщо ви хочете сперечатися з PEBKAC). Попрацюйте зі своїм QA, щоб знайти задовільне рішення для цього.

Загалом, будьте обережні зі словами типу "між", які здаються зрозумілими, але не є. Крім вашої незгоди щодо того, чи варто їздити на маршруті, вони є проблемами з інклюзивністю на будь-якому кінці, і вони можуть інтуїтивно означати різні речі в різних областях (наприклад, "між п’ятницею та понеділком" означатиме для більшості людей щось інше, ніж "між понеділком і понеділком П’ятниця ”)

— Мартійн
джерело

1

Я розкладу принцип UNIX, який говорить про прості інтерфейси.

Де б не був інтерфейс, який ви пропонуєте зовнішньому світу, зберігайте річ якнайменше дивно!

Тепер, коли я зменшив постановку проблеми до більш прагматичної, я думаю, що вам знадобиться лише кілька моментів, щоб зрозуміти, що, визначаючи діапазони чисел, очевидно, щоб *** зберігати менший як попередній ***. Якщо це все ще головоломка, подумайте так: Скільки разів ви використовували зворотний спосіб представлення двох чисел, розповідаючи дітям, як їх порівняти?

Якщо ваш QA інженер називає це помилкою, ввічливо скажіть йому, що ви очікуєте справжніх помилок, а не способів передавати дорогу енергію на тривіальні речі.

— an4
джерело

0

Зробіть ваш код налагодження кинутим стан помилки або записуйте попередження, коли воно передається значеннями в неправильному порядку. Таким чином викликовий код може перевірити та обміняти параметри, якщо це необхідно. Таким чином, користувачі цієї "функції" стануть усвідомленими та роблять правильно (про що ви не знаєте заздалегідь).

— Грімальді
джерело