¿Debería "entre x e y" ser conmutativo?

26

En mi aplicación, hay algunas plantillas de expresión predefinidas que se pueden usar para filtrar datos. Uno de ellos es " between x and y". Un ingeniero de control de calidad afirma que hay un defecto en su definición, porque " between 100 and 200" da resultados diferentes que " between 200 and 100". La expresión se traduce internamente a " value >= x and value <= y", por lo que obviamente no hay resultados cuando el segundo límite es más bajo que el primero. Verifiqué que el mismo comportamiento está en SQL - " between x and y" supone que y> = x o que no hay resultados. Significa que el operador no es conmutativo, al menos en SQL.

Entonces, ¿es correcto el control de calidad que " between x and y" debería ser conmutativo?

requirements

— pkalinow
fuente

11

No, pero tal vez tu interfaz de usuario debería ponerse roja cuando alguien la llena incorrectamente.

— Ewan

3

también, uno de esos> = <= debe ser exclusivo para que pueda encadenar 100-> 200 200-> 300, etc. sin que se superpongan

— Ewan

23

No está claro si betweendebe incluir o excluir los valores inferiores y superiores. La persona de control de calidad puede ser pedante, pero siempre que haya incertidumbre, alguien necesita aclarar las historias / requisitos del usuario. Podría resultar que la forma en que se hace es como se supone que debe ser, pero hay que tomar una decisión.

— Doblado

11

No es un caso de bien o mal. Es un caso de ... ¿cómo quiere la empresa que se comporte la aplicación? La respuesta es qué funcionalidad se espera. Los debates técnicos no impulsan la funcionalidad requerida. La funcionalidad requerida genera debates técnicos y, con suerte, inspira la mejor solución para el negocio.

— Brad Thomas

2

Esta pregunta trata más sobre lo que el usuario espera que sobre lo que espera un programador. Como tal, sería más apropiado en la experiencia del usuario .

— Makyen

32

Si su especificación actual deja esto sin definir, el comportamiento es completamente arbitrario, no hay una definición "correcta" o "incorrecta". Por lo tanto, si su ingeniero de control de calidad no puede indicarle el párrafo exacto en la especificación donde se define este comportamiento, probablemente pueda negar su solicitud (aunque no parece ser un requisito que requiera mucho esfuerzo para implementarlo). Si ambos no pueden encontrar un consenso, una persona de su equipo debe tomar una decisión sobre qué es más importante en el contexto de la solicitud:

siguiendo el estándar SQL lo más cerca posible
no seguirlo debido a la ergonomía, casos de uso específicos u otros requisitos

Cualquiera sea la decisión que tome su equipo, puede ser una buena idea documentar el comportamiento y la razón por la cual se tomó la decisión.

— Doc Brown
fuente

57

probablemente pueda negar su solicitud => En realidad, diría que, ante todo, el comportamiento debe definirse. Luego, puede agradecer al tipo de control de calidad por señalar el problema y decir que ahora se especifica que funciona de manera <específica> (y asegúrese de que el código coincida con la especificación).

— Matthieu M.

1

@MatthieuM. Creo que es una respuesta separada que debería tener 33 votos a favor propios. ;)

— jpmc26

1

Convierta el error en una mejora y déjelo atrasado para siempre. Gracias QA por su diligencia.

— Sandy Chapman

1

@MatthieuM. Sí, en el mundo ideal habría un requisito claro para cada detalle. En tal caso, no necesitaría hacer preguntas en Stack Exchange :)

— pkalinow

@pkalinow: Creo que entendiste mal mi comentario. Mi punto era que antes de cerrar el error, debería (1) agradecer al tipo de control de calidad por señalar un fragmento de código poco especificado y (2) sentarse junto con quien esté interesado para especificar realmente el comportamiento. Esto puede significar asignar el informe de control de calidad a quien esté a cargo de escribir las especificaciones, al propietario del producto si tiene tales cosas, etc. ... luego, una vez que se haya acordado el comportamiento, puede evaluar si el software necesita un cambio o no. Tal vez signifique cambiar el software, tal vez signifique cerrar el informe ...

