“Entre x e y” deve ser comutativo?

26

No meu aplicativo, existem alguns modelos de expressão predefinidos que podem ser usados para filtrar dados. Um deles é " between x and y". Um engenheiro de controle de qualidade afirma que há um defeito em sua definição porque " between 100 and 200" fornece resultados diferentes de " between 200 and 100". A expressão é traduzida internamente para " value >= x and value <= y", portanto, obviamente não há resultados quando o segundo limite é mais baixo que o primeiro. Eu verifiquei que o mesmo comportamento está no SQL - " between x and y" assume que y> = x ou não há resultados. Isso significa que o operador não é comutativo, pelo menos no SQL.

Então, o controle de qualidade está certo de que " between x and y" deve ser comutativo?

requirements

— pkalinow
fonte

11

Não, mas talvez sua interface do usuário fique vermelha quando alguém a digitar errado.

— Ewan

3

Além disso, é um daqueles> = <= deve ser tão exclusiva que você pode encadear 100-> 200 200> 300 etc sem obter sobreposições

— Ewan

23

Não está claro se betweendeve incluir ou excluir os valores mais altos e mais baixos. A pessoa do controle de qualidade pode ser pedante, mas enquanto houver incerteza, alguém precisará esclarecer as histórias / requisitos do usuário. Pode acontecer que da maneira como é feito, como deveria ser, mas é necessário tomar uma decisão.

— Bent

11

Não é um caso de certo ou errado. É um caso de ... como a empresa deseja que o aplicativo se comporte? A resposta é qual funcionalidade é esperada. Os debates técnicos não direcionam a funcionalidade necessária. A funcionalidade necessária gera debates técnicos e, esperançosamente, inspira a melhor solução para os negócios.

— Brad Thomas

2

Esta pergunta é mais sobre o que o usuário espera do que sobre o que um programador espera. Como tal, seria mais apropriado na Experiência do Usuário .

— Makyen 27/02

32

Se sua especificação atual deixa isso indefinido, o comportamento é completamente arbitrário, não há definição "certa" ou "errada". Portanto, se o seu engenheiro de controle de qualidade não puder apontar o parágrafo exato da especificação em que esse comportamento está definido, você provavelmente poderá negar a solicitação dele (embora não pareça ser um requisito que exija muito esforço para implementá-lo). Se você não conseguir encontrar um consenso, uma pessoa em sua equipe terá que tomar uma decisão sobre o que é mais importante no contexto do aplicativo:

seguindo o padrão SQL o mais próximo possível
não segui-lo devido à ergonomia, casos de uso específicos ou outros requisitos

Qualquer que seja a decisão que sua equipe tome, pode ser uma boa idéia documentar o comportamento e o motivo pelo qual a decisão foi tomada.

— Doc Brown
fonte

57

você provavelmente pode negar o pedido dele => Na verdade, eu diria que, em primeiro lugar, o comportamento deve ser definido. Em seguida, você pode agradecer ao responsável pelo controle de qualidade por apontar o problema e dizer que agora ele está especificado para funcionar de <maneira específica> (e verifique se o código corresponde à especificação).

— Matthieu M.

1

@MatthieuM. Eu acho que é uma resposta separada que deveria ter 33 votos positivos. ;)

— jpmc26 27/02

1

Converta bug em aprimoramento e deixe-o no backlog por perpetuidade. Agradeço ao controle de qualidade por sua diligência.

— Sandy Chapman

1

@MatthieuM. Sim, no mundo ideal, haveria um requisito claro para cada detalhe. Em tal caso, eu não teria necessidade de fazer perguntas sobre Stack Troca :)

— pkalinow

