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
fuente
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.Respuestas:
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:
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.
fuente
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.
fuente
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ónequals xy prefiere eso a evaluarvalue >= x and value <= xfuente
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 elminymaxpara cada registro si los coloca enwhere, y si puede eliminar ese esfuerzo , no hay razón para no hacerlo.value >= min(x, y) and value <= max(x, y)es tan legible comovalue >= minXY and value <= maxXY, dóndeminXYymaxXYson 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.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:
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.
fuente
¿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ásstride + 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 .
fuente
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")
fuente
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.
fuente
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).
fuente