Sobre bugs

Os meros mortais acham que o trabalho de um desenvolvedor é puro glamour (assim como eles também acham que adoramos consertar suas impressoras ou wifis). O que pouca gente sabe é que nossa profissão pode ser bem estressante.

Neste texto vou tentar dar algumas dicas que refletem a minha própria experiência de como lidar melhor com bugs e como tentar controlá-los.

Planejamento

Without requirements or design, programming is the art of adding bugs to an empty text file.

— Louis Srygley

Na maioria das vezes a origem dos bugs está no planejamento, seja ele técnico ou de produto. Existem dois tipos de planejamento: pré-bug e pós-bug. O pré-bug é o clássico “precisamos disso para ontem”.

Sempre que você precisa virar a noite ou mudar toda uma implementação de uma hora para outra, é grande a chance de você também introduzir novos bugs na sua aplicação - sob pressão dificilmente você vai produzir o seu melhor: você vai ficar irritado; vai fazer as coisas de qualquer jeito só pra alcançar o seu objetivo; o sono vai chegar uma hora ou outra. Nada de bom pode sair disso.

O pós-bug é quando um bug é identificado em produção. Existem dois caminhos a serem seguidos: analisar com calma e aplicar a solução ideal ou tentar achar uma solução o mais rápido possível, seja ela qual for.

O designer Pete Lacey resumiu bem o impacto de um planejamento pós-bug:

Mesmo que os dois tipos de correções durem o mesmo tempo e entreguem o mesmo resultado, o primeiro é muito mais estressante para todos os envolvidos.

Tenha sempre um plano B

Na maioria dos casos é possível temporariamente tirar o sistema do ar, ou fazer um rollback. É muito melhor ter usuários reclamando por downtime do que por uma falha crítica no sistema.

Tanto o rollback como uma página de manutenção no ar vão, é claro, abalar a moral do time, no entanto vão dar tempo para achar a solução mais próxima da ideal, identificar a causa raiz do problema; dar tempo para suporte e qualquer tipo de comunicação externa.

Mas atenção: esteja certo de que seu rollback vai funcionar. Teste seus backups. Planeje os seus releases para que eles não introduzam mudanças irreversíveis (como migrações de banco, features que não têm compatibilidade com versões anteriores ou com outros serviços do seu sistema etc.).

Não ignore os sinais

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

— anonymous

Quem aí nunca disse: “Ah aconteceu isso mas foi porque eu tava com base antiga”; ou o famoso “funciona na minha máquina”; ou “deve ter sido algum problema temporário no backend”. Quando se trata de bugs nós somos bastante otimistas e sempre achamos que a culpa é de algum fator externo.

Evite ficar na defensiva. Isso foi algo que aprendi depois de causar muitos estragos em produção, mas hoje em dia eu não ignoro nenhum sinal desses. Sempre que há um erro, seja ele em um ambiente de desenvolvimento ou staging, procure investigar até ter uma resposta satisfatória do que aconteceu.

O mesmo vale para quando alguém fala “Tentei isso ontem e deu um problema, mas hoje estava funcionando”. 99% dos erros não vão ser reportados — os usuários são muito mais espertos do que a gente acha e vão achar “workarounds” extremamente criativos para burlar os nossos bugs. Pare com essa falácia de que todo usuário é idiota e preste muita atenção em tudo o que eles dizem.

Como enxergamos os usuários dos nossos sistemas

QA

Each new user of a new system uncovers a new class of bugs.

— Brian W. Kernighan

Uma parte importante de evitar bugs é ter um processo claro e eficiente de QA (quality assurance - ou garantia de qualidade). É comum os testes de QA serem executados apenas do ponto de vista de segurança ou técnico: XSS, strings estranhas, strings longas etc. E acabamos esquecendo que precisamos garantir que o sistema funcione também para os nossos usuários.

Teste sempre com dados reais, não só com lorem ipsum. Coloque-se no lugar do usuário e teste todos os caminhos sob o ponto de vista dele.

Monitoramento e controle

The longer it takes for a bug to surface, the harder it is to find.

— Roedy Green

