Qual é o benefício de evitar o uso de um depurador?

O que parece ser uma adivinhação do lado de fora, muitas vezes acaba por ser o que eu chamo de "depuração em sua mente". De certa forma, isso é semelhante à habilidade dos grandes mestres de jogar xadrez sem olhar para um tabuleiro de xadrez.

É de longe a técnica de depuração mais eficiente que eu conheço, porque não requer um depurador. Seu cérebro explora vários caminhos de código ao mesmo tempo, gerando um melhor retorno do que você poderia obter com um depurador.

Eu não estava consciente sobre essa técnica antes de entrar brevemente no mundo da programação competitiva , onde usar um depurador significava perder preciosos segundos. Após cerca de um ano de competições, comecei a usar essa técnica quase exclusivamente como minha linha inicial de defesa, seguida de depuração de log, com o uso de um depurador real localizado no distante terceiro lugar. Um efeito colateral útil desta prática foi que eu comecei a adicionar novos bugs em um ritmo mais lento, porque "depuração em minha mente" não parou quando eu escrevi um novo código.

É claro que este método tem suas limitações, principalmente devido às limitações da mente de visualizar múltiplos caminhos através do código. Aprendi a respeitar essas limitações da minha mente, recorrendo a um depurador para corrigir bugs em algoritmos mais avançados.

Quanto mais eu conheço uma base de código, menos eu preciso de um depurador (mas eu ainda verifico o erro relatado, é uma pista importante em qualquer raciocínio).

É uma excelente ferramenta para entender alguns comportamentos dinâmicos de pequena a média complexidade, mas muitas vezes descubro que me concentro nos detalhes em vez de no quadro geral. E depois de um tempo, é aí que estão os problemas: em interações de escopo mais amplo, cujo comportamento dinâmico tende a ser mais facilmente compreensível com outras ferramentas (registro de entrada e saída em limites de módulo, por exemplo).

Eles podem não ser maus programadores, mas provavelmente são solucionadores de problemas extremamente ineficientes.

Eu costumo seguir o conselho de Depuração: as 9 regras indispensáveis para encontrar até mesmo os problemas de software e hardware mais difíceis (David Agans), e este cai diretamente sob a orientação de "Pare de pensar e olhar"

Qualquer trabalho requer o uso das ferramentas certas da maneira correta. Se você tiver um depurador, use-o para ver o que realmente está acontecendo. A maioria dos erros são causados por suposições.

Eu trabalhei com desenvolvedores que se recusam a usar depuradores porque eles sabiam melhor. A resposta clássica que recebi uma vez foi "o acidente não está sendo causado por mim, passei o dia inteiro inspecionando o código [onde estava falhando] e não há nada de errado". (Que tal valor nulo que foi lido do banco de dados?) O chefe parecia pensar que era uma ótima resposta, mas o cliente não.

Eu saí desse time o mais rápido que pude. O objetivo deles era empinar o trabalho e transformar um problema simples de 10 minutos em um problema de longo prazo.

Seu melhor guia para a prática de depuração é o livro de Steve McConnel Code Complete . O Capítulo 23 aborda a depuração em detalhes, e vou destilar alguns pontos dela.

1. Entender o problema é importante, e o uso do depurador não é um substituto para ele.
2. Adivinhar é uma má abordagem para a depuração. Se seus colegas estão realmente usando adivinhação, ao invés de pensar sobre o problema, então eles estão fazendo um trabalho ruim. Adivinhação significa colar instruções de impressão aleatória no código e esperar encontrar algo útil.
3. Se seus colegas realmente não sabem como usar um depurador (em vez de optar por não usar um), então sim, eles são incompetentes, assim como alguém que não conhece a sintaxe da linguagem que eles deveriam ser usando.

Difícil dizer. A depuração por adivinhação pode funcionar se você já tiver uma idéia sobre o que é o bug (valor incorreto passado a uma função de biblioteca, possivelmente SQL inválida, etc.). Admito que faço isso algumas vezes quando o erro em si parece pequeno ou óbvio, como "buffer de caractere muito pequeno" - o rastreamento de pilha mostra a falha da linha e não preciso de um depurador para resolver esse problema.

Fazer isso o tempo todo pode ser contraproducente e se os primeiros "palpites" falharem, adivinhar é provavelmente a estratégia errada de solução de problemas e um depurador real deve ser chamado. Normalmente, eu d dizer que não há absolutamente nada de errado em usar o depurador.

