Programadores reais usam depuradores? [fechadas]

Se programadores experientes realmente usam depuradores, e se sim, em que circunstâncias. Embora na resposta a essa pergunta eu tenha dito "meses" atrás, eu provavelmente quis dizer "anos" - eu realmente não uso um depurador. Portanto, minha pergunta específica é em que circunstâncias você, como programador experiente, usaria um depurador?

Eu diria que não usar um depurador é um sinal de inexperiência. Percorrer o código linha por linha é a melhor maneira de rastrear o fluxo de execução.

Eu uso o depurador frequentemente, porque trabalho em um sistema grande e, portanto, sou péssimo. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Não importa o quão curto e frequentemente seja o seu código, sempre haverá a possibilidade de ele ter erros. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Errar é humano e nunca se pode provar que um programa está correto. Por que não usar ferramentas como depurador / teste automatizado para nos ajudar nesse negócio difícil?

Se o código for curto o suficiente, serão necessários testes simples. Além disso, se for curto e você souber a natureza do bug, a leitura do código poderá ser suficiente. No entanto, uma vez que a base de código é grande, envolve vários idiomas misturados, além de três camadas, você simplesmente deve ter uma boa cobertura de teste em vários níveis, além de um depurador muito bom - caso contrário, você estará perdendo muito tempo.

Então, quando não preciso de um depurador?

Não sou o codificador mais inteligente, nem o mais experiente, mas, ainda assim, às vezes não preciso usar o depurador. É quando:

• O código é meu ou bem escrito AND
• Está escrito em uma linguagem legível E
• O projeto geral é pequeno.

Quando confio muito em um depurador?

• Resposta curta: frequentemente .
• Quando um aplicativo falha. Especialmente quando é implantado. A instalação do VS2010 nesse computador pode fazer a diferença entre "Erro desconhecido" e FileNotFoundException.
• Quando uma biblioteca de terceiros trava ou se comporta mal.
• Quando o código está mal escrito. Principalmente se o mesmo arquivo foi abordado por 10 pessoas diferentes nos últimos 10 anos, 7 das quais não estão mais na empresa.
• Quando o projeto é grande
• Quando o código é bastante monolítico.
• Quando há várias camadas (GUI, SQL, BL) envolvidas.

Observe que "depurador" pode se referir a mais de uma ferramenta. Eu uso o depurador do Visual Studio, o depurador SQL (principalmente para procs armazenados) e o profiler SQL (para descobrir qual SP está sendo chamado). Precisaria de ferramentas desse calibre para escrever um script rápido do sysadmin-ish Python? Não. Se eu fiz minha própria pequena ferramenta baseada em GUI? Depende. Se for .Net WinForms - provavelmente não. Se for WPF - sim.

O que define um programador "real" de qualquer maneira? Um que é rápido? bem informado? É bom em algoritmos? Escreve boa documentação? Apenas quando exatamente um graduado para este novo título? Quando alguém cruza a linha mágica?

Eu diria que um programador que não sujou as mãos em um esforço existente de mais de 100 anos-homem não teve a chance de ser humilhado pela complexidade e pelas próprias limitações (além de frustrado com a qualidade do código).

Eu, pessoalmente, tento usar o melhor depurador disponível para mim e costumo usá-lo com frequência. Se uma tarefa é simples o suficiente e não requer um depurador - eu não a uso então. Não demora muito para descobrir se eu preciso de um ou não.

...

Agora, em teoria, eu podia ler a base de código por tanto tempo, que simplesmente a obtinha. No entanto, a abordagem prática funciona melhor, e muitas vezes quero reescrever o código estúpido que estou vendo. Infelizmente, levei mais de 10 anos para limpar a base de código em que estou. Portanto, usar o depurador é um primeiro passo óbvio. Somente quando eu descobrir qual das 5 milhões de linhas de código está funcionando, eu digitalizarei o arquivo para cima e para baixo para tentar descobrir o que essa classe está fazendo.

"Eu não gosto de depuradores. Nunca, provavelmente nunca." - Linus Torvalds

Por outro lado, ele não tem uma conta no Stack Overflow, então não tenho certeza se você está interessado na opinião dele :)

Portanto, minha pergunta específica é em que circunstâncias você, como programador experiente, usaria um depurador?

