Como programadores, é nossa responsabilidade garantir que, quando algo der terrivelmente errado com nosso software, o usuário tenha um plano de fuga razoável. É uma questão de segurança fundamental no tratamento de erros de software que eu comparo aos onipresentes cartões de segurança das companhias aéreas.
Qual delas retrata com precisão a maneira como o o senhor trata o usuário no caso de uma emergência?
Se aprendi alguma coisa nos últimos trinta anos, foi que o senhor Eu escrevo software de baixa qualidade, com bugs. Não preciso apenas proteger meus usuários dos meus erros, preciso proteger a mim mesmo de meus erros também. É por isso que o a primeira coisa que faço em qualquer projeto novo é configurar uma estrutura de tratamento de erros. Os erros são inevitáveis, mas a ignorância não deveria ser. Se o senhor conhece os problemas, pode corrigi-los e responder a eles.
Observe que, quando digo “erros”, não me refiro a problemas mundanos e corriqueiros, como valores de formulário vazios, nenhum resultado ou arquivo não encontrado. Esses tipos de erros são abordados muito bem em 37 Signals’ Defensive Design for the Web: How to Improve Error Messages, Help, Forms, and Other Crisis Points (Como melhorar mensagens de erro, ajuda, formulários e outros pontos de crise).
É um ótimo livro; uma leitura rápida com muitas dicas visuais do que fazer e do que não fazer, lado a lado. No entanto, apesar do ícone de ponto de exclamação gigante na capa, ele trata principalmente da usabilidade fundamental da Web, não do tratamento de erros em si.
Estou falando do erros catastróficos — desastres reais. Casos em que um bug previamente desconhecido em seu código faz com que o aplicativo trave e queime de forma espetacular. Isso acontece em todos os aplicativos, sejam eles sites ou executáveis tradicionais.
A situação é bastante terrível neste momento, mas é possível fazer alguma recuperação de desastres, se o senhor planejar com antecedência.
- Não é função do usuário informar o senhor sobre erros em seu software!
Se os usuários tiverem que lhe dizer quando seu aplicativo falha e por quê, o senhor terá falhou totalmente com seus usuários. Não posso enfatizar isso o suficiente.
Já é ruim o suficiente o fato de o usuário ter que usar nosso software ruim; vamos realmente acrescentar um insulto à injúria pressionando-o a servir também como equipe de controle de qualidade? Se o senhor depender dos usuários para informá-lo sobre os problemas do seu software, verá apenas uma pequena fração dos erros gerais. A maioria dos usuários não se incomodará em informar o senhor sobre os problemas. Eles simplesmente deixarão de usar o aplicativo em silêncio.
Qualquer que seja a solução de tratamento de erros escolhida, ela deve registrar automaticamente tudo o que for necessário para solucionar a falha e, idealmente, enviar um conjunto completo de informações de diagnóstico de volta ao servidor. Isso é fundamental. Se o senhor ainda não tiver algo assim, faça-o imediatamente.
- Não exponha os usuários ao padrão tela da morte.
É verdade que não podemos fazer muito para nos recuperarmos desses tipos de falhas, mas confiar no sistema operacional ou no servidor da Web subjacente para fornecer as más notícias genéricas ao usuário é rude e impensado. Substitua a tela de falha padrão e forneça algo personalizado, algo relevante para o o senhor e o senhor pode se candidatar a o senhor usuários. Aqui estão algumas ideias:
- Informe aos usuários que a culpa é nossa, não deles.
- Informe ao usuário que o erro foi registrado e enviado.
- Se possível, sugira algumas soluções alternativas e opções de solução de problemas.
- Talvez até forneça informações de contato direto se eles estiverem realmente presos e precisarem desesperadamente fazer algo.
- Tenha um registro público detalhado dos erros do seu aplicativo.
Na minha experiência, nada motiva mais uma equipe do que um registro público detalhado de todas as falhas. É claro que deve haver um banco de dados de erros pesquisável e classificável em algum lugar, mas as notificações ativas também são uma boa ideia. As falhas são incrivelmente irritante para seus usuários. É justo que a equipe por trás do software compartilhe um pouco dessa dor a cada falha. O senhor poderia enviar um e-mail de erro, uma mensagem de texto ou uma mensagem instantânea para todos da equipe. Ou talvez fazer com que cada falha abra automaticamente um tíquete de bug em seu software de rastreamento de bugs. Cansado de lidar com todos esses e-mails de erro e/ou tíquetes de bug? Conserte o software para que o senhor não precise fazer isso!
- Aproveite a regra 80/20.
Depois de ter um registro abrangente de cada falha, o senhor pode classificar esses dados por frequência e dedicar seu esforço de codificação à resolução dos problemas mais comuns. Microsoft, com base nos dados de seu Windows Error Reporting Servicedescobriram que a correção de 20% dos principais bugs relatados resolveu 80% dos problemas dos clientese a correção de 1% dos principais bugs relatados resolveu 50% dos problemas dos clientes. Isso é muito importante! Deixe que o Princípio de Pareto trabalha para o senhor, não contra ele.
Como profissionais de software, devemos proteger nossos usuários – e a nós mesmos – de nossos erros. Colisão com responsabilidade!