Estou surpreso que a discussão sobre este tópico não tenha mencionado "teste unitário".

Como faço desenvolvimento orientado a testes, não gasto muito tempo no depurador. 10 anos atrás, eu costumava percorrer diligentemente o depurador:

1. Depois de escrever um trecho de código para garantir que funcionou e
2. Quando recebi um relatório de bug para tentar diagnosticar o problema

O que eu descobri depois de 10 anos de desenvolvimento orientado a testes é que sou muito mais produtivo como programador se:

1. escrevo testes de unidade antes escrevo o código para garantir que o escrevi corretamente
2. Eu escrevo testes de unidade imediatamente ao receber um relatório de bug para tentar duplicar e detalhar o problema.

Permitir que o computador execute o código e valide o resultado é milhares de vezes mais rápido do que eu posso pensar ou percorrer o código para validar mentalmente os resultados e não cometer erros.

Eu ainda tenho que percorrer o depurador ocasionalmente, e ainda estou envolvido em analisar mentalmente o código ... mas apenas raramente, e principalmente por um código muito complicado.

Pessoalmente, tento minimizar o uso de um depurador por:

• usando verificadores estáticos e opções semelhantes de compilador que sugerem possíveis fontes de erros apenas analisando o código
• escrevendo código com poucos efeitos colaterais possíveis, no estilo mais funcional possível, eliminando o estado mutável sempre que possível
• escrevendo testes de unidade com a granularidade mínima razoável
• sem engolir exceções

Naturalmente, todos cometem erros, por isso, mesmo ao compor programas dessa maneira, se um teste falhar, eu uso o depurador para inspecionar o valor de uma expressão intermediária. Mas, ao aderir aos princípios acima, o defeito é mais fácil de localizar e a depuração não significa um processo doloroso e indeterminado.

Use o depurador sempre que possível. O depurador irá simplesmente pregar a questão (ah, olhe, nós não verificamos esse valor), ou forneceremos uma grande quantidade de contexto que é útil ao analisar o código relevante (wow, a pilha está totalmente desarrumada, eu vou seja um problema de estouro de buffer).

A depuração é uma ferramenta muito útil para inspecionar o estado dos objetos e variáveis em seu código em tempo de execução.

Como mencionado anteriormente nas respostas acima, a depuração é extremamente útil, mas há alguns casos em que ela é limitada.

Na minha experiência, acho que usar o depurador é muito útil porque ajuda a revelar suposições falsas que eu estava fazendo sobre o estado do meu código. Algumas pessoas não são tão astutas ao ler o código para encontrar um bug, então a depuração pode ajudar a revelar falsas suposições que você ou outro desenvolvedor fez sobre o estado do código.

Talvez você espere que um parâmetro nunca seja nulo quando passado para um método, portanto, você nunca verifica esse caso e continua no método como se esse parâmetro nunca fosse nulo. A realidade é que o parâmetro irá acabar sendo nulo em algum ponto, mesmo se você definir como pré-condição para o método que o parâmetro nunca deve ser nulo. Isso sempre vai acontecer.

Em contraste com a utilidade dos depuradores nos exemplos acima mencionados, acho difícil e de alguma forma não é útil usar quando multi-threading (isto é, simultaneidade, processamento assíncrono) está envolvido. Isso pode ajudar, mas é fácil perder a orientação no nevoeiro multiencadeado quando os pontos de interrupção do depurador estão sendo atingidos em um encadeamento no ponto A e um encadeamento completamente separado no ponto B. O desenvolvedor é forçado a empurrar o novo ponto de interrupção " processo de pensamento "no topo da" pilha "de seu cérebro e orientar-se para o código no ponto do novo ponto de interrupção. Depois que a relevância do ponto de interrupção B diminui, o desenvolvedor volta para o primeiro ponto de interrupção e precisa lembrar o que estava procurando antes do gatilho do ponto de interrupção B. Eu sei que isso pode ser uma explicação confusa, mas meu ponto de vista neste parágrafo é que a depuração onde a simultaneidade é usada pode ser muito ADD (Transtorno de Déficit de Atenção), e por isso pode ser mais difícil permanecer produtivo em seu padrão de pensamento de depuração.

Além disso, a imprevisibilidade do código concorrente pode distrair ainda mais o desenvolvedor na depuração de código simultâneo.

Em conclusão, na minha sincera opinião:

• Depuração quando a simultaneidade é usada = maior tendência a perder o foco do "padrão de pensamento de depuração"

