4 respostas

★ Melhor resposta

Uma coisa que você nunca vê mencionada é usar a aba Network em paralelo. Muitas vezes você pensa que seu JavaScript está bugado quando na verdade o problema é que uma chamada de API falhou silenciosamente ou retornou dados estranhos. Sempre confira as respostas do backend antes de garimpar seu código front-end - te poupa horas.

Para o resto, o verdadeiro truque é aprender a ler o stack trace. Quando um erro aparece, não olhe só onde diz "erro aqui", mas rastreie o caminho de chamadas que o causou. Muitas vezes a verdadeira fonte do bug fica dois ou três níveis acima na cadeia. E se você usa TypeScript ou um linter decente, você já pega a maior parte dos problemas antes mesmo de fazer debugging de verdade.

Quantos console.log() você está colocando no código antes de perceber que o Chrome DevTools já tem tudo que você precisa?

A real mudança de perspectiva é parar de pensar o debugging como uma caça ao tesouro desesperada. O Chrome DevTools tem a aba Sources, que te permite colocar breakpoints de verdade - não só "imprime esse valor e torce" - e fazer step line by line pelo código. A coisa que a galera não usa o suficiente é o watch de variáveis específicas, então você vê em tempo real o que muda enquanto o código roda. Aí tem o console drawer que fica sempre à mão, perfeito para fazer quick check sem parar a execução.

Outra coisa que me salvou várias vezes: usar a aba Network não só para ver se as requisições saem, mas para checar exatamente o que você recebe do servidor. Quantas vezes passei horas debugando lógica que era na verdade um problema nos dados que chegavam. Se a app é complexa e tem um estado interno, o Vue DevTools ou React DevTools (depende do que você usa) são killer - você vê o estado mudar em tempo real e volta pros estados anteriores. Não é mágica, é só que a galera muitas vezes não sabe que existem.

Ah, e uma última coisa boba mas verdadeira: coloca breakpoints condicionais. Nem sempre você quer parar numa linha, você quer parar só quando uma certa variável tem um certo valor. Pelo menos você economiza tempo de ficar clicando "continue" mil vezes.

Não desperdice tempo colocando breakpoints aleatórios nas funções; em vez disso, use as Condições do Chrome DevTools para parar a execução apenas quando uma variável atinge um valor específico - muda completamente a forma como você rastreia bugs em apps complexos. E quando você se depara com um erro que parece aleatório, a aba Network frequentemente revela o que você não vê no código, como race conditions ou respostas de API malformadas.

Quando você começa a debugar, quantos breakpoints coloca antes de perceber que o problema provavelmente está em outro lugar?

O que frequentemente falta é uma abordagem sistemática. Chrome DevTools é poderoso, mas muitos usam apenas console.log e breakpoints clássicos. Tente conditional breakpoints: clique com o botão direito na linha de código, escolha "Add conditional breakpoint" e escreva a condição que te interessa. Por exemplo, um breakpoint que só ativa quando `user.id === undefined` em vez de parar toda vez. Depois use Logpoints (semelhante, mas imprime uma mensagem sem parar a execução) quando precisar rastrear valores sem quebrar o fluxo.

Um truque que poucos conhecem: na aba Network do DevTools, você pode filtrar e ver exatamente o que está dando errado com suas requisições. Se o app se comporta estranho, muitas vezes o problema é que uma request não é o que você acha ou a resposta está malformada. Use também a aba Performance se suspeitar de lag: registre o que acontece e veja onde o código realmente desacelera. Por fim, aprenda a usar Watch expressions: na seção Scope, adicione as variáveis que te interessam e veja elas atualizarem em tempo real conforme você avança no código. Você economiza um monte de prints desnecessários.

ricci1987 asker Obrigada pelos conselhos! Eu não usava os conditional breakpoints e os logpoints, são exatamente o que eu procurava. Vou tentar agora a aba Network para as requisições.

Sua resposta

Entrarpara responder.