Se o senhor estiver esperando pelo lhe informem sobre problemas com seu site ou aplicativoo senhor está vendo apenas uma pequena fração de todos os problemas que estão realmente ocorrendo. A proverbial ponta do iceberg.
Além disso, se esse for o caso, lamento ter que lhe dizer isso, mas o senhor é péssimo no seu trabalho, que é saber mais sobre a integridade do seu aplicativo do que os usuários. Quando um usuário me informa sobre um erro genuíno que ocorreu com meu software, fico profundamente constrangido. E mais do que um pouco envergonhado. Não consegui ver e resolver o problema antes que o usuário me contasse. Negligenciei a bater com responsabilidade.
A primeira coisa que qualquer projeto de software executado de forma responsável deve construir é um recurso de relatório de exceções e erros. Ned Batchelder compara isso com colocar uma máscara de oxigênio em si mesmo antes de colocar uma em seu filho:
Quando ocorrer um problema em seu aplicativo, sempre verifique primeiro se o erro foi tratado adequadamente. Se não tiver sido, sempre corrija o código de tratamento primeiro. Há alguns motivos para insistir nessa ordem de trabalho:
- Com o erro original em vigor, o senhor tem um caso de teste perfeito para o bug no seu código de tratamento de erros. Depois de corrigir o problema original, como o senhor testará o tratamento de erros? Lembre-se de que um dos motivos pelos quais havia um erro em primeiro lugar é que é difícil testá-lo.
- Depois que o problema original é corrigido, a urgência de corrigir o código de tratamento de erros desaparece. O senhor pode dizer que vai fazer isso, mas qual é a pressa? O senhor será como o cara que tem um telhado com vazamento. Quando está chovendo, o senhor não pode consertá-lo porque está chovendo, e quando não está chovendo, não há vazamento!
O senhor precisa ter um local central onde todos os seus erros sejam agregados, um local que todos os desenvolvedores da sua equipe conheçam intimamente e visitem todos os dias. No Stack Overflow, usamos uma bifurcação personalizada do ELMAH.
Monitoramos esses logs de exceção diariamente, às vezes de hora em hora. Nossos logs de exceção são uma lista de tarefas de fato para nossa equipe. E por um bom motivo. A Microsoft vem coletando tipos semelhantes de registros de falhas há anos, tanto para si mesma quanto para outros fornecedores de software, sob a bandeira do serviço Windows Error Reporting. O dados resultantes são convincentes:
Quando um usuário final sofre uma falha, é exibida uma caixa de diálogo que pergunta se ele deseja enviar um relatório de erro. Se o usuário optar por enviar o relatório, o WER coletará informações sobre o aplicativo e o módulo envolvidos na falha e as enviará por meio de um servidor seguro para a Microsoft.
O fornecedor mapeado de um bucket pode então acessar os dados de seus produtos, analisá-los para localizar a origem do problema e fornecer soluções por meio das caixas de diálogo de erro do usuário final e fornecendo arquivos atualizados no Windows Update.
A análise de tendências de base ampla dos dados de relatórios de erros mostra que 80% dos problemas dos clientes podem ser resolvidos com a correção de 20% dos principais bugs relatados. Até mesmo a correção de 1% dos principais bugs resolveria 50% dos problemas dos clientes. Os mesmos resultados de análise também são geralmente verdadeiros em uma base de empresa por empresa.
Embora Eu continue sendo um fã do desenvolvimento orientado a testesO senhor sabe que a natureza especulativa do investimento de tempo é um problema que sempre tive com ele. Se o senhor corrigir um bug que nenhum usuário real jamais encontrará, o que o senhor realmente fez? o senhor consertou? Embora existam muitos outros motivos válidos para praticar o TDDcomo um mecanismo puro de correção de bugs, ele sempre me pareceu uma otimização prematura demais para o meu gosto. Prefiro muito mais gastar meu tempo corrigindo bugs que são problemas no prática em vez de teoria.
O senhor certamente pode fazer as duas coisas. Mas se o tempo do desenvolvedor for limitado, prefiro alocá-lo para corrigir os problemas que os usuários reais estão tendo com meu software, com base em dados concretos e frios. Isso é o que chamo de Desenvolvimento orientado por exceções. Envie seu software, coloque o maior número possível de usuários na frente dele e estude atentamente os logs de erros que eles geram. Use esses logs de exceções para se concentrar nas áreas problemáticas do seu código. Rearquitete e refatore seu código para que os três principais erros não ocorram mais. Iterar rapidamente, implemente e repita o processo. Esse ciclo de feedback orientado por dados é tão poderoso que o senhor terá (pelo menos da perspectiva dos usuários) um aplicativo estável como uma rocha em poucas iterações.
Os registros de exceções são possivelmente a forma mais poderosa de feedback que seus clientes podem lhe dar. É um feedback baseado em software de remessa que o senhor não precisa pedir ou persuadir os usuários a lhe darem. O senhor também não precisa interpretar as divagações estranhas e semi-coerentes dos usuários sobre quais são os problemas. Os problemas reais, com stack traces e dumps, são coletados para o senhor, de forma automática e silenciosa. Os logs de exceção são a última palavra em feedback do cliente.
Estou defendendo o envio de código com bugs? Código incompleto? Código ruim? É claro que não. Estou dizendo que quanto mais cedo o código sair do editor e for apresentado a usuários reais, mais dados o senhor terá para melhorar seu software. Os registros de exceções são uma grande parte disso, assim como os dados de uso. E o senhor também deve conversar com seus usuários. Se o senhor for capaz de fazê-lo.
Seu software será fornecido com bugs de qualquer maneira. O software de todo mundo tem. O software real trava. O software real perde dados. O software real é difícil de aprender e difícil de usar. A questão não é a quantidade de bugs que o senhor vai enviar, mas com que rapidez o senhor pode corrigir esses bugs? Se a sua equipe tem praticado o desenvolvimento orientado por exceções o tempo todo, a resposta é: podemos melhorar nosso software em pouco tempo! Basta o senhor nos ver melhorando-o!
E isso é música doce, doce para os ouvidos de todos os usuários.