Dovrebbe essere "commutativo tra xey"?

Se la tua specifica attuale lascia questo indefinito, il comportamento è completamente arbitrario, non esiste una definizione "giusta" o "sbagliata". Quindi, se il tuo ingegnere di QA non può indicarti il paragrafo esatto nelle specifiche in cui questo comportamento è definito, puoi probabilmente rifiutare la sua richiesta (anche se non sembra essere un requisito che richiede molto sforzo per implementarlo). Se entrambi non riesci a trovare un consenso, una persona del tuo team deve prendere una decisione che è più importante nel contesto dell'applicazione:

• seguendo lo standard SQL il più vicino possibile
• non seguirlo per motivi di ergonomia, casi d'uso specifici o altri requisiti

Qualunque sia la decisione presa dal tuo team, potrebbe essere una buona idea documentare il comportamento e il motivo per cui è stata presa la decisione.

Questa è una domanda di usabilità o esperienza utente. Il comportamento di SQL o di qualsiasi altro sistema è irrilevante, la domanda è ciò che ha più senso dal punto di vista dell'utente.

Il comportamento attuale non ha senso dal punto di vista dell'utente. O xey dovrebbero essere intercambiabili o non dovrebbe essere consentito selezionare x più grande di y. Permettendo x maggiore di y ma restituire un set vuoto introduce una inutile possibilità di errori senza fornire alcun beneficio.

Quindi l'ingegnere addetto al controllo qualità è corretto, c'è un difetto, ma la soluzione proposta non è necessariamente la migliore. Devi eseguire test di usabilità per decidere, o almeno chiedere ad alcuni utenti rappresentativi ciò che sembra più naturale per loro.

In alternativa, puoi porre la domanda al link . Le persone laggiù conoscono davvero qualcosa sull'esperienza utente.

Ci sono un paio di scelte sensate e quali scegliere dipende dal resto del sistema e dalle aspettative dei tuoi utenti.

Puoi, come sottolinea l'ingegnere del QA, rendere commutativa l'espressione, quindi la traduzione sarebbe

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

Puoi limitare l'utilizzo valido a x <= y , che richiede piuttosto che l'interfaccia utente possa visualizzare "non è un'espressione valida" il prima possibile.

Come variante di quanto sopra, la restrizione x < y se hai un'espressione equals x e preferisci quella a valutare value >= x and value <= x

In un'impostazione non interattiva, in cui i tuoi limiti sono creati da uno script, di solito ha senso richiedere che siano in ordine. Questo crea un controllo di validazione in meno da fare, ha più senso semanticamente ed è banale da gestire.

In un'impostazione interattiva, vuoi aiutare l'utente. Se possibile, creare una GUI che non consenta l'inserimento di intervalli di swap, o perlomeno renderlo il più semplice possibile per inserire gli intervalli in ordine. Se stai inserendo gli intervalli in base al testo, acquisisci una pagina da Vim, il modello di usabilità e chiedi all'utente di scambiare automaticamente intervalli invertiti:

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

Se il tuo ingegnere di QA non aveva nulla nel modo di UX per mostrargli una gamma invertita sarebbe indesiderabile, allora ha fatto un'ipotesi ragionevole.

Francamente? Non usare "tra". A tutti.

In primo luogo, il termine è incredibilmente ambiguo, specialmente in inglese. È commutativo? I termini sono esclusivi? Inclusive?

In secondo luogo, se stai facendo un'interfaccia separata dal back-end, non preoccuparti del comportamento del back-end; e non lasciare che anche i tuoi utenti assumano comportamenti ereditari. Certo, SQL definisce il BETWEEN come inclusivo, ma questo non è quasi mai il comportamento desiderato (ad esempio: se fai qualcosa come rows BETWEEN :start and :start + :stride otterrai stride + 1 righe).

Invece, dovresti elencare esplicitamente i confronti per gli endpoint. "Maggiore o uguale a x". "Prima di oggi". Questo rimuove l'ambiguità. Aiuta anche a scrivere codice più pulito ed evitare alcuni errori insidiosi. L'esempio di righe precedente è essenzialmente post di Djikstra sull'indicizzazione . E permettendo a SQL di usare un limite superiore inclusivo su alcuni tipi può causare la selezione di dati errati .

È improduttivo discutere con il tuo controllo di qualità su chi è "giusto" e chi è "sbagliato". Hai interpretato le specifiche in modo diverso rispetto a loro. Ciò significa che le specifiche sono sufficientemente ambigue da richiedere chiarimenti.

Se l'interfaccia utente è la specifica e non è il comportamento previsto dal controllo di qualità, non sarà il comportamento che almeno alcuni utenti si aspettano. Ciò indica un problema di usabilità (anche se si vuole discutere di PEBKAC). Lavora con il tuo QA per trovare una soluzione soddisfacente a questo.

Come punto generale, fai attenzione con parole come "tra" che sembrano chiare, ma non lo sono. A parte il tuo disaccordo sull'opportunità di spostarsi, i loro sono problemi di inclusività da entrambe le parti e potrebbero intuire significati diversi su domini diversi (ad esempio, "tra venerdì e lunedì" significherà qualcosa di diverso dalla maggior parte della gente rispetto a "tra lunedì e venerdì ")

Forzerò un principio UNIX che parla di semplici interfacce.

Ovunque ci sia un'interfaccia che offri al mondo esterno, tieni la cosa il meno sorprendente possibile !

Ora che ho ridotto l'affermazione del problema a uno più pragmatico, penso che ci vorranno solo pochi istanti per rendersi conto che quando si specificano gli intervalli di numeri, è ovvio che *** mantenere quello più piccolo come il vecchio ***. Se è ancora un enigma, pensa in questo modo: quante volte hai usato il modo opposto di rappresentare due numeri mentre dicevi ai bambini come confrontare quelli?

Se il tuo ingegnere di QA lo chiama bug, digli gentilmente che ti stai aspettando alcuni bug reali , e non modi per trasmettere energia costosa su cose banali.

Fai in modo che il tuo codice di debug genera una condizione di errore o registra un avviso ogni volta che viene passato i valori nell'ordine sbagliato. In questo modo il codice chiamante può controllare e scambiare i parametri, se necessario. In questo modo gli utenti di questa "funzionalità" diventeranno consapevoli e faranno la cosa giusta (che non conosci in anticipo).