Para mim, o Idiot Proofing significa apenas garantir que o usuário não possa quebrar um pedaço de software, mesmo que tenha tentado. Por exemplo, se um valor for lido em uma caixa de texto e convertido em um dobro, se o software subjacente for à prova de idiotas, ele não será interrompido se o usuário digitar um valor que não seja o dobro.

Recentemente, escrevi um cronograma de desenvolvimento e um dos itens foi nomeado "Interface do usuário à prova de idiotas". As pessoas que estou construindo este software fingiram estar brincando ofensivas com o termo, mas posso ver onde esse termo realmente deixaria as pessoas chateadas.

Qual é a melhor maneira de dizer isso?

Se você estiver incluindo a "Interface do usuário à prova de idiotas" como um item de agendamento, estará apenas tentando adicionar qualidade ao seu software posteriormente. Qualquer sistema bem projetado validará suas entradas e dará orientações claras aos usuários, como é óbvio, não é algo que é colocado na programação como um item discreto (que é então sujeito a remoção quando a crise inevitável ocorrer).

Como alternativa, se for um item discreto (sei como algumas organizações pensam sobre agendamento), a "interface do usuário à prova de idiotas" deve ser alterada para "Biblioteca de validação de entrada" e movida para a frente do agendamento.

Validação de entrada do usuário que eu pensaria que seria um termo profissional. Não vejo nada de errado com a prova de idiotas, se usado em documentos internos.

Endurecimento é uma boa palavra. Se alguém perguntar, diga a eles que a primeira passagem no software geralmente é escrita para cenários ideais e, como ferramentas de aço, o software precisa ser "reforçado" para o uso cotidiano difícil por clientes reais.

Robustificação é outra boa palavra para isso - você está tornando o código robusto para os tipos de desafios que os clientes reais colocam nele.

Ambas as palavras parecem legais e industriais, não culpam os usuários ou os programadores, e entendem o assunto.

Aliás, aqui está o velho mascote de Metrowerks, Arnold, o cara que costumava nos ajudar os programadores de Mac a endurecer e a fortalecer nosso código com um forno de tratamento térmico, uma forja e uma bigorna e uma marreta pequena:

Programação defensiva

É o que eu fui ensinado. Voltar quando tivemos que talhar nossos próprios pedaços de madeira.

Se você quer ser PC, chame de programação "antecipatória".

Quando eu estava aprendendo, chamamos de prova de balas .

A maioria dos outros eufemismos que li também se aplica.

Que tal um sistema ou interface do usuário "tolerante a falhas"?

"Prova idiota" deve consistir em ambos

• projetar a interface do usuário para que seja fácil de usar e leve o usuário a inserir dados da maneira que os programadores esperam; e

• testando a interface do usuário para determinar se a interface pode ser quebrada inserindo valores de dados inesperados.

Ambas as etapas podem aparecer razoavelmente no cronograma de desenvolvimento, onde o design é avaliado por um especialista em experiência do usuário e o código entregue é testado por um testador para garantir que dados inválidos sejam manipulados corretamente (para o que "corretamente" significa para o seu aplicativo).

A prova de idiotas envolve muito mais do que simples validação de entrada. Eu nem incluiria isso em sua definição.

A validação de entrada é um processo em que você limpa e valida os dados do usuário para eliminar valores ilegais / sem sentido. Isso sempre deve ser feito com qualquer informação vinda de fora do seu programa, a fim de eliminar o óbvio e também proteger-se de ataques (por exemplo, ataques de injeção de sql).

Eu consideraria a prova de idiotas um conjunto de lógicas para impedir que o usuário acidentalmente causasse grandes danos a si próprio por meios legais.

Por exemplo, fazer rmrejeitar o comando rm -rf /e fechar variantes não tem nada a ver com validação ou correção. É um comando perfeitamente válido. Infelizmente, é um comando que pode e pode eliminar todos os seus dados de todos os seus discos no Unix / Linux. A prova idiota disso rejeitaria esse comando e sugeriria rm -rf --i-really-mean-this /, ou se estiver no modo interativo, que o usuário digite uma resposta afirmativa após um aviso.

