Thread by @rogermelodev

Nessa thread, você aprenderá:

✅ O que é Blackboxing;
✅ Como utilizar breakpoints de listeners de eventos;
✅ Como utilizar a palavra-chave "debugger";
✅ E muito mais.

Vem debugar comigo! 👇

Investigar erros e debugar uma aplicação é uma habilidade a ser masterizada.

E essa habilidade está ligada ao seu modo de pensar. Ao seu processo resolver um problema inesperado no código.

Ao encontrar um bug, é comum que Desenvolvedores(as) mais novos, por exemplo, fiquem desconfortáveis e comecem a modificar partes do código, o que deixa a situação ainda mais complicada.

Meu objetivo nesta thread é mostrar técnicas úteis para que você lide com bugs em suas aplicações.

🔥 Escreva testes

Este item não ocupa o 1º lugar por acaso.

Escrever testes, principalmente com TDD, deveria ser o default, a realidade do início de todo projeto.

Desenvolver aplicações com TDD diminui drasticamente a densidade de bugs.

Mas, nem sempre você tem o controle sobre esse tipo de decisão.

De qualquer forma, se você encontrou um bug, escreva um teste automatizado que reproduza esse bug.

Isso manterá você focado apenas neste único bug e irá acelerar o processo de resolução. Afinal, você não terá que percorrer manualmente o caminho para reproduzir o bug.

🔥 console.log()

Essa é, de longe, a abordagem mais comum para debugar uma aplicação.

Nada de novo nisso.

Desde quando escrevemos nosso 1º "Hello, World", somos conduzidos a utilizar essa ferramenta.

Mas, há outras alternativas que você deveria conhecer.

🔥 console.log() com contexto

Esta é apenas uma maneira de otimizar o modo como você visualiza o que está sendo investigado.

Essa técnica é muito útil quando você precisa investigar muitas variáveis.

O console.log abaixo exibirá os valores das variáreis no console:

Se adicionarmos 2 caracteres na invocação deste console.log, nos beneficiaremos do Shorthand property names e visualizaremos, de forma mais organizada, tanto os nomes quanto os valores das variáveis:

🔥 console.table()

O método table, do console, exibe os valores de arrays ou objetos em uma tabela.

Isso facilita a visualização e comparação dos dados.

Pode ser útil para você quando for necessário, por exemplo, investigar um array de objetos:

🔥 O seletor "$"

Este seletor funciona de forma similar ao seletor do jQuery.

Ele é um alias para o "document.querySelector", no console do browser.

Já o "$$" é um alias para o "document.querySelectorAll":

🔥 console.trace()

Útil em casos onde você está, por exemplo, trabalhando em um novo callback e não sabe ao certo qual função está invocando qual.

O método trace() exibe uma stack trace no console.

O que é uma stack trace?

Uma stack trace é uma lista ordenada de funções que levam até um determinado ponto em uma aplicação.

É essencialmente um breadcrumb da sua aplicação.

Observe no console que, cada linha representa a função invocada dentro da função da linha abaixo.

Ou seja, o console.trace está mostrando que "myFunc3" foi invocada dentro de "myFunc2" e "myFunc2" foi invocada dentro de "myFunc1".

🔥 console.dir()

Útil quando você quer inspecionar um elemento do DOM como um objeto JavaScript, e não como um markup (que o console.log retorna).

Com o console.dir(), você consegue visualizar mais facilmente as propriedades e métodos que esse objeto possui.

🔥 console.dir() no NodeJS

Ao executar o console.dir no console do NodeJS, você pode setar que o output de um objeto seja colorido e que propriedades aninhadas sejam exibidas:

🔥 Breakpoints e a palavra-chave "debugger"

No código abaixo, a função "handleParagraphClick", que possui um "debugger" dentro dela, é executada quando clicamos no parágrafo.

Ao executarmos o script no chrome e clicarmos no parágrafo, a execução do código é pausada exatamente na linha onde declaramos o debugger.

Nesse momento, o browser está esperando você decidir o que deve ser feito.

Você pode pular para a próxima linha do código ou retomar a execução do script.

Você também pode adicionar breakpoints, clicando no número da linha do script. Vamos adicionar um breakpoint na linha 8, onde "num" recebe 5:

Ao clicarmos no "play" (botão azul com uma seta), a execução do script será retomada até a linha do breakpoint que criamos:

Ou seja, com breakpoints, é possível pausarmos a execução do script em diferentes locais e verificarmos onde erros estão acontecendo.

É possível, por exemplo, investigarmos o que está acontecendo com as variáveis do script.

Para fazermos este teste, voltaremos ao ponto inicial da execução da página, clicando no "play", atualizando a página e clicando no parágrafo.

Observe que na sessão "watch", no canto superior direito do console, podemos clicar no "+", digitar o nome da variável que desejamos observar e pressionar enter.

Isso fará com que o valor que a variável possui no momento em que o código está pausado seja exibido:

Ou seja, até o ponto da execução do debugger, "num" armazena 3.

Ao clicarmos no "play", a execução é pausada no breakpoint e o watch exibe que agora, "num" armazena 5.

Você também tem a opção de investigar esses valores selecionando o trecho do código a ser investigado e deixando o cursor do mouse parado em cima dele.

E claro, estamos investigando apenas uma variável que possui uma reatribuição explícita aqui.

Porém, se você está trabalhando em um código complexo, com muitas variáveis, objetos, arrays, etc... utilizando essa técnica, você pode descobrir como e quando esses objetos estão sendo modificados.

🔥 Breakpoints de listeners de eventos

Úteis quando você quer investigar o código que um event listener dispara.

Você pode selecionar eventos específicos, como o "click", ou categorias de eventos, como eventos do mouse.

Utilizando o mesmo código do exemplo anterior, vamos selecionar a aba "sources" do console e, na sessão "Event Listener Breakpoints", clicaremos na seta à esquerda de "Mouse" e marcaremos o checkbox com a opção "click".

Feito isso, ao clicarmos no parágrafo, o browser automaticamente cria um breakpoint na função de callback que o evento disparou.

🔥 Blackboxing

Talvez, ao reproduzir a técnica acima, o seu breakpoint tenha sido criado e exibido em um arquivo diferente do que estamos trabalhando ou em uma linha de código de uma lib third-party.

Só que o problema que estamos debugando não está relacionado a esse arquivo, certo? Então, faz sentido o ignorarmos.

Copie o nome do arquivo e no canto superior direito do console, clique nos 3 pontos verticais e depois na opção "settings".

No painel à esquerda, clique em "Blackboxing" e no botão "Add pattern...".

Este input aceita o nome do arquivo ou Regex patterns dos nomes dos scripts a serem ignorados.

Observe que após adicionar o nome do script e fechar essa sessão do console, clicando no "x" do canto superior direito, o console já exibe uma mensagem avisando que este arquivo está marcado como ignorado.

Se fecharmos a aba do arquivo e recarregarmos a página, ao clicar no parágrafo, o breakpoint é criado na linha correta, como o esperávamos.

Espero que esse conteúdo ajude você a debugar suas aplicações.

Acha que esse conteúdo pode ajudar + pessoas❓

👉Retweeta👈 essa thread!

Linkei o início dela ali
em baixo, para facilitar =)

https://twitter.com/rogermelodev/status/1198647029884506113

Baixe meu eBook gratuito e com exercícios 👇

https://twitter.com/rogermelodev/status/1179150503403491331