Aqui está uma pergunta interessante de Mike Stall: o que é pior do que cair?
Mike fornece a seguinte lista de cenários de acidentes, na ordem do melhor para o pior:
- O aplicativo funciona como esperado e nunca trava.
- O aplicativo trava devido a bugs raros que ninguém percebe ou com os quais ninguém se importa.
- O aplicativo trava devido a um bug comumente encontrado.
- O aplicativo trava e para de responder devido a um bug comum.
- O aplicativo trava muito depois do bug original.
- O aplicativo causa perda e/ou corrupção de dados.
Mike ressalta que há uma tensão natural entre…
- falhar imediatamente quando seu programa encontrar um problema, por exemplo, “falhar rapidamente”
- tentando se recuperar do estado de falha e prosseguir normalmente
A filosofia por trás do “fail fast” é melhor explicada em Artigo de Jim Shore (pdf).
Algumas pessoas recomendam tornar seu software robusto, contornando os problemas automaticamente. Isso faz com que o software “falhe lentamente”. O programa continua funcionando logo após um erro, mas falha de forma estranha mais tarde. Um sistema que falha rapidamente faz exatamente o oposto: quando ocorre um problema, ele falha imediata e visivelmente. A falha rápida é uma técnica não intuitiva: “Falhar imediata e visivelmente” parece que tornaria o software mais frágil, mas na verdade o torna mais frágil.
mais frágil, mas na verdade o torna mais robusto. Os bugs são mais fáceis de encontrar e corrigir, portanto, menos bugs entram em produção.
Falhar rápido é um conselho razoável – se o senhor for um desenvolvedor. O que poderia ser mais fácil do que interromper tudo de forma brusca no minuto em que o senhor recebe um byte de dados que não lhe agrada? Os computadores são espetacularmente implacáveis, portanto, é natural que os desenvolvedores reflitam esse masoquismo diretamente nos usuários.
Mas, do ponto de vista do usuário, falhar rapidamente não é útil. Para ele, é apenas mais um diálogo de erro sem sentido impedindo-os de realizar seu trabalho. Os melhores softwares nunca incomodam os usuários com erros triviais e sem sentido. mais atencioso do que isso. Infelizmente, a tentativa de ajudar o usuário corrigindo o erro pode piorar as coisas, levando a falhas sutis e catastróficas no futuro. À medida que o senhor avança na lista de Mike, a dor aumenta exponencialmente. Tanto para os desenvolvedores e usuários. A solução de problemas nº 5 é uma marcha da morte brutal e, quando chegar ao nº 6 – o senhor perdeu ou corrompeu os dados do usuário -, terá sorte se tiver algum usuário esquerda para corrigir bugs para.
O que é interessante para mim é que, apesar de causar mais do que minha cota de falhas de software e telas azuis de hardware, eu nunca perdi dados ou tive meus dados corrompidos. O senhor imaginaria que a Lei de Murphy forçaria o pior resultado possível pelo menos uma vez por ano, mas isso é extremamente raro em minha experiência. Talvez esse seja um sinal encorajador para o estado atual da engenharia de software. Ou talvez eu apenas tenha tido sorte.
Então, o que nós, como desenvolvedores de software, podemos fazer a respeito disso? Se adotarmos uma estratégia de “falhar com a maior frequência e da forma mais desagradável possível”, claramente falhamos com nossos usuários. Mas se corrompermos ou perdermos os dados de nossos usuários por meio de tentativas equivocadas de evitar mensagens de erro – se não tratarmos os dados de nossos usuários como sacrossantos -, teremos também falhou com nossos usuários. O senhor precisa fazer as duas coisas ao mesmo tempo:
- Se o senhor pode corrigir o problema com segurança, o senhor deve. Assuma a responsabilidade por seu programa. Não se deixe levar pelo caminho mais fácil, colocando o ônus de lidar com todos os problemas diretamente nos usuários.
- Se o senhor não pode corrigir o problema com segurança, sempre opte por proteger os dados do usuário. A proteção dos dados do usuário é uma confiança sagrada. Se o senhor prejudicar esse contrato básico de confiança entre o usuário e o seu programa, estará prejudicando não apenas a sua credibilidade, mas a credibilidade de todo o setor de software como um todo. Depois de serem prejudicados pela perda ou corrupção de dados, os usuários não perdoam tão cedo.
O princípio orientador aqui, como sempre, deve ser o seguinte respeitar seus usuários. Faça a coisa certa.