Observei esta anotação em meu journal de muitos anos atrás (2009) e ela continua atual. Baseado em um powerpoint do cientista da computação Andreas Zeller, autor de Why Programs Fail, este acrônimo é um caminho fácil de lembrar quando precisamos encontrar um bug no sistema. Eu lembro que estava pensando até em escrever um artigo na época, mas ainda estava trabalhando a questão de como traduzir as siglas para o português.
A boa notícia é que hoje, 14 anos depois da reforma ortográfica da língua portuguesa, eu posso dizer que não me importo mais para a tradução: Developer: you need to know English!.
Este é um item importantíssimo: prove que exista. A primeira coisa que você precisa antes de corrigir um bug é saber que ele existe. Se não for possível detectá-lo, se ninguém consegue mostrar algo que não funcionou como deveria, ele não existe. Assunto encerrado.
Depois que o pessoal de suporte conseguiu provar que o problema existe, quer dizer que você, programador, vai ter que trabalhar. Ninguém mandou ficar gerando bugs a torto e a direito ou ir trabalhar em um vespeiro.
E já que o problema existe e você vai ter que corrigi-lo, a primeira coisa que deve ser feita é reproduzir a falha encontrada. Sem conseguir reproduzir de novo, além de você não entender o que o usuário quer que você faça, mais importante é que você não saberá quando o problema foi corrigido.
Se você está nesse passo ótimo, quer dizer que consegue, pelo menos algumas vezes, reproduzir o problema. E nesse caso a próxima tarefa é automatizar a reprodução deste bug, em caminhos simples e bem definidos, por favor.
E quando eu digo automatizar não quero que você faça um programa que faça o bug aparecer. Basta uma lista com um passo a passo em que o comportamento que não deveria estar no sistema consegue ser gerado.
Se houver muitos passos fica difícil entender onde está o problema, e é por isso que nesta tarefa além de automação está o item simplificar. Um estudo sobre o princípio da Navalha de Ockham deve ajudar.
Agora que você tem o sisteminha com o bug reproduzidinho e tudo bonitinho... que tal encontrar este maledeto? Não é tão simples quanto falar (tente explicar isso para seu gerente), mas é possível. Sempre é possível.
Tente encontrar nos itens relacionados com a reprodução do problema os possíveis caminhos onde pode estar a falha. Assim como super-heróis, todo bug tem uma origem. Esta tarefa 4 diz sobre encontrar esta origem. Bug Begins.
Como você deve ter passado um bom tempo no item 4 é hora de entender que não dá para analisar o sistema inteiro toda vez que um bug aparece. Não dá para dedicar alguns meses para ler o código e a documentação, fazer cursos na Udemy e só então voltar para o bug.
Voltando à analogia de super-herói, imagine que seu bug se parece com uma aranha. Se você estiver dedicando muito tempo em um formigueiro é capaz que você esteja no caminho errado. Não, esta não é uma busca por todo o reino animal. Comece pelo mais óbvio até ele deixar de ser óbvio. Então encontre o próximo candidato óbvio. Isso é focar.
Isolar a infecção significa remontar aquela listinha de passos para reprodução de forma que o bug aconteça em um ambiente controlado. Sempre que eu rodo este programinha baseado no código de produção ele dá o resultado errado para a situação que encontramos em produção.
Ao isolar a cadeia de eventos nós estamos verdadeiramente aprendendo como o sistema funciona. Não todo o sistema, mas os itens de uma cadeia responsável pelo surgimento de um bug. E isso não se esquece. Quanto mais complexo o bug, mais aprenderemos.
Essa é a parte fácil. O bug já está isolado, pode ser reproduzido quantas vezes precisar e isso pode ser usado até como teste após a correção. Só falta os 10% de mexer no código.
Claro que pode se tratar de um bug conceitual, de arquitetura, o que vai exigir bem mais que 10%. Mas a correção de um bug em si pode ser resolvido com quantas gambiarras for necessário se há urgência. E isso quer dizer alguns minutos batendo código. Na próxima reunião de grooming vocês programadores decidem a melhor maneira de resolver isso no futuro distante e ideal que nunca irá acontecer.
Obrigado, e até o próximo bug.