“Tra xey” dovrebbe essere commutativo?

26

Nella mia applicazione ci sono alcuni modelli di espressioni predefiniti che possono essere utilizzati per filtrare i dati. Uno di questi è " between x and y". Un ingegnere addetto al controllo qualità afferma che esiste un difetto nella sua definizione, perché " between 100 and 200" fornisce risultati diversi rispetto a " between 200 and 100". L'espressione viene tradotta internamente in " value >= x and value <= y", quindi ovviamente non ci sono risultati quando il secondo limite è inferiore al primo. Ho verificato che lo stesso comportamento sia in SQL - " between x and y" presuppone che y> = x o che non ci siano risultati. Significa che l'operatore non è commutativo, almeno in SQL.

Quindi, il QA è giusto che " between x and y" dovrebbe essere commutativo?

requirements

— pkalinow
fonte

11

No, ma forse il tuo ui dovrebbe diventare rosso quando qualcuno lo riempie in modo sbagliato.

— Ewan,

3

inoltre, uno di quelli> = <= dovrebbe essere esclusivo in modo da poter incatenare 100-> 200 200-> 300 ecc senza sovrapposizioni

— Ewan

23

Non è chiaro se betweenincludere o escludere i valori inferiore e superiore. La persona addetta al controllo qualità può essere pedante ma fintanto che c'è incertezza, qualcuno deve chiarire le storie / i requisiti degli utenti. Si potrebbe scoprire che il modo in cui viene fatto è come dovrebbe essere, ma una decisione deve essere presa.

— Piegato il

11

Non è un caso di giusto o sbagliato. È un caso di ... come fa l'azienda a comportarsi con l'applicazione? La risposta è quale funzionalità è prevista. I dibattiti tecnici non guidano la funzionalità richiesta. Le funzionalità richieste guidano i dibattiti tecnici e si spera ispirino la migliore soluzione per l'azienda.

— Brad Thomas,

2

Questa domanda riguarda più ciò che l'utente si aspetta che ciò che un programmatore si aspetta. Come tale, sarebbe più appropriato sull'esperienza utente .

— Makyen,

32

Se le specifiche attuali lasciano questo non definito, il comportamento è completamente arbitrario, non esiste una definizione "giusta" o "sbagliata". Quindi, se il tuo ingegnere addetto al controllo qualità non può indicarti il paragrafo esatto nelle specifiche in cui è definito questo comportamento, probabilmente puoi rifiutare la sua richiesta (anche se non sembra essere un requisito che richiede molti sforzi per implementarlo). Se entrambi non riesci a trovare un consenso, una persona del tuo team deve prendere una decisione su cosa è più importante nel contesto dell'applicazione:

seguire lo standard SQL il più vicino possibile
non seguirlo a causa di ergonomia, casi d'uso specifici o altri requisiti

Qualunque sia la decisione presa dalla tua squadra, potrebbe essere una buona idea documentare il comportamento e il motivo per cui la decisione è stata presa.

— Doc Brown
fonte

57

probabilmente puoi negare la sua richiesta => In realtà direi che prima di tutto, il comportamento dovrebbe essere definito. Quindi puoi ringraziare il responsabile della qualità per aver segnalato il problema e dire che ora è specificato per funzionare in <modo specifico> (e assicurarti che il codice corrisponda alle specifiche).

— Matthieu M.

1

@MatthieuM. Penso che sia una risposta separata che dovrebbe avere 33 voti propri. ;)

— jpmc26,

1

Converti il bug in miglioramento e lascialo nel backlog per sempre. Grazie a QA per la loro diligenza.

— Sandy Chapman,

1

@MatthieuM. sì, nel mondo ideale ci sarebbe un chiaro requisito per ogni dettaglio. In tal caso, non avrei bisogno di porre domande su Stack Exchange :)

— pkalinow,

@pkalinow: penso che tu abbia frainteso il mio commento. Il mio punto era che prima di chiudere il bug, dovresti (1) ringraziare il responsabile della qualità per aver sottolineato un pezzo di codice non specificato e (2) sederti insieme a chiunque sia interessato a specificare effettivamente il comportamento. Ciò può significare assegnare il rapporto QA a chiunque sia incaricato di scrivere le specifiche, al proprietario del prodotto se si dispone di tali elementi, ecc ... quindi, una volta concordato il comportamento che dovrebbe essere stato concordato, è possibile valutare se il software deve essere modificato o no. Forse significherà cambiare il software, forse significherà chiudere il rapporto ...

— Matthieu M.

13

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 degli utenti.

Il comportamento attuale non ha senso dal punto di vista dell'utente. O x e y dovrebbero essere intercambiabili o non dovrebbe essere consentito selezionare una x maggiore di y. Consentire x maggiore di y ma restituire un set vuoto introduce una possibilità non necessaria di errori senza fornire alcun vantaggio.

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

In alternativa, puoi porre la domanda all'indirizzo /ux// . Le persone laggiù in realtà sanno qualcosa o due sull'esperienza utente.

— JacquesB
fonte

11

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

È possibile, come sottolinea l'ingegnere addetto al controllo qualità, rendere l'espressione commutativa e 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, il che richiede piuttosto che la tua interfaccia utente possa visualizzare "che non è un'espressione valida" il prima possibile.

