Czy „między xiy” powinno być przemienne?

W mojej aplikacji jest kilka predefiniowanych szablonów wyrażeń, których można użyć do filtrowania danych. Jednym z nich jest „ between x and y”. Inżynier ds. Kontroli jakości twierdzi, że w definicji występuje defekt, ponieważ „ between 100 and 200” daje inne wyniki niż „ between 200 and 100”. Wyrażenie jest wewnętrznie przetłumaczone na „ value >= x and value <= y”, więc oczywiście nie ma wyników, gdy druga granica jest niższa niż pierwsza. Sprawdziłem, czy to samo zachowanie jest w SQL - „ between x and y” zakłada, że ​​y> = x lub nie ma żadnych wyników. Oznacza to, że operator nie jest przemienny, przynajmniej w SQL.

Czy więc kontrola jakości ma rację, że „ between x and y” powinno być przemienne?

Jeśli twoja obecna specyfikacja pozostawia to niezdefiniowane, zachowanie jest całkowicie arbitralne, nie ma definicji „właściwej” lub „złej”. Jeśli więc inżynier ds. Kontroli jakości nie może wskazać dokładnego akapitu w specyfikacji, w której zdefiniowane jest to zachowanie, prawdopodobnie możesz odrzucić jego prośbę (choć nie wydaje się, aby wymagało to wiele wysiłku, aby ją wdrożyć). Jeśli oboje nie możecie znaleźć konsensusu, jedna osoba w zespole musi podjąć decyzję, co jest ważniejsze w kontekście wniosku:

• przestrzeganie standardu SQL tak dokładnie, jak to możliwe
• nieprzestrzeganie go z powodu ergonomii, szczególnych przypadków użycia lub innych wymagań

Niezależnie od decyzji podjętej przez zespół dobrym pomysłem może być udokumentowanie zachowania i przyczyny, dla której decyzja została podjęta.

To pytanie dotyczące użyteczności lub doświadczenia użytkownika. To, jak zachowuje się SQL lub jakikolwiek inny system, nie ma znaczenia, pytanie brzmi, co ma największy sens z punktu widzenia użytkownika.

Obecne zachowanie nie ma sensu z perspektywy użytkownika. Albo X i Y powinny być wymienne i nie należy dopuścić, aby wybrać większe od y x. Zezwolenie na x większe niż y, ale zwrócenie pustego zestawu, wprowadza niepotrzebną możliwość błędów bez żadnych korzyści.

Inżynier ds. Kontroli jakości ma więc rację, ale jest to usterka, ale proponowane rozwiązanie niekoniecznie jest najlepsze. Musisz wykonać testy użyteczności, aby zadecydować o tym, lub przynajmniej zapytaj niektórych reprezentatywnych użytkowników, co wydaje im się najbardziej naturalne.

Ewentualnie możesz zadać pytanie na /ux// . Ludzie tam naprawdę wiedzą coś o doświadczeniu użytkownika.

Istnieje kilka rozsądnych wyborów, a wybór zależy od reszty systemu i oczekiwań użytkowników.

Możesz, jak zauważa inżynier ds. Kontroli jakości, po prostu zmienić wyrażenie na przemienne, a wtedy tłumaczenie byłoby

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

Możesz ograniczyć prawidłowe użycie do x <= y, co raczej wymaga, aby Twój interfejs użytkownika wyświetlał „to nie jest prawidłowe wyrażenie” tak wcześnie, jak to możliwe.

Jako wariant powyższego ograniczenia, x < yjeśli masz wyrażenie equals xi wolisz je od ocenyvalue >= x and value <= x

W nieinteraktywnym ustawieniu, w którym granice są tworzone przez skrypt, zwykle uzasadnione jest wymaganie, aby były w porządku. Stwarza to o jedną mniejszą kontrolę sprawdzania poprawności, ma sens semantyczny i jest łatwe do zarządzania.

W ustawieniu interaktywnym chcesz pomóc użytkownikowi. Jeśli to możliwe, utwórz interfejs GUI, który nie pozwala na wprowadzanie zamienionych zakresów lub przynajmniej ułatwia wprowadzanie zakresów w kolejności. Jeśli wprowadzasz zakresy tekstem, weź stronę z vima, tego wzorca użyteczności, i poproś użytkownika, aby automatycznie zamienił zakresy odwrócone:

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