— Matthieu M.

13

Esta es una pregunta de usabilidad o experiencia de usuario. El comportamiento de SQL o de cualquier otro sistema es irrelevante, la pregunta es qué tiene más sentido desde la perspectiva de los usuarios.

El comportamiento actual no tiene sentido desde la perspectiva del usuario. O x e y deberían ser intercambiables o no debería permitirse seleccionar una x mayor que y. Permitir x más grande que y pero devolver un conjunto vacío introduce una posibilidad innecesaria de errores sin proporcionar ningún beneficio.

Por lo tanto, el ingeniero de control de calidad es correcto, hay un defecto, pero la solución propuesta no es necesariamente la mejor. Debes realizar pruebas de usabilidad. Decide esto, o al menos pregunta a algunos usuarios representativos qué les parece más natural.

Alternativamente, puede hacer la pregunta en /ux// . La gente de allí en realidad sabe una o dos cosas sobre la experiencia del usuario.

— JacquesB
fuente

11

Hay un par de opciones sensatas, y cuál elegir depende del resto del sistema y de las expectativas de sus usuarios.

Puede, como señala el ingeniero de control de calidad, simplemente hacer que la expresión sea conmutativa, y luego la traducción sería

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

Puede restringir el uso válido x <= y, lo que requiere que su IU pueda mostrar "esa no es una expresión válida" lo antes posible.

Como una variación de lo anterior, la restricción x < ysi tiene una expresión equals xy prefiere eso a evaluarvalue >= x and value <= x

— Caleth
fuente

Nota: No haga la declaración en sí value >= min(x, y) and value <= max(x, y). Precalcule lo que pueda para guardar el trabajo de su servidor de base de datos, especialmente si es redundante de esa manera (puede hacer las operaciones relevantes una vez y establecer ambos resultados en consecuencia). Puede que no importe, dependiendo del servidor de la base de datos y de los valores específicos en los que se está alimentando, pero un servidor SQL mal escrito podría realizar el miny maxpara cada registro si los coloca en where, y si puede eliminar ese esfuerzo , no hay razón para no hacerlo.

— Financia la demanda de Mónica el

66

No escuche QPaysTaxes: optimizar las cosas sin medir la necesidad es exactamente lo que Knuth llamó "optimización prematura siendo la raíz de todo mal". Hay muchas posibilidades de que en la mayoría de los códigos del mundo real no se note una diferencia de velocidad si se calculan Min y Max para cada registro, pero los valores de cálculo previo (y la introducción de código adicional y redundancia adicional) harán que el programa sea mucho menos mantenible.

— Doc Brown

@DocBrown Estoy de acuerdo en que no deberíamos hacer cambios para obtener ganancias potenciales de rendimiento sin medir, pero al contrario de lo que afirmas, los límites precalculados me resultarían más legibles que una línea y, por lo tanto, más mantenibles.

— Jacob Raihle

@JacobRaihle: esto puede ser dudoso, pero para mi gusto value >= min(x, y) and value <= max(x, y)es tan legible como value >= minXY and value <= maxXY, dónde minXYy maxXYson los límites precalculados. Sin embargo, para este último tendrá que escribir un código para agregar estas dos nuevas variables al sistema, llenarlas de antemano, no olvide actualizar estos valores cuando x e y cambien, y así sucesivamente. Los datos redundantes siempre introducen un cierto riesgo de errores.

— Doc Brown

5

En una configuración no interactiva, donde los límites son creados por un script, generalmente tiene sentido exigir que estén en orden. Esto crea una verificación de validación menos que hacer, tiene más sentido semánticamente y es trivial de administrar.