e

• a qualquer momento = maior produtividade de depuração b / c sua atenção não é interrompida por pontos de interrupção inesperados (inesperados devido a condições de corrida).

Eu acho que eles estão sendo um pouco hardcore. Pessoalmente, quando me deparo com um bug, eu reconheço o código, tento localizá-lo em minha mente a partir da lógica do programa, porque isso às vezes me ajuda a descobrir outros problemas ou efeitos colaterais mais fáceis do que usar o debbuger e corrigir o bug onde ele se manifesta .

Mesmo quando acho que já acertei, costumo depurar para ter certeza de que estou certo. Quando o problema é um pouco mais complexo, acredito que a depuração é absolutamente essencial.

Também ... apenas a minha opinião, mas não há desculpa para não tirar uma vantagem decente das ferramentas que um IDE moderno pode trazer para a mesa. Se isso ajudar você a concluir seu trabalho mais rapidamente e de maneira mais confiável, você deve usá-lo.

Odeio generalizar, mas muitos programadores que conheci acham que existe apenas uma maneira de resolver um problema (do jeito deles). É fácil supor que todos os testes possíveis foram pensados. Uma perspectiva diferente pode ser muito valiosa.

A programação por tentativa e erro pode resultar em novas e ótimas abordagens, além de detectar coisas que outras pessoas não perceberam.

A desvantagem normalmente demora muito mais tempo.

É, depende da pessoa. Pessoalmente, eu não uso depuradores tanto assim. Quando eu programo micro controladores, eu basicamente uso LEDs ou gravando dados em EEPROMs para "depurar" o código nele. Eu não uso o JTAG.

Quando eu programo software para PCs ou servidores, costumo usar log e muita saída do console. Para linguagens no estilo C, eu uso diretivas de pré-processador e, em Java, usei níveis de log.

Como eu não uso depuradores, você diria que estou fazendo algo errado? São os trabalhos dos editores, para mostrar onde eu tenho erros sintáticos, e quando há um erro lógico, eu só tenho que executar testes.

Existe uma diferença entre não precisar usar um depurador e não saber como (ou se recusar) usar um depurador. O depurador é apenas uma das muitas ferramentas para usar no rastreamento e correção de bugs. Eu trabalhei com desenvolvedores que podem resolver em sua cabeça e outros que pensam que podem.

A melhor mistura é escrever seu código para que seja fácil de testar por meio de testes unitários e registre os erros. Então você espera que não precise examinar os logs ou usar o depurador. É como comprar seguro. Espero que você nunca precise usá-lo, mas depois de encontrar um bug que não pode ser resolvido marcando novamente o código, é tarde demais para adicionar manipulação / registro de erros, testes de unidade ou aprender a usar um depurador.

Diferentes ferramentas / plataformas favorecem diferentes técnicas de depuração (depurador, registro, testes de unidade, etc.) Desde que os desenvolvedores estejam familiarizados com algumas das técnicas para sua plataforma / ferramenta, além de apenas verificar novamente o código, então eles podem ser um desenvolvedor habilidoso, mas se eles tiverem apenas um truque quando se trata de depuração, eles acabarão encontrando um bug que não poderão ser encontrados ou consertados.

Muitas respostas, mas não uma menção sobre Heisenbug ?!?!

Heisenbugs occur because common attempts to debug a program, such as inserting output statements or running it in a debugger, usually modify the code, change the memory addresses of variables and the timing of its execution.

Eu uso depurador, apenas no pior dos casos (para erros difíceis de encontrar). Além disso, de acordo com as práticas recomendadas que muitos desenvolvedores / testadores aclamados têm falado, é bom testar completamente o código. Dessa forma, você pode cobrir a maioria dos problemas e, portanto, não há necessidade de usar o depurador.

Eu li um argumento contra a depuração do depurador aqui recentemente (ou foi StackOverflow?). Você deve ter casos de teste em relação ao seu código. Se seus testes passarem, sua depuração provavelmente não vai exercitar o bug (suposição: você irá depurar com dados semelhantes aos dados de teste).

Por outro lado, o registro é obrigatório. Se você passar seus testes e implantar para produção, poderá descobrir que tem um bug. A evidência do bug é de algo que aconteceu no passado. ou seja, alguém diz: "Como isso chegou lá?" Se você não tiver bons registros, nunca encontrará a causa. Mesmo um depurador pode não ser útil nesse ponto, porque você não sabe como os dados se pareciam com o bug. Você precisa ser capaz de depurar o aplicativo dos logs.

Infelizmente, estou parafraseando um pouco, e posso estar fazendo um desserviço ao argumento original. Em particular, a posição de "Existem importantes auxiliares de depuração para gastar o tempo de desenvolvimento em suporte" pode ser ortogonal à importância dos depuradores. Mas a parte sobre a dificuldade em definir o estado do sistema em uma configuração que torna a depuração útil para encontrar bugs me pareceu algo em que pensar.

Com bons testes de unidade e exceções que fornecem o backtrace, você raramente precisa usar um depurador.

A última vez que usei uma depuração foi quando obtive um arquivo principal em algum aplicativo legado.

Am I being a "debbuger minion" or are these guys being "too hardcore"?

Nem Eles são apenas pessoas que gostam de tornar sua vida mais difícil do que deveria ser.

A depuração é apenas uma ferramenta que um bom desenvolvedor deve usar proficientemente.

Certamente, às vezes, você pode saber de cor onde o bug pode estar se você souber a base do código. Mas você também pode perder um dia ou uma semana inteira para encontrar um bug incômodo apenas olhando para o código.

Em linguagens tipificadas dinamicamente sem algum tipo de depuração (mesmo que seja apenas descarregando valores para o console), adivinhar às vezes torna-se impossível.

Então, para responder à sua pergunta - talvez eles sejam programadores brilhantes, mas suas habilidades de resolução de problemas e sua proficiência quando caçam bugs são ruins.

Depende do escopo de um problema. Se o programa é pequeno e as coisas estão bem divididas, você provavelmente pode descobrir olhando. Se o programa é de 4,5 milhões de linhas de código desenvolvido por uma equipe de mais de 100 pessoas ao longo de vários anos, então certos bugs serão impossíveis de detectar.

O que estava em questão no programa (em C) era uma sobregravação de memória. O depurador com um ponto de interrupção de memória identificou a linha de código ofensiva assim que o erro apareceu. Mas neste caso, não há como alguém ter lido e retido todas as 4.5 milhões de linhas de código para identificar o ponto em que alguém escreveu além de seu array (além disso, eles teriam que saber o layout da memória para o gigantesco estado do programa). cerca de 10 minutos em um longo período de entradas para chegar a esse ponto).

Os pontos são: Em pequenos programas ou coisas altamente modularizadas, você pode se livrar de um depurador. Se o programa é realmente grande e complexo, o depurador pode economizar muito tempo. Como outros já disseram, é uma ferramenta, e tem suas situações em que se sobressai acima de qualquer outro método, e outras onde não é a melhor escolha.

Se o erro ocorrer no computador de um cliente, ou em um computador em que seu ambiente é muito diferente do seu, a configuração de um depurador / depurador remoto será incômoda. Então, para o dia frio em que você recebe um bug do campo, a resposta de "mas ... eu não tenho um depurador" não ajuda. Portanto, você precisa desenvolver um conjunto de habilidades para solucionar problemas e encontrar o bug apenas por meio da compreensão de arquivos de código e de registro.

Que bobagem: "Programadores Reais não precisam de Depuradores". Pode-se dizer também que um programador real não precisa de nenhuma IDE, apenas me dê um bloco de anotações e um lápis sem brilho. O depurador é uma ferramenta como qualquer outra que ajuda na produtividade.

Além disso, considere que nem todos os responsáveis pela depuração de código estão familiarizados com esse código em questão. Muitos contratados do tempo entram em um ambiente onde eles têm apenas um ideal geral que está acontecendo. Eles podem até receber uma descrição detalhada de um ambiente - ou um mapa de esquema de 20 anos e guia para convenções de nomenclatura arcanas (tente entender a diferença entre a tabela X1234 e a tabela X4312 com os campos F1, F2 e F3 [sim, lixo como este existe] quando você é novo), mas muitas vezes essa descrição está errada; caso contrário, por que há um erro de "mistério"?

Como alguém novo em um ambiente, você pode passar horas ou dias mapeando e "conhecer" um grande banco de dados para uma área problemática que pode corrigir e, depois, nunca mais precisar examinar novamente. Este é um enorme desperdício de tempo e dinheiro. Se você tiver acesso ao depurador, verá o que está acontecendo, corrigirá e desaparecerá em questão de minutos. Tudo isso "você não precisa depuradores" hooey é apenas exagero elitista.