Jeśli twój inżynier ds. Kontroli jakości nie miał żadnych przeszkód, by UX pokazałby mu, że odwrócony zasięg byłby niepożądany, to przyjął rozsądne założenie.

Szczerze? Nie używaj „pomiędzy”. W ogóle.

Po pierwsze, termin ten jest niezwykle niejednoznaczny, szczególnie w języku angielskim. Czy to jest przemienne? Czy warunki są wyłączne? Włącznie?

Po drugie, jeśli robisz interfejs oddzielony od backendu, nie martw się o zachowanie backendu; i nie pozwól, aby użytkownicy również przyjęli zachowanie odziedziczone. Jasne, SQL definiuje go BETWEENjako obejmujący, ale prawie nigdy nie jest to pożądane zachowanie (na przykład - jeśli zrobisz coś takiego rows BETWEEN :start and :start + :stride, co dostanieszstride + 1 wiersze).

Zamiast tego należy wyraźnie wymienić porównania dla punktów końcowych. „Większa lub równa x”. „Przed dziś”. To usuwa dwuznaczność. Pomaga także w pisaniu czystszego kodu i pozwala uniknąć pewnych podstępnych błędów. Przykład wierszy z wcześniejszego jest zasadniczo postem Djikstry na temat indeksowania . A zezwolenie SQLowi na użycie włączającej górnej granicy dla niektórych typów może spowodować wybranie niewłaściwych danych .

Nieproduktywne jest spieranie się ze swoim QA o to, kto jest „dobry”, a kto „zły”. Zinterpretowałeś specyfikację inaczej niż oni. Oznacza to, że specyfikacja jest na tyle dwuznaczna, że ​​wymaga wyjaśnienia.

Jeśli interfejs użytkownika jest specyfikacją i nie jest to zachowanie, którego spodziewa się QA, nie będzie to zachowanie, którego przynajmniej niektórzy użytkownicy oczekują. Wskazuje to na problem z użytecznością (nawet jeśli chcesz argumentować PEBKAC). Współpracuj z kontrolą jakości, aby znaleźć satysfakcjonujące rozwiązanie tego problemu.

Zasadniczo uważaj na słowa „między”, które wydają się jasne, ale nie są. Oprócz tego, że nie zgadzasz się co do tego, czy należy dojeżdżać do pracy, są problemy z włączeniem na obu końcach i mogą intuicyjnie oznaczać różne rzeczy w różnych domenach (na przykład „między piątkiem a poniedziałkiem” będzie oznaczać coś innego dla większości ludzi niż „między poniedziałkiem a Piątek")

Rozwiążę zasadę UNIX, która mówi o prostych interfejsach.

Gdziekolwiek istnieje interfejs, który oferujesz światu zewnętrznemu, spraw, aby było to jak najmniej zaskakujące, jak to możliwe!

Teraz, gdy zredukowałem opis problemu do bardziej pragmatycznego, myślę, że zajmie ci tylko kilka chwil, aby zdać sobie sprawę, że przy określaniu zakresów liczb *** jest oczywiste, że *** zachowaj mniejszy jak poprzedni ***. Jeśli nadal jest to zagadka, pomyśl tak: Ile razy używałeś odwrotnego sposobu przedstawiania dwóch liczb, mówiąc dzieciom, jak je porównać?

Jeśli twój inżynier ds. Kontroli jakości nazywa to błędem, powiedz mu grzecznie, że oczekujesz prawdziwych błędów, a nie sposoby na przesyłanie kosztownej energii na trywialne sprawy.

Spraw, aby kod debugowania generował błąd lub rejestrował ostrzeżenie za każdym razem, gdy wartości są przekazywane w niewłaściwej kolejności. W ten sposób kod wywołujący może w razie potrzeby sprawdzić i wymienić parametry. W ten sposób użytkownicy tej „funkcji” staną się świadomi i będą postępować właściwie (czego wcześniej nie wiesz).