Como depurar código de maneira mais eficaz? [fechado]

A mentalidade e atitude para depurar talvez seja a a parte mais importante, porque determina a eficácia com que você corrigirá o erro e o que você aprenderá com ele – se houver alguma coisa.

Clássicos sobre desenvolvimento de software como The Pragmatic Programmer e Code Complete basicamente defendem a mesma abordagem: todo erro é uma oportunidade de aprender, quase sempre sobre você mesmo (porque apenas os iniciantes culpam o compilador / computador primeiro).

Portanto, trate-o como um mistério que será interessante desvendar. E decifrar esse mistério deve ser feito sistematicamente, expressando nossas suposições (para nós mesmos ou para outros) e, em seguida, testando nossas suposições, uma por uma, se necessário – usando todas as ferramentas à nossa disposição, especialmente depuradores e frameworks de teste automatizados. Depois que o mistério for resolvido, você poderá fazer ainda melhor examinando todo o seu código em busca de erros semelhantes que possa ter cometido; e escrever um teste automatizado para garantir que o erro não aconteça inadvertidamente novamente.

Uma última observação – prefiro chamar os erros de “erros” e não de “bugs” – Dijkstra repreendeu seus colegas por usarem o último termo porque é desonesto, apoiar a ideia de que as fadas dos insetos perniciosas e inconstantes plantaram bugs em nossos programas enquanto não estávamos procurando, em vez de estarmos lá por causa de nosso próprio pensamento (desleixado): http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Poderíamos, por exemplo, começar limpando nossa linguagem não mais chamando um bug de bug, mas chamando-o de erro. É muito mais honesto porque coloca a culpa em seu devido lugar, viz. com o programador que cometeu o erro. A metáfora animista do bug que se infiltrou maliciosamente enquanto o programador não estava olhando é intelectualmente desonesta, pois disfarça que o erro é criação do próprio programador. O bom dessa simples mudança de vocabulário é que ela tem um efeito tão profundo : enquanto, antes, um programa com apenas um bug costumava ser “quase correto”, depois um programa com um erro é simplesmente “errado” (porque está errado).

Comentários

• Na verdade, gosto do termo " erro " em vez de " bug ", não porque coloca a culpa no " do programador quem cometeu o erro ", mas porque deixa claro que pode não ter sido o culpado pelo programador. Para mim, " bug " implica em erro no código; enquanto " erro r " implica em erro em algum lugar . Talvez no código, talvez na configuração do ambiente, talvez nos requisitos. Fico louco quando meu chefe tem uma " lista de bug " em que metade dos problemas são mudanças de requisitos. Chame de lista de tarefas, ferchrissakes!
• +1 para " cada erro é uma oportunidade de aprender, quase sempre sobre você (porque apenas os iniciantes culpam o compilador / computador primeiro) "
• Você conhece a história do termo " bug ", certo? Quero dizer, conforme usado no desenvolvimento de software. É claro que não ' não temos esse problema hoje, mas um bug realmente atingiu o hardware de um computador despercebido pelo programador e causou um problema.Para que ninguém pense em me corrigir, sei que Edison usou esse termo muito antes do incidente da mariposa, e é por isso que usei a palavra ' história ', não ' origem '. Consulte computerworld.com/article/2515435/app-development/… e en.wikipedia.org/wiki/Software_bug#Etymology
• @threed Claro. Mas por algum tempo, os insetos não causaram a grande maioria dos erros de software.

1. Escreva testes. O teste não é apenas ótimo para prevenir bugs (na minha experiência, o TDD feito da maneira certa elimina quase todos os bugs triviais e estúpidos), mas também ajuda muito na depuração. O teste força seu design a ser bastante modular, o que torna o isolamento e a replicação do problema muito mais fácil. Além disso, você controla o ambiente, então haverá muito menos surpresas. Além disso, depois de obter um caso de teste com falha, você pode estar razoavelmente certo de que “acertou em cheio o motivo real do comportamento que o está incomodando.

2. Aprenda a usar um depurador. As instruções print podem funcionar razoavelmente bem em algum nível, mas um depurador na maioria das vezes é muito útil (e uma vez você sabe como usá-lo, é muito mais confortável do que print afirmações).

3. Fale sobre o seu problema com alguém, mesmo que seja apenas um patinho de borracha . Forçar-se a expressar em palavras o problema no qual está trabalhando realmente faz milagres.

4. Defina um limite de tempo. Se, por exemplo, após 45 minutos você sentir que não está indo a lugar nenhum, apenas mude para outras tarefas por algum tempo. Quando você voltar ao seu bug, provavelmente será capaz de ver outras soluções possíveis que você não teria considerado antes.

Comentários

• +1 para " Forçar-se a expressar em palavras o problema no qual está trabalhando realmente faz milagres. "
• E para adicionar a (1), quase todo bug que você vê no código implica que existe ' um bug – ou pelo menos uma omissão – na suíte de teste. Corrija os dois ao mesmo tempo e não apenas prove que ' corrigiu o problema em questão, você ' está seguro contra reintroduzida.