@pkalinow: Acho que você não entendeu meu comentário. Meu argumento foi que, antes de encerrar o bug, você deve (1) agradecer ao responsável pelo controle de qualidade por apontar um pedaço de código subespecificado e (2) sentar junto com quem estiver interessado em realmente especificar o comportamento. Isso pode significar atribuir o relatório de controle de qualidade a quem está encarregado de escrever as especificações, ao proprietário do produto, se você tiver essas coisas, etc ... então, depois que o comportamento que deveria ter sido acordado, você poderá avaliar se o software precisa ser alterado ou não. Talvez isso significa mudar o software, talvez ele vai dizer fechando o relatório ...

— Matthieu M.

13

Esta é uma questão de usabilidade ou experiência do usuário. Como o SQL ou qualquer outro sistema se comporta é irrelevante, a questão é o que faz mais sentido da perspectiva dos usuários.

O comportamento atual não faz sentido da perspectiva do usuário. Xey devem ser intercambiáveis ou não deve ser permitido selecionar um x maior que y. Permitir x maior que y, mas retornar um conjunto vazio, introduz uma possibilidade desnecessária de erros sem fornecer nenhum benefício.

Portanto, o engenheiro de controle de qualidade está correto, pois existe um defeito, mas a solução proposta não é necessariamente a melhor. Você precisa executar testes de usabilidade para decidir isso ou, pelo menos, perguntar a alguns usuários representativos o que lhes parece mais natural.

Como alternativa, você pode fazer a pergunta em /ux// . As pessoas ali sabem alguma coisa sobre a experiência do usuário.

— JacquesB
fonte

11

Existem algumas opções sensatas, e a escolha depende do resto do sistema e das expectativas de seus usuários.

Você pode, como ressalta o engenheiro de controle de qualidade, tornar a expressão comutativa e a tradução seria

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

Você pode restringir o uso válido a x <= y , o que exige que sua interface do usuário possa exibir "isso não é uma expressão válida" o mais cedo possível.

Como uma variação do acima, a restrição x < yse você tiver uma expressão equals xe preferir que avaliarvalue >= x and value <= x

— Caleth
fonte

Nota: Por favor, não faça a declaração value >= min(x, y) and value <= max(x, y). Pré-calcule o que puder para salvar o trabalho do servidor de banco de dados, especialmente se for redundante assim (você pode executar as operações relevantes uma vez e definir os dois resultados de acordo). Pode não interessar, dependendo do servidor de banco de dados e dos valores específicos em que você está inserindo, mas um servidor SQL mal escrito pode executar o mine maxpara cada registro se você os colocar no wheree se pode retirar esse esforço , não há razão para não fazê-lo.

— Fund Monica's Lawsuit

6

Por favor, não ouça QPaysTaxes - otimizar as coisas sem nunca medir a necessidade é exatamente o que Knuth chamou de "otimização prematura sendo a raiz de todo mal". As chances são altas na maioria dos códigos do mundo real; você não notará diferença de velocidade se Min e Max forem calculados para cada registro, mas os valores pré-calculados (e, portanto, a introdução de código extra e redundância extra) tornarão o programa muito menos sustentável.

— Doc Brown

@DocBrown Eu concordo que não devemos fazer alterações para obter ganhos potenciais de desempenho sem medir, mas, contrariamente à sua afirmação, consideraria os limites pré-calculados mais legíveis que os de uma linha e, portanto, mais sustentáveis.

— Jacob Raihle

@ JacobRaihle: isso pode ser opinativo, mas para o meu gosto value >= min(x, y) and value <= max(x, y)é tão legível quanto value >= minXY and value <= maxXY, onde minXYe maxXYsão os limites pré-calculados. No entanto, para o último, será necessário escrever um código para adicionar essas novas duas variáveis ao sistema, preenchê-las antecipadamente, não se esqueça de atualizar esses valores quando xey mudar, e assim por diante. Dados redundantes sempre apresentam um certo risco de erros.

— Doc Brown

5

Em um cenário não interativo, onde seus limites são criados por um script, geralmente faz sentido exigir que eles estejam em ordem. Isso cria menos uma verificação de validação, faz mais sentido semanticamente e é trivial de gerenciar.