Come variazione di quanto sopra, la restrizione x < yse hai un'espressione equals xe preferisci quella alla valutazionevalue >= x and value <= x

— Caleth
fonte

Nota: non rilasciare la dichiarazione stessa value >= min(x, y) and value <= max(x, y). Calcola in anticipo cosa puoi salvare il tuo server di database, specialmente se è ridondante in questo modo (puoi eseguire le operazioni pertinenti una volta e impostare entrambi i risultati di conseguenza). Potrebbe non importare, a seconda del server di database e dei valori specifici che stai inserendo, ma un server SQL scritto male potrebbe benissimo eseguire il mine maxper ogni record se li inserisci wheree se riesci a eliminare tale sforzo , non c'è motivo di non farlo.

— Finanzia la causa di Monica il

6

Per favore, non ascoltate QPaysTaxes: ottimizzare le cose senza mai misurare la necessità è esattamente ciò che Knuth chiamava "l'ottimizzazione prematura essendo la radice di tutti i mali". Le probabilità sono molto alte nella maggior parte del codice del mondo reale che non noterai una differenza di velocità se Min e Max sono calcolati per ogni record, ma i valori precalcolanti (e quindi introducendo codice aggiuntivo e ridondanza extra) renderanno il programma molto meno gestibile.

— Doc Brown,

@DocBrown Sono d'accordo sul fatto che non dovremmo apportare modifiche ai potenziali guadagni in termini di prestazioni senza misurare, ma contrariamente alla tua affermazione troverei limiti precalcolati più leggibili di un one-liner e quindi più mantenibili.

— Jacob Raihle

@JacobRaihle: questo può essere supponente, ma per i miei gusti value >= min(x, y) and value <= max(x, y)è leggibile come value >= minXY and value <= maxXY, dove minXYe maxXYsono i limiti precalcolati. Tuttavia, per quest'ultimo dovrà scrivere del codice per aggiungere queste nuove due variabili al sistema, riempirle in anticipo, non dimenticare di aggiornare questi valori quando cambia xey, e così via. I dati ridondanti comportano sempre un certo rischio di errori.

— Doc Brown

5

In un'impostazione non interattiva, in cui i limiti vengono 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, si desidera aiutare l'utente. Se possibile, crea una GUI che non consenta l'inserimento di intervalli scambiati, o almeno rende più facile l'inserimento degli intervalli in ordine. Se stai inserendo gli intervalli di testo, prendi una pagina da VIM, quel parametro di usabilità, e invita l'utente a scambiare automaticamente gli intervalli invertiti:

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

Se il tuo ingegnere addetto al controllo qualità non aveva nulla da invidiare a UX per mostrargli che una gamma invertita sarebbe indesiderabile, allora ha fatto un presupposto ragionevole.

— Karl Bielefeldt
fonte

2

Francamente? Non usare "tra". Affatto.

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

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

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 di prima è essenzialmente il post di Djikstra sull'indicizzazione . E consentire a SQL di utilizzare un limite superiore inclusivo su alcuni tipi può comportare la selezione di dati errati .

— Clockwork-Muse
fonte

Bene, vale la pena pensarci. E grazie per i collegamenti. Il post di Dijkstra non è probabilmente molto pertinente, ma interessante :)

— pkalinow il

Questo in realtà non risponde alla domanda OP, ma aggiunge alla confusione.

— Roland Tepp,

1

Non è produttivo discutere con il tuo QA 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 QA, non sarà il comportamento che almeno alcuni utenti si aspettano. Ciò indica un problema di usabilità (anche se si desidera discutere PEBKAC). Collabora con il tuo QA per trovare una soluzione soddisfacente a questo.

Come punto generale, fai attenzione con parole come "in mezzo" che sembrano chiare, ma non lo sono. A parte il tuo disaccordo sull'opportunità di permutare, si tratta di problemi con inclusività su entrambe le estremità e possono intuire in modo intuitivo cose diverse su domini diversi (ad esempio, "tra venerdì e lunedì" significherà qualcosa di diverso per la maggior parte delle persone rispetto a "tra lunedì e Venerdì")

— Martijn
fonte

1

Forcherò un principio UNIX che parla di interfacce semplici.

Ovunque ci sia un'interfaccia che stai offrendo al mondo esterno, mantieni la cosa il meno sorprendente possibile!

Ora che ho ridotto l'affermazione del problema a una più pragmatica, penso che ci vorranno solo pochi istanti per rendersi conto che quando si specificano gli intervalli di numeri, è ovvio *** mantenere il più piccolo come il precedente ***. Se è ancora un enigma, pensa in questo modo- Quante volte hai usato il modo inverso di rappresentare due numeri mentre dicevi ai bambini come confrontarli?

Se il tuo ingegnere addetto al controllo qualità lo chiama un bug, digli cortesemente che ti aspetti alcuni bug reali e non modi per trasmettere energia costosa su cose banali.

— an4
fonte

0

Fai in modo che il tuo codice di debug generi una condizione di errore o registri un avviso ogni volta che vengono passati i valori nell'ordine sbagliato. In questo modo il codice chiamante può controllare e scambiare parametri, se necessario. In questo modo gli utenti di questa 'funzione' diventeranno consapevoli e faranno la cosa giusta (che non si conosce in anticipo).

— Grimaldi
fonte