the principle of least astonishment
expressãoprogramaçãodesenvolvimento web
Um componente deve se comportar como a maioria dos usuários espera; surpresa é defeito.
O princípio, em circulação desde os anos 1970, julga projetos pela distância entre o que fazem e o que um usuário razoável prevê: uma interface que espanta será mal usada, por melhor que seja a documentação. Vale para design de APIs, padrões de fábrica, tratamento de erros e UI. Quando duas implementações são igualmente corretas, entregue a que dispensa explicação.
Um sistema deve se comportar como seus usuários esperam e, onde isso for impossível, deve ao menos surpreender do jeito menos danoso. O princípio parece brando até você notar que a maioria das falhas de usabilidade e um bom número de incidentes de segurança são espanto: alguém raciocinou corretamente a partir de um modelo errado.
Ele se aplica com mais força às interfaces que engenheiros constroem uns para os outros. Uma função chamada get que também escreve, um sinalizador cujo sentido se inverte num caminho de código, um comando destrutivo que não pergunta: cada um é defensável isoladamente e cada um viola a expectativa que a pessoa traz de tudo o mais que já usou. Consistência com a convenção em geral vence a esperteza local, porque o modelo do leitor vem de outro lugar.
A dimensão de segurança merece nota própria. O espanto é onde moram os erros perigosos: um apagar que não confirma, um padrão que compartilha mais do que se espera, uma opção cujo nome sugere o oposto do que faz. Quando o caminho seguro e o caminho esperado divergem, os usuários acabam no esperado, então tornar o comportamento esperado o comportamento seguro vale mais que qualquer quantidade de documentação explicando a diferença.
Também conhecido como: POLA, least surprise