En una configuración interactiva, desea ayudar al usuario. Si es posible, cree una GUI que no permita ingresar rangos intercambiados, o al menos haga que sea más fácil ingresar rangos en orden. Si está ingresando los rangos por texto, tome una página de vim, ese modelo de usabilidad, y solicite al usuario que cambie automáticamente los rangos invertidos:

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

Si su ingeniero de control de calidad no tenía nada en el camino de UX para mostrarle que un rango invertido sería indeseable, entonces hizo una suposición razonable.

— Karl Bielefeldt
fuente

2

¿Francamente? No use "entre". En absoluto.

Primero, el término es increíblemente ambiguo, especialmente en inglés. ¿Es conmutativo? ¿Son exclusivos los términos? ¿Inclusivo?

Segundo, si está haciendo una interfaz divorciada del backend, no se preocupe por el comportamiento del backend; y tampoco permita que sus usuarios asuman comportamientos heredados Claro, SQL lo define BETWEENcomo inclusivo, pero este casi nunca es el comportamiento deseado (por ejemplo, si haces algo así rows BETWEEN :start and :start + :stride, obtendrás stride + 1filas).

En cambio, debería enumerar explícitamente las comparaciones para los puntos finales. "Mayor o igual que x". "Antes de hoy". Esto elimina la ambigüedad. También ayuda a escribir código más limpio y a evitar algunos errores insidiosos. El ejemplo de filas de antes es esencialmente la publicación de Djikstra sobre indexación . Y permitir que SQL use un límite superior inclusivo en algunos tipos puede resultar en la selección de datos incorrectos .

— Clockwork-Muse
fuente

Bueno, vale la pena pensarlo. Y gracias por los enlaces. La publicación de Dijkstra probablemente no sea muy relevante, pero sí interesante :)

— pkalinow

Esto realmente no responde a la pregunta de OP, sino que aumenta la confusión.

— Roland Tepp

1

No es productivo discutir con su QA sobre quién está "correcto" y quién está "equivocado". Interpretaste la especificación de manera diferente a como lo hicieron. Eso significa que la especificación es suficientemente ambigua que requiere aclaración.

Si la interfaz de usuario es la especificación, y no es el comportamiento que el control de calidad espera, no será el comportamiento que al menos algunos usuarios esperan. Eso indica un problema de usabilidad (incluso si desea discutir PEBKAC). Trabaje con su QA para encontrar una solución satisfactoria para eso.

Como punto general, tenga cuidado con palabras como "entre" que parecen claras, pero que no lo son. Además de su desacuerdo sobre si se debe conmutar, hay problemas con la inclusión en cada extremo, y pueden significar intuitivamente diferentes cosas en diferentes dominios (por ejemplo, "entre viernes y lunes" significará algo diferente para la mayoría de las personas que "entre el lunes y Viernes")

— Martijn
fuente

1

Tendré un principio de UNIX que habla de interfaces simples

Donde quiera que haya una interfaz que ofrezca al mundo exterior, ¡mantenga la cosa lo menos sorprendente posible!

Ahora que he reducido el enunciado del problema a uno más pragmático, creo que le tomará unos minutos darse cuenta de que al especificar rangos de números, es obvio que mantener el más pequeño como el *** anterior. Si todavía es un enigma, piense así: ¿Cuántas veces ha usado la forma inversa de representar dos números mientras les dice a los niños cómo compararlos?

Si su ingeniero de control de calidad lo llama un error, dígale cortésmente que está esperando algunos errores reales , y no formas de enviar energía costosa a cosas triviales.

— an4
fuente

0

Haga que su código de depuración arroje una condición de error o registre una advertencia cada vez que se pasan los valores en un orden incorrecto. De esta forma, el código de llamada puede verificar e intercambiar parámetros, si es necesario. De esta forma, los usuarios de esta 'característica' se darán cuenta y harán lo correcto (que no se sabe de antemano).

— Grimaldi
fuente