Qualquer coisa que seja destrutiva para o sistema deve ser à prova de idiotas. Qualquer coisa que possa causar constrangimento em potencial também pode ser um candidato (por exemplo, "você tem certeza de que deseja enviar este e-mail sem anexo, mesmo que tenha mencionado um no seu texto?" E "você tem certeza de que deseja enviar este e-mail para o empresa inteira? ")

A prova de idiotas é uma colaboração entre o controle de qualidade (tentando ser o melhor idiota) e o desenvolvimento (tentando antecipar todos esses cenários e projetá-los).

Quanto a um sinônimo mais amigável , posso sugerir "análise destrutiva do caminho do código" ou "ativar o feedback do usuário para operações críticas". Qualquer que seja o nome, você deve realmente iniciá-lo o mais cedo possível no processo de design.

"Verificação de sanidade" tende a funcionar muito bem com bastante frequência ...

Chame de "adicionando Poka-yokes à interface do usuário". http://en.wikipedia.org/wiki/Poka_yoke

"Tratamento de erros" ou "validação de entrada" seriam outros termos que eu usaria para o que você descreve. À prova de balas seria outro termo que eu poderia ver sendo usado em alguns círculos, pois a idéia aqui é tornar o software robusto o suficiente para lidar com quase tudo. Sólido como rocha seria outra gíria que eu poderia imaginar alguém querendo usar aqui também.

"Prova do pior cenário possível". Porque, como desenvolvedores, todos sabemos que se isso puder ser feito, será feito . Então você só precisa estar preparado para lidar com a pior situação do seu caso com seu software.

As medidas de segurança não são apenas uma maneira de proteger os usuários contra invasões cibernéticas externas, mas também contra si mesmos. Vivemos em um mundo imperfeito com usuários imperfeitos.

Gold-plating é o termo educado (e com um som muito positivo) que eu uso quando falo sobre melhorar a experiência da interface do usuário final de qualquer forma (GUI ou outra).

A prova de idiotas, como você diz, é a maior parte desse processo, junto com as melhorias no design ou no fluxo de trabalho (pense no reconhecimento do feedback do usuário final).

A idéia aqui é que você possa usar esse termo livremente no ambiente de trabalho e ser visto como um processo valioso (uma vez concluído) pelo gerenciamento e pelos usuários, mesmo que demore algum tempo (e, portanto, geralmente custa algum dinheiro).

muitos outros termos relacionados a esse processo (geralmente no final do ciclo) fazem com que pareça com esse processo:

• implica usuários (geralmente gerenciamento ;-) são burros
• é difícil de conseguir
• tem pouco patrimônio líquido

Ao associar o ouro ao processo (o metal geralmente equivale a "valor" em vez de "custo"), vi o processo mudar de despesa para investimento na mentalidade de alguns gerentes.

É como afirmar abertamente que, até que isso seja feito, esse pedaço de aço desajeitado ainda não é uma joia. Mas uma vez que é banhado ... então é valioso.

Utilizando com mais frequência em relação aos processos de fabricação, mas acho que um bom ajuste é o Poka-Yoke :

"[poka yo-ke] é um termo japonês que significa" proteção contra falhas "ou" à prova de erros "

Foi originalmente descrito como baka-yoke, mas como isso significa "à prova de idiotas" (ou "à prova de idiotas"), o nome foi alterado para o mais leve poka-yoke.

De maneira mais ampla, o termo pode se referir a qualquer restrição de modelagem de comportamento projetada em um produto para evitar operação incorreta pelo usuário ".

Um termo comum em lojas maiores também é garantia de qualidade (QA) .

É um termo geral e vago de propósito, que você pode moldar para seu próprio significado específico dentro do seu ciclo de liberação.

Chamamos isso de Prova Humana. Somos todos idiotas.