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

26

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?

pkalinow
źródło
11
Nie, ale być może twój interfejs użytkownika powinien zmienić kolor na czerwony, gdy ktoś źle go wypełni.
Ewan
3
ponadto, jeden z tych> = <= powinien być wyłączny, aby można było połączyć 100-> 200 200-> 300 itd. bez nakładania się
Ewan
23
Nie jest jasne, czy betweennależy uwzględnić lub wykluczyć niższe i wyższe wartości. Osoba zapewniająca jakość może być pedantyczna, ale dopóki istnieje niepewność, ktoś musi wyjaśnić historie / wymagania użytkowników. Może się okazać, że sposób, w jaki to jest zrobione, jest taki, jak powinien, ale trzeba podjąć decyzję.
Wygięty
11
To nie jest przypadek dobra czy zła. Jest to przypadek ... jak firma chce, aby aplikacja zachowywała się? Odpowiedzią jest oczekiwana funkcjonalność. Debaty techniczne nie napędzają wymaganej funkcjonalności. Wymagana funkcjonalność napędza debaty techniczne i, mam nadzieję, inspiruje najlepsze rozwiązanie dla biznesu.
Brad Thomas
2
To pytanie dotyczy bardziej tego, czego oczekuje użytkownik niż tego, czego oczekuje programista. W związku z tym byłoby bardziej odpowiednie dla User Experience .
Makyen

Odpowiedzi:

32

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.

Doktor Brown
źródło
57
prawdopodobnie możesz odrzucić jego prośbę => Tak naprawdę powiedziałbym, że przede wszystkim należy zdefiniować zachowanie. Następnie możesz podziękować facetowi z działu jakości za wskazanie problemu i powiedzieć, że teraz jest on określony do pracy w <określony sposób> (i upewnij się, że kod pasuje do specyfikacji).
Matthieu M.
1
@MatthieuM. Myślę, że to osobna odpowiedź, która powinna mieć 33 głosy poparcia. ;)
jpmc26
1
Przekształć błąd w ulepszenie i pozostaw go w zaległości na zawsze. Dziękuję QA za staranność.
Sandy Chapman
1
@MatthieuM. tak, w idealnym świecie każdy szczegół byłby wyraźny. W takim przypadku nie musiałbym zadawać pytań na Stack Exchange :)
pkalinow
@pkalinow: Myślę, że źle zrozumiałeś mój komentarz. Chodzi mi o to, że przed zamknięciem błędu powinieneś (1) podziękować facetowi z działu jakości za wskazanie nieokreślonego fragmentu kodu i (2) usiąść razem z kimkolwiek zainteresowanym, aby faktycznie określić zachowanie. Może to oznaczać przypisanie raportu kontroli jakości osobie odpowiedzialnej za napisanie specyfikacji do właściciela produktu, jeśli masz takie rzeczy itp., A następnie, po zachowaniu, które powinno zostać uzgodnione, możesz ocenić, czy oprogramowanie wymaga zmiany albo nie. Może to będzie oznaczać zmianę oprogramowania, może oznaczać zamknięcie raportu ...
Matthieu M.
13

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.

JacquesB
źródło
11

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

Caleth
źródło
Uwaga: Proszę nie składać samego oświadczenia value >= min(x, y) and value <= max(x, y). Oblicz, ile możesz zrobić, aby zapisać pracę serwera bazy danych, szczególnie jeśli jest on tak zbędny (możesz wykonać odpowiednie operacje raz i odpowiednio ustawić oba wyniki). Może nie chodzi, w zależności od serwera bazy danych oraz wartości określonych w karmisz, ale słabo napisany serwer SQL może dobrze wykonać mini maxza każdego rekordu, jeśli je umieścisz wherei czy możesz usunąć wysiłek , nie ma powodu, aby tego nie robić.
Pozew funduszu Moniki z
6
Proszę, nie słuchaj QPaysTaxes - optymalizacja rzeczy bez mierzenia konieczności jest dokładnie tym, co Knuth nazwał „przedwczesną optymalizacją będącą źródłem wszelkiego zła”. Szanse są wysokie w większości kodów świata rzeczywistego, nie zauważysz różnicy prędkości, jeśli Min i Max są obliczane dla każdego rekordu, ale wstępne obliczenia wartości (a więc wprowadzenie dodatkowego kodu i dodatkowej redundancji) sprawią, że program będzie znacznie mniej konserwowalny.
Doc Brown
@DocBrown Zgadzam się, że nie powinniśmy wprowadzać zmian w zakresie potencjalnego wzrostu wydajności bez mierzenia, ale wbrew twierdzeniu uważam, że wstępnie obliczone granice byłyby bardziej czytelne niż jeden wiersz, a zatem łatwiejsze w utrzymaniu.
Jacob Raihle
@JacobRaihle: może to być uzasadnione, ale moim zdaniem value >= min(x, y) and value <= max(x, y)jest tak czytelne, jak value >= minXY and value <= maxXY, gdzie minXYi gdzie maxXYsą wstępnie obliczone granice. Jednak w przypadku tego ostatniego trzeba będzie napisać kod, aby dodać te dwie nowe zmienne do systemu, wypełnić je wcześniej, nie zapomnij zaktualizować tych wartości, gdy zmieniają się xiy itd. Nadmiarowe dane zawsze wiążą się z pewnym ryzykiem błędów.
Doc Brown
5

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.

Karl Bielefeldt
źródło
2

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 .

Clockwork-Muse
źródło
Warto o tym pomyśleć. I dzięki za linki. Post Dijkstry nie jest chyba zbyt trafny, ale interesujący :)
pkalinow
To tak naprawdę nie odpowiada na pytanie PO, a jedynie zwiększa zamieszanie.
Roland Tepp
1

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")

Martijn
źródło
1

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.

an4
źródło
0

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).

Grimaldi
źródło