Em um ambiente interativo, você deseja ajudar o usuário. Se possível, crie uma GUI que não permita a inserção de intervalos trocados ou, pelo menos, facilite a inserção de intervalos em ordem. Se você estiver inserindo os intervalos por texto, pegue uma página do vim, esse modelo de usabilidade e solicite ao usuário que troque automaticamente os intervalos invertidos:

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

Se seu engenheiro de controle de qualidade não tivesse nada no UX para mostrar a ele que um intervalo invertido seria indesejável, ele fez uma suposição razoável.

— Karl Bielefeldt
fonte

2

Francamente? Não use "entre". Em absoluto.

Primeiro, o termo é incrivelmente ambíguo, especialmente em inglês. É comutativo? Os termos são exclusivos? Inclusivo?

Segundo, se você estiver fazendo uma interface separada do back-end, não se preocupe com o comportamento do back-end; e também não permita que seus usuários assumam comportamentos herdados. Claro, o SQL define BETWEENcomo inclusivo, mas esse quase nunca é o comportamento desejado (por exemplo - se você fizer algo como rows BETWEEN :start and :start + :strideobter stride + 1linhas).

Em vez disso, você deve listar explicitamente as comparações para os pontos de extremidade. "Maior ou igual a x". "Antes de hoje". Isso remove a ambiguidade. Também ajuda a escrever um código mais limpo e evita alguns erros traiçoeiros. O exemplo de linhas anteriores é essencialmente o post de Djikstra sobre indexação . E permitir que o SQL use um limite superior inclusivo em alguns tipos pode resultar na seleção de dados incorretos .

— Musa Mecânica
fonte

Bem, vale a pena pensar. E obrigado pelos links. Pós o Dijkstra' provavelmente não é muito relevante, mas interessante :)

— pkalinow

Isso realmente não responde à pergunta do OP, mas aumenta a confusão.

— Roland Tepp 06/03/19

1

Não é produtivo discutir com seu controle de qualidade sobre quem está "certo" e quem está "errado". Você interpretou as especificações de forma diferente do que elas. Isso significa que a especificação é suficientemente ambígua para exigir esclarecimentos.

Se a interface do usuário for a especificação e não for o comportamento que o controle de qualidade espera, não será o comportamento que alguns usuários esperam. Isso indica um problema de usabilidade (mesmo se você quiser discutir o PEBKAC). Trabalhe com seu controle de qualidade para encontrar uma solução satisfatória para isso.

Como ponto geral, tenha cuidado com palavras como "entre" que parecem claras, mas não são. Além do seu desacordo sobre se deve ou não ser comutado, há problemas com a inclusão de ambos os lados e podem intuitivamente significar coisas diferentes em domínios diferentes (por exemplo, "entre sexta e segunda" significa algo diferente para a maioria das pessoas do que "entre segunda e segunda" Sexta-feira")

— Martijn
fonte

1

Vou bifurcar um princípio UNIX que fala sobre interfaces simples.

Onde quer que exista uma interface que você esteja oferecendo ao mundo exterior, mantenha a coisa o menos surpreendente possível!

Agora que reduzi a declaração do problema para uma mais pragmática, acho que você levará apenas alguns momentos para perceber que, ao especificar intervalos de números, é óbvio manter o menor como o anterior ***. Se ainda é um enigma, pense assim: quantas vezes você usou a maneira inversa de representar dois números e dizer às crianças como compará-los?

Se o seu engenheiro de controle de qualidade chamar isso de bug, diga-lhe educadamente que espera alguns erros reais , e não maneiras de transmitir energia dispendiosa em coisas triviais.

— an4
fonte

0

Faça seu código de depuração gerar uma condição de erro ou registrar um aviso sempre que os valores forem passados na ordem errada. Dessa forma, o código de chamada pode verificar e trocar parâmetros, se necessário. Dessa forma, os usuários desse 'recurso' ficarão cientes e farão a coisa certa (que você não sabe de antemão).

— Grimaldi
fonte