Oii, Luidi.
Boas demais suas perguntas. Você tocou em pontos de organização e arquitetura que fazem diferença quando o projeto começa a crescer. Vamos analisar ponto a ponto.
- Debug vs. Console.log
A principal diferença entre eles é o controle.
- console.log: Ele "fala" sempre. Se o código passar por aquela linha, a mensagem será exibida no terminal. Em um projeto grande, se todos os arquivos tiverem
console.log, o terminal vira uma mistura caótica de mensagens, dificultando achar o erro real. Além disso, esquecer um console.log imprimindo um objeto gigante em produção pode afetar a performance e encher os logs do servidor com lixo. - debug: Ele funciona como canais de rádio. Você categoriza as mensagens (ex:
app:banco, app:autenticacao, app:socket). Por padrão, ele fica em silêncio. Você só vê as mensagens se "sintonizar" no canal específico através da variável de ambiente DEBUG.
Quando usar cada um?
- Use
console.log: Pra testes rápidos e descartáveis durante o desenvolvimento (o famoso "será que entrou neste if?"), ou para saídas que o programa deve mostrar para o usuário final (como em ferramentas de linha de comando CLI). - Use
debug: Pra deixar "rastros" permanentes no código que ajudem a entender o fluxo da aplicação. Você pode deixar o log lá para sempre; ele não vai atrapalhar ninguém até que alguém precise investigar aquele módulo específico.
- Onde guardar as variáveis de ambiente do Debug?
Aqui precisamos separar o que é dado sensível (senhas, chaves de API) do que é configuração de comportamento (nível de log, porta do servidor).
A variável DEBUG não contém senhas, apenas define o que será exibido na tela. Por isso, a lógica de segurança é diferente de uma chave de banco de dados.
Analisando suas opções:
- Direto no terminal (
DEBUG=app:* node server.js):
- Uso: Ideal para investigações pontuais. Exemplo: você quer ver apenas os logs de banco de dados naquele momento específico para achar um bug. Você roda o comando, vê o erro e pronto.
- No arquivo
.env:
- Uso: É útil se você quer deixar uma configuração padrão para o seu computador local sem afetar os outros desenvolvedores. Porém, nativamente o
debug não lê o .env sozinho (você precisaria carregar o dotenv antes do debug iniciar, o que pode ser uma "gambiarra" dependendo da ordem de importação).
- No
package.json (nos scripts):
- Uso: É a opção mais indicada para padronizar o ambiente de desenvolvimento do time.
- Você pode criar um script assim:
"dev": "DEBUG=app:* nodemon server.js". - Por que pode ir para o repositório? Porque saber que o projeto usa o namespace
app:* não é uma falha de segurança. Pelo contrário, ajuda quem baixar o projeto a saber como rodar vendo os logs corretamente.
Espero ter ajudado.
Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!