Ferramentas como Rollbar e Sentry, por exemplo, são ótimas para monitorar e identificar bugs que não são reportados por usuários. Elas também vão identificar casos extremos (edge cases) que passaram despercebidos nos testes automatizados e QA. Hoje em dia eu não imagino construir um sistema sem algum tipo de monitoramento e relatório de erros. Em muitos casos, você pode até mesmo ver um histórico das ações do usuário, facilitando muito na hora de identificar e aplicar uma correção.

Outro fator importante é fazer uma boa triagem e manter o número de bugs sob controle. Não existe um número mágico, mas nunca vi projetos com mais de 50 bugs abertos voltarem a um estado “saudável”. O que acontece é aquela famosa maratona onde todos os desenvolvedores se unem para corrigir esses bugs, mas quase sempre a maior parte to tempo é usada para consertar 1 ou 2 bugs.

Também é necessário ter algum tipo de categorização para os seus bugs - e essa categorização precisa estar nas mãos do time de desenvolvimento. Eu sempre prefiro o básico prioridade baixa, média e alta, onde: alta significa que precisamos parar tudo e corrigir o bug; média, o bug precisa ser corrigido na mesma semana; e baixa em no máximo um mês. Você pode tentar ter mais níveis de prioridade, mas evite um sistema muito complexo onde os bugs realmente importantes vão acabar se perdendo.

E, claro, não aceite feature request como bug. :)

Transparência

It’s not a bug — it’s an undocumented feature.

— anonymous

Mais uma vez, quem nunca escondeu um bug do resto do time/empresa? Há algum tempo descobri que isso é uma prática muito ruim e, se você tem medo de dizer que criou um bug, o ambiente que você trabalha não é dos melhores.

Sempre que descobrir qualquer bug, mesmo (e principalmente) se for um filho teu, crie uma issue pra todo mundo ficar sabendo. Nada de correções ninja. Avise quem precise ser avisado (suporte, gestores etc.). Converse com os outros desenvolvedores. Resumindo, seja profissional.

Vai ser difícil no início, mas depois você vai perceber que é muito melhor tratar bugs como mais uma tarefa e aceitar que eles vão acontecer sempre, não há escapatória.

Em alguns casos também é importante comunicar externamente, seja para seus usuários, ou para o seu cliente. Minha regra é: internamente seja sempre transparente e avalie a necessidade de uma comunicação externa com todas as pessoas responsáveis pelo projeto.

Post-mortem

The trick is to fix the problem you have, rather than the problem you want.

— Bram Cohen

É claro que você não precisa avaliar a revisar todo e qualquer bug encontrado. Mas, no caso de bugs críticos, é fundamental que os profissionais envolvidos façam um post-mortem.

Não é para achar culpados. É para estabelecer ações e evitar que este tipo de falha aconteça no futuro. É comum, por exemplo, escrever testes específicos para a falha encontrada. Ou então corrigir alguma etapa do processo de desenvolvimento, adicionar uma nova monitoração, melhorar o processo de code review.

E o mais importante: deixar claro para o “responsável” pelo bug que não foi culpa dele e que ele é parte de um time que vai sempre tentar melhorar seus processos.

O mundo não vai acabar

If McDonald’s were run like a software company, one out of every hundred Big Macs would give you food poisoning, and the response would be, “We’re sorry, here is a coupon for two more.”

— Mark Minasi

Em um mundo dominado por software, cadas vez mais bugs vão fazer parte da nossa vida. Crypto currency, “smart” cars e por aí vai.

Quando me deparo com um bug em produção sempre gosto de pensar que não é o fim do mundo e ser grato por não trabalhar em softwares onde bugs podem causar a morte de outros seres humanos.

Se esse também é o seu caso, passados alguns meses ninguém mais vai lembrar do seu bug, ou ele vai até mesmo virar motivo de piada. E depois de tudo resolvido você vai tomar ações e aprender lições que vão te ajudar na sequência da sua carreira.

É da nossa natureza exagerar nas coisas ruins e menosprezar as coisas boas. Tenho certeza que para cada bug que você encontra em produção, inúmeras outras features bacanas foram lançadas. Nunca se esqueça disso.

Happy coding!