Gosto da maioria das outras respostas, mas aqui estão algumas dicas sobre o que fazer ANTES de fazer nada disso. Irá economizar muito tempo.

1. Determine se realmente há um bug. Um bug é SEMPRE uma diferença entre o comportamento do sistema e os requisitos; o testador deve ser capaz de articular o comportamento esperado e o real. Se ele não for capaz de fornecer suporte para o comportamento esperado, não há requisitos e não há bug – apenas a opinião de alguém. Envie de volta.

2. Considere a possibilidade que o comportamento esperado está errado. Isso pode ser devido a uma interpretação incorreta do requisito. Também pode ser devido a um defeito no próprio requisito (um delta entre um requisito detalhado e um requisito comercial). Você também pode enviá-los de volta.

3. Isole o problema. Apenas a experiência vai te ensinar a maneira mais rápida de fazer isso – algumas pessoas podem quase fazer isso com seus instintos. Uma abordagem básica é variar uma coisa enquanto mantendo todas as outras coisas constantes (o problema ocorre em outros ambientes? com outros navegadores? em uma região de teste diferente? em horários diferentes do dia?) Outra abordagem é olhar para despejos de pilha ou mensagens de erro – às vezes você pode apenas dizer a propósito está formatado qual componente do sistema lançou o erro original (p.ex. se for em Alemão poderá bla me aquele terceiro com quem você trabalha em Berlim).

4. Se você restringiu a dois sistemas que colaboram, inspecione as mensagens entre os dois sistemas por meio do monitor de tráfego ou arquivos de log e determinar qual sistema está se comportando de acordo com as especificações e qual não está. Se houver mais de dois sistemas no cenário, você pode realizar verificações de pares e trabalhar para “descer” a pilha de aplicativos.

5. O motivo pelo qual isolar o problema é tão crítico é que o problema pode não ser devido a um defeito no código sobre o qual você tem controle (por exemplo, sistemas de terceiros ou o ambiente) e você deseja que essa parte assuma o controle o mais rápido possível. Isso serve tanto para poupar seu trabalho quanto para colocá-los em ação imediatamente para que a resolução possa ser alcançada no menor período de tempo possível. Você não quer trabalhar em um problema por dez dias apenas para descobrir que realmente é um problema com o serviço da web de outra pessoa.

6. Se você determinou que realmente há um defeito e ele realmente está no código que você controla, pode isolar ainda mais o problema procurando a última construção “boa” e inspecionar os logs de controle de origem em busca de alterações que possam ter causado o problema. Isso pode economizar muito tempo.

7. Se você não consegue descobrir a partir do controle de origem, agora é a hora de anexar seu depurador e percorrer o código para descobri-lo É provável que agora você tenha uma boa ideia do problema de qualquer maneira.

Assim que você souber onde está o bug e puder pensar em uma correção, aqui está uma boa procedimento para consertá-lo:

1. Escreva um teste de unidade que reproduza o problema e falhe.

2. Sem modificar o teste de unidade, faça ele passa (modificando o código do aplicativo).

3. Mantenha o teste de unidade em seu conjunto de testes para evitar / detectar regressão.

Acho que a reprodução de um bug também é importante. Todos os casos que reproduzem o bug podem ser listados e, em seguida, você pode ter certeza de que sua correção de bug cobre todos esses casos.

Há um livro excelente que li sobre este assunto chamado Por que os programas falham , que descreve várias estratégias para encontrar bugs que vão desde a aplicação de método científico para isolar e resolver um bug, para depuração delta. A outra parte interessante deste livro é que ele acaba com o termo “bug”. A abordagem de Zeller é:

(1) Um programador cria um defeito no código. (2) O defeito causa uma infecção (3) A infecção se propaga (4) A infecção causa uma falha.

Se você deseja melhorar suas habilidades de depuração, recomendo fortemente este livro.

Em minha própria experiência pessoal, encontrei muitos bugs em nosso aplicativo, mas a gestão simplesmente nos pressiona para frente para obter novos recursos. Eu “tenho ouvido com frequência” Nós mesmos encontramos esse bug e o cliente ainda não percebeu, então deixe até que eles percebam “. Acho que ser reativo em oposição a pró-ativo na correção de bugs é uma ideia muito ruim, pois quando chega a hora de realmente consertar, você tem outros problemas que precisam ser resolvidos e mais gerenciamento de recursos quer sair o mais rápido possível, então você é pego em um ciclo vicioso que pode levar a muito estresse e esgotamento e, finalmente, um sistema repleto de defeitos.

A comunicação também é outro fator quando os bugs são encontrados. Enviar um e-mail ou documentá-lo no bug tracker está tudo bem, mas em minha própria experiência, outros desenvolvedores encontram um bug semelhante e, em vez de reutilizar a solução que você colocou para consertar o código (já que eles se esqueceram disso), eles adicionam suas próprias versões, então você tem 5 soluções diferentes em seu código e ele parece mais inchado e confuso como resultado. Então, quando você corrigir um bug, certifique-se de que algumas pessoas revisem a correção e forneçam feedback caso tenham corrigido algo semelhante e encontrou uma boa estratégia para lidar com isso.

Limist mencionou o livro,