Para mim essa abordagem "otimista" acaba carregando um potencial perigo para a e · FelipeLimaCoelho

Para mim essa abordagem "otimista" acaba carregando um potencial perigo para a experiência do usuário, me lembrando até dos mandamentos do Go Horse. Te dou 2 analogias para tentar te mostrar como um otimismo pode levar a péssimas situações para uma pessoa/usuário:

Você confia no seu código e acredita que ele sempre irá cumprir o seu propósito, pois você utiliza linguagem tipada e sempre confere o resultado seja no console, debug ou interface e, dessa forma, você acredita que não precisará realizar testes unitários, de integração etc. Nem preciso dizer que isso é um Go Horse de carteirinha e essa prática vai dar merd@ em algum momento.
Um princípio do UX é que se você faz uma ação, você precisa saber o resultado da sua ação. Se você recebe o resultado da sua ação e após algum momento, por qualquer motivo, esse resultado precisa vir com "pedido de desculpas" falando que o resultado não era realmente o que antes foi afirmado, isso fere totalmente o princípio mencionado, além de proporcionar uma experiência em que o usuário sempre precisará ficar alerta devido a falta de compromisso com a "verdade".

Dito isso, inicialmente o otmimismo parece realmente produtivo mas, ao meu ver, é preciso ter um certo pragmatismo ao codar.

Por isso, como mencionei anteriormente, a abordagem possui seus lados positivos e negativos. Mas tenha cuidado pois aplicar o conceito de interface otimista não implica que toda a aplicação deva seguir essa linha.

Sendo assim deve-se utilizar essa abordagem em situações específicas onde ela possa agregar valor à experiência do usuário.

Por exemplo, não é recomendável aplicar a abordagem otimista na funcionalidade principal da aplicação. No entanto, pode ser aplicada em situações triviais, onde não há muita lógica ou regra de negócio associada, onde a chance de falhar é baixa ou sem valor grandioso em caso de falha.

Um exemplo disso é, atualizar o nome do cachorro do usuário - uma tarefa que não está diretamente ligada ao core da aplicação. Qual a chance de algo dar errado nesse caso? Digo no sentido de o sistema apresentar um erro, já que não há uma regra de negócio cabeluda para definir o nome do cachorro do usuário.

E mesmo que ocorra um problema, como o sistema não estar online por alguma circunstância, qual seria o impacto em informar posteriormente ao usuário que a mudança não foi bem-sucedida? Afinal, essa funcionalidade não é essencial para o funcionamento do sistema.

Entendo que isso possa parecer uma violação do princípio de UX, mas em algumas situações, pode-se abrir mão desse princípio em prol da fluidez e velocidade na interação com o usuário.
É igual desenvolver uma aplicação com conceitos SOLID, você vai usar todos os conceitos? de S a D? Não, você vai usar o que for pertinente e quando for pertinente!

É essencial ressaltar que a abordagem otimista não substitui a necessidade de testes, sejam eles unitários, de integração ou E2E. A realização de testes é fundamental para garantir a funcionalidade da aplicação, independentemente da abordagem utilizada na interface - seja ela tradicional, otimista ou qualquer outra! Os testes são elementos agnósticos a abordagem utilizada na interface.

Linguagem tipada ou dinâmica, programador experiente ou não, falhas e bugs podem e vão ocorrer em qualquer momento ou feature da aplicação. Portanto, é importante reconhecer os limites e possibilidades da abordagem otimista, e utilizá-la quando cabível, como mais uma ferramenta em nossa caixa de ferramentas de desenvolvimento.