• Quando você não conseguir "depurar" lendo seu código.
• Quando você não consegue prever quais valores, determinadas variáveis ​​têm um determinado tempo.
• Quando o seu modelo mental do seu código não se encaixa na saída fornecida pelo seu código

Editar:

Tive a sorte de não saber usar um depurador em minha jornada de programação. Assim, no passado, fui forçado a depurar sem um depurador. No entanto, depois de aprender a usar um depurador -> me tornei 100x mais produtivo na busca de bugs.

Dar uma perspectiva ligeiramente diferente das respostas atuais; Como engenheiro de software embarcado trabalhando em sistemas que geralmente possuem um componente em tempo real, raramente uso um depurador.

Ocasionalmente, um depurador pode ser uma ferramenta incrível e sempre que posso criar e executar código em uma área de trabalho, sempre utilizo um depurador.

No chip, com restrições em tempo real, há um fardo pesado associado à tentativa de usar um depurador. Assim que você interrompe a execução, é provável que você perturbe, possivelmente fatalmente, o tempo do restante do sistema. Geralmente no chip, printf em código não crítico e E / S oscilando em código crítico de tempo é a melhor e mais simples ferramenta. Não é tão bom quanto um depurador, mas é muito mais barato trabalhar com um sistema real.

Acho que programadores experientes usam quase exclusivamente depuradores, quando são necessários. Qual a melhor maneira de rastrear um bug do que realmente seguir a execução do código ...

Você está sob a suposição de que os Skeets do mundo não cometem erros ou apenas sabem tudo? Todos, exceto os programas mais triviais, se comportam de maneiras inesperadas sob algumas circunstâncias. É certo que os problemas terão que ser investigados. Portanto, as opções são usar instruções de impressão, em uma extremidade do espectro, ou examinar o que aconteceu, post mortem, por outro, ou parecer exatamente no meio enquanto o código é executado e descobrir o que está acontecendo.

Talvez uma maneira melhor de pensar sobre isso seja que programadores experientes sabem quando usar um depurador. No código com poucas dependências, observar um rastreamento de pilha é provavelmente suficiente para descobrir o que está errado. Mas há cenários complicados em que seu código está funcionando com outro código e você precisa de um depurador para examinar as coisas que não escreveu.

Eu não, e estou programando há mais de 10 anos. Eu costumava, quando programava em c / c ++. Agora eu programo em java. A verdade é que, se você estiver registrando corretamente, terá um rastreamento de pilha suficiente para os desenvolvedores mais qualificados. Além disso, se você estiver escrevendo (bons) testes de unidade e testes funcionais, isso elimina toda uma classe de erros.

Quem se importa? O que eu quero saber é que o uso de um depurador me impedirá de ser um programador melhor a longo prazo? Talvez os depuradores fossem de qualidade inferior quando muitos desenvolvedores experientes começaram, então eles eram um obstáculo. É uma muleta que impede uma compreensão mais profunda?

Algum programador, provavelmente melhor que o resto de nós, encontrou a necessidade de um depurador e construiu um (Não faço ideia de quem criou o primeiro). Tenho certeza que eles foram mais produtivos como resultado disso. Duvido que a motivação tenha sido permitir que mortais menores escrevessem código.

Raramente.

Seus métodos devem ser pequenos / simples o suficiente para serem compilados e executados por sua mente; os testes de unidade devem cobrir a funcionalidade. Se você encontrar um bug, escreva um teste. Execute, conserte.

Eu só tendem a usar o depurador quando tenho comportamento inesperado de código não testável, como a estrutura do ASP.NET.

No Smalltalk, desenvolvo quase inteiramente no depurador:

1. Escreva um teste que eu sei que falhará.
2. Execute o teste. Quando falha, o depurador é exibido.
3. Escreva, no depurador, o código necessário para fazer o teste passar.
4. Retomar a execução.
5. Se eu receber uma luz verde, vá para a etapa 1 com um novo teste com falha. Caso contrário, no depurador, descubra o que fiz de errado e corrija-o.

Eu uso um depurador quando preciso. Isso não é diário, mas ocorre ocasionalmente. Às vezes, é melhor seguir o código para ver o que exatamente acontece.

Devo admitir que uso cada vez menos depuradores. Estou desenvolvendo em Delphi há mais de 10 anos. Também escrevo procedimentos armazenados em PL / SQL. Há alguns meses, também sou desenvolvedor de PHP.

Eu uso principalmente o depurador em qualquer um desses casos, se encontrar um pedaço de código obscuro que foi escrito anos atrás e precisar modificá-lo. Às vezes, ajuda a descobrir a maneira exata como um programa funciona, se for difícil ler o código. No PHP, isso quase nunca é necessário, mas no Delphi, que é baseado em eventos, às vezes ajuda quando você tem uma estrutura complexa.

Mas como você diz, usar o depurador é uma exceção. A maioria dos problemas é resolvida apenas lendo o código e corrigindo os erros que você (ou outra pessoa) cometeu.

Mas isso vale para percorrer o código. Costumo usar a pilha de chamadas quando ocorre uma exceção e, ocasionalmente, coloco um ponto de interrupção em algum lugar para inspecionar uma variável. Mas quase sempre em um pedaço de código que precisa de uma refatoração completa de qualquer maneira.

Eu ocasionalmente codifico sem depurador, mas somente quando forçado a um tiro, isto é. gunge incorporado herdado em um 8051 ou Z80.

IMHO, você precisa de um depurador e fazer logon em qualquer trabalho complexo. Uma vez não substitui a outra. Um sistema de registro não pode ajudar se o aplicativo estiver em um driver, por exemplo, onde a única coisa que o código pode fazer é interagir com o hardware e definir um semáforo.

Um depurador não pode ajudar com um erro do sistema em que os aplicativos estão funcionando bem de acordo com a maneira como você os escreveu, mas o sistema ainda não funciona devido a algum erro intermitente no protocolo de comunicação.

Portanto, preciso do depurador para remover os bugs estúpidos e flagrantes e as configurações de hardware. Preciso de um bom log para detectar erros intermitentes de integração do sistema.

Tenho que ter os dois - preciso de toda a ajuda que conseguir!

Eu só uso um depurador quando essas etapas falham:

1. Obtenha o erro reproduzível. Pensar. Isso geralmente é tudo o que é necessário.
2. Verifique qualquer rastreamento e logs de pilha.
3. Adicione mais logs ao redor do código incorreto.

Essas etapas cuidam de 95% de todos os casos. Isso significa que raramente uso um depurador e, quando o faço, tende a me dar muita informação e fico atolado em detalhes não relacionados. Isso é especialmente verdadeiro se você trabalha em um sistema multithread em tempo real.

Portanto, declarações de log colocadas criteriosamente ajudam bastante.

Poderia ser simplesmente que programadores muito experientes são iguais aos programadores muito antigos, e eles aprenderam a programar e formaram seus hábitos, quando os depuradores nem sempre estavam disponíveis e, às vezes, não eram muito bons?

Se você é realmente bom em depuração printf (e nos anos 80, não tínhamos muitas opções, mas nos tornamos realmente bons nisso), talvez um depurador não adicione muito.

É uma questão de escolha pessoal.

Honestamente, acho que os depuradores são úteis em certas situações em que ajuda muito a saber o que está acontecendo com o seu ram em qualquer etapa da execução do programa.

O principal utilitário de um depurador é interromper um programa sem que o programa seja projetado para se interromper: esse recurso é bastante importante.

Além desses dois recursos, não acho que um depurador seja realmente necessário; qualquer programa complexo que você faça deve ter algum tipo de modo "detalhado", ou seja, informando tudo o que está fazendo com printf ou std :: cout, que escolhas ele fez e muitos outros parâmetros.

Imagine que você cria um programa e o usuário tem um problema ao usá-lo: como saber se ele está sendo usado da maneira como foi projetado para ser usado ou se a coisa sobre a qual está reclamando pode ser um bug?

Os depuradores são como a direção elétrica do seu carro: é mais confortável ter um, mas não vai melhorar sua condução.

A programação é sobre design e lógica, a maneira como as ferramentas podem ajudá-lo a rastrear coisas não o torna um programador melhor.

Além disso, depuradores são úteis para idiomas compilados, muito menos para idiomas interpretados.