Ser um desenvolvedor significa que mais da metade do tempo você tem que ser um depurador, às vezes para o seu próprio código, e outras vezes para ajudar seus colegas na revisão do código ou no caso de programação em par. Apesar de ser uma habilidade necessária para desenvolvedores, a depuração não é algo que seja ensinado a ninguém em nenhum momento de suas carreiras, o que leva a crer que é muito difícil. A depuração parece difícil, não por causa da mecânica, mas porque é difícil entender por onde começar como novato. Sem dúvida, é uma arte que pode ser adquirida criando e revisando cada vez mais código ao longo do tempo, mas a intuição pode ser desenvolvida desde o início com algumas recomendações que discutiremos hoje neste artigo. Vamos começar. Reproduzindo o problema O pior cenário durante a depuração de qualquer problema é quando o bug não pode ser reproduzido de forma confiável. Isso pode acontecer devido a vários fatores, como condições de corrida, sistemas externos ou problemas ambientais que levam a diferentes padrões de comportamento em sistemas implantados ou caixas de estágio de desenvolvedor. Isso se resume tanto ao testador quanto ao desenvolvedor, quanto mais específico você puder ser na maneira de reproduzir o bug, melhor. Além disso, depois de encontrar o problema e uma maneira de demonstrá-lo, certifique-se de colocar todos os detalhes sobre como reproduzi-lo, bem como entendê-lo e resolvê-lo, em um sistema de rastreamento de bugs. Isso não apenas ajudará você a verificar a correção depois de implementada, mas também ajudará os outros desenvolvedores a entender a causa e a solução do bug. Aqui estão algumas dicas simples a seguir ao descrever as etapas para reproduzir um problema: Tente ser específico, pois quanto mais probabilidades você mencionar, mais caminhos de investigação serão abertos. Caso uma entrada seja necessária, sempre inclua algum exemplo ou valores de amostra. Além disso, mencione as restrições ou regras especificadas para a entrada do usuário porque isso pode ser uma causa provável do problema, que vale a pena verificar. Sempre especifique os detalhes do ambiente - sistema operacional, tipo de navegador e versão do navegador. Isso pode ser particularmente o caso de aplicativos da Web em que diferentes navegadores podem representar diferentes comportamentos. Inclua relatórios de falhas relevantes, logs, capturas de tela anotadas, etc., para explicar adequadamente a diferença entre como você espera que o aplicativo se comporte e como ele realmente se comporta, sem deixar chances de mal-entendido para o depurador. Converter o problema em um teste automatizado Esta etapa nem sempre é possível; e às vezes é possível, mas não prático ou realmente necessário; no entanto, pode haver casos em que vale a pena implementá-lo. O teste automatizado, neste contexto, pode ser qualquer coisa que seu caso de uso de desenvolvimento já esteja utilizando para teste, como teste de unidade ou teste de integração. Sempre que possível, os testes de unidade são uma excelente escolha porque são projetados para serem executados com frequência, assim você saberá se o problema retornará em breve. Você pode se pegar escrevendo muitos testes de unidade que passariam ao tentar identificar a origem do problema. Ocasionalmente, você também pode se pegar escrevendo testes de unidade que não fazem sentido fora da situação atual, mas, mesmo assim, não há problema em ter um teste que possa ajudá-lo a apontar a origem do problema. Só porque não é o problema atual, não significa que não encontrará um mais tarde - e também serve como mais documentação de como o código deve se comportar. Os testes de unidade de trabalho são frequentemente uma excelente abordagem para determinar qual camada dentro de um sistema está gerando o problema. Refatore seus testes de unidade com o mesmo vigor que faria com seu código de produção. Se você tiver um grande teste de unidade que está realmente testando uma parte significativa do código, tente dividi-lo em testes menores. Se você tiver sorte, descobrirá que um grande teste de unidade com falha baseado no problema original pode ser dividido em vários testes de aprovação e um único teste de falha menor. Mesmo se você encontrar um problema no início e puder resolvê-lo em uma única linha, crie um teste de unidade para validá-lo sempre que possível. Cometer erros ao corrigir o código é tão simples quanto desenvolvê-lo em primeiro lugar, e os princípios de testar primeiro ainda se aplicam. Não espere que as coisas funcionem como deveriam Você tem que ser um pouco paranóico se estiver depurando qualquer problema para se manter tão claro que algo em algum lugar não está funcionando como deveria, caso contrário, não haverá nenhum problema. Você precisa ter a mente aberta sobre onde pode estar o problema e navegar com seu conhecimento do sistema envolvido. O principal objetivo aqui é impedir que você afirme: "O problema não pode estar aí". Prove se você não acredita. Se parece ser, independentemente de quão impossível pareça, investigue-o mais. Seja claro sobre o propósito do código Se o objetivo de qualquer parte do código não estiver claro para você, independentemente de ser ou não a causa do problema, dedique algum tempo para entendê-lo. Você sempre pode colocar alguns testes em torno dele e tentar documentar o que ele faz. Se você não tem certeza se o comportamento é correto ou não, peça ajuda. Uma vez claro, tente documentar tudo o que você sabe, seja com um teste, documentação XML ou algum documento externo. Corrija um problema de cada vez Se um pedaço de código for excepcionalmente ruim, você pode acabar descobrindo outros problemas ao depurar o original. Nesse caso, é fundamental decidir qual problema deve ser resolvido primeiro e depois focar apenas nesse problema. Em um mundo perfeito, você resolveria um problema, verificaria seu código no controle de versão, corrigiria o próximo e assim por diante. Isso torna fácil determinar quais alterações no código levaram a quais alterações no comportamento mais tarde, o que é crítico quando uma correção para um problema acaba quebrando outra coisa. Faça seu código ajudá-lo a depurar Os logs podem ser incrivelmente úteis na depuração. Eles podem fornecer informações do local onde os depuradores podem não ser úteis. No entanto, o registro, assim como a depuração, também é uma arte cuidadosa. Se você não fizer isso corretamente, pode não ser capaz de ajudá-lo da melhor maneira possível. Portanto, sempre que uma exceção for lançada no código, faça questão de registrar não apenas a mensagem da exceção, mas também o rastreamento de pilha. As exceções nunca devem ser engolidas silenciosamente sem serem registradas. Às vezes, eles podem ser a maneira mais fácil de verificar a entrada do usuário ou as definições de configuração. Nessas situações, o registro pode ser realmente seu amigo. Da mesma forma, torne seu código resistente a entradas incorretas. Quanto mais cedo uma entrada incorreta for detectada, mais fácil será encontrar o problema. Pode ser difícil rastrear a raiz de um problema se você obtiver uma expectativa somente após um valor ter sido manipulado por vários métodos. Os contratos podem ser úteis para definir as restrições aqui, caso contrário, você deve estar atento e adicionar validações se suspeitar de um problema no futuro. Saiba mais sobre seu depurador Assim como um Jedi não pode ser ótimo sem seu sabre de luz, você não pode ser um grande desenvolvedor sem conhecer os recursos do seu depurador. Os depuradores modernos têm muitos recursos que são subutilizados porque os desenvolvedores não os conhecem. Por exemplo, pontos de interrupção condicionais ou representação definida pelo usuário de estruturas de dados podem fazer a diferença entre uma sessão de depuração que dura um dia inteiro ou uma que dura apenas 10 minutos. Você não precisa saber tudo de cor, mas uma boa ideia do que seu depurador é capaz e um bom conhecimento das teclas de atalho envolvidas para as funcionalidades básicas, como passar por cima, entrar, definir ponto de interrupção e retomar a execução são importantes . Envolva as pessoas A depuração é difícil, pois pode ser desmoralizante, e trabalhar com um labirinto de código mal documentado pode levar rapidamente à exaustão física. Considere o seguinte: se você está preso, faça uma pausa, dê um passeio, tome um café, uma barra de chocolate - o que quer que o ajude. Não fique constrangido se precisar incluir outra pessoa - se o comportamento do código parecer implausível ou se você simplesmente não souber onde procurar, pergunte. Fique de olho no que a outra pessoa está fazendo, tanto para aprender com ela quanto para avisá-la se ela parecer estar entrando em um beco sem saída que você observou anteriormente. Deixe-os saber o que você observou e o que você pensa, uma discussão pode trazer uma dica. Teste até o FIM Quando achar que resolveu o problema, faça tudo o que puder para testá-lo (dentro do razoável). Obviamente, os testes de unidade devem ser seu primeiro porto de escala - os testes de unidade que você introduziu para isolar o problema agora devem passar, mas também todos os outros testes. Um problema de alto nível é frequentemente causado por vários problemas de baixo nível - é fácil descobrir o primeiro de baixo nível, corrigi-lo e, então, assumir que o problema de alto nível desaparecerá. Às vezes, ocorre o oposto: o comportamento de alto nível se deteriora como resultado de um problema mais significativo de baixo nível. Nesse caso, você precisará continuar corrigindo e testando até ver que tudo está funcionando corretamente. Auditoria para possíveis erros Os problemas freqüentemente ocorrem em grupos. Por exemplo, se você descobrir que alguém esqueceu de fazer escape/codificação suficientes na entrada do usuário em uma instância, o mesmo problema pode surgir em outra. É significativamente mais barato executar uma auditoria rápida de possíveis problemas de uma só vez do que deixar cada questão ser levantada como um problema distinto, talvez envolvendo outros engenheiros conduzindo as mesmas investigações que você acabou de concluir. Considere as consequências do seu adesivo da mesma forma. Isso causará um problema em outro lugar que pode não ser solucionável a curto prazo? Terá um impacto na aplicação de patches ou atualizações? É um reparo significativo nesta fase do ciclo de vida do seu produto? Geralmente vale a pena descobrir o que está errado, mas ocasionalmente é mais seguro deixar o código quebrado - potencialmente com um reparo "band-aid" que aborda os sintomas, mas não a causa - e deixar a cura completa para o próximo lançamento. Isso não significa que você deva deixar o relatório de bug como está. Se você tiver uma sugestão de reparo, tente criar um arquivo de correção e adicioná-lo ao relatório de bug (deixando claro quais versões de quais arquivos precisam de correção, é claro). No mínimo, forneça uma explicação detalhada de sua pesquisa no relatório de bug para evitar perda de tempo mais tarde. Um status de bug de "Resolver próximo lançamento" (ou qualquer que seja o seu equivalente) deve indicar exatamente isso, não "É improvável que consertemos isso, mas vamos atrasar um lançamento de cada vez". Conclusão Essas recomendações não podem torná-lo um depurador profissional em um ou dois dias, mas certamente o ajudarão a começar na direção certa se forem seguidas com paciência e boa prática. Código de alta qualidade não acontece por acaso - requer paciência e precisão. Isso foi tudo para este artigo. Deixe-me saber o que você pensa sobre as dicas acima para depuração e sinta-se à vontade para adicionar sua abordagem, dicas e truques para se tornar um depurador profissional nos comentários abaixo. Continue lendo!
