Como fazer análise de código JavaScript na prática
A análise de código JavaScript envolve inspecionar a estrutura, a lógica e o desempenho de um arquivo ou projeto inteiro para identificar bugs, más práticas e gargalos. Não é só rodar um linter e torcer para que nada exploda. O trabalho real acontece quando você lê o código com intenção.
analise o código em javascript com a ferramenta certa
Para começar, você precisa de um conjunto básico de ferramentas. O ESLint é o padrão do setor, mas sozinho ele não mostra problemas de runtime. Combine ele com o SonarQube ou o CodeClimate se quiser uma análise mais profunda que cruza métricas de complexidade ciclomatica com regras de segurança. Para performance, o Lighthouse e o Chrome DevTools Coverage panel são suficientes na maioria dos casos. Eu configurei um pipeline simples uma vez que usava ESLint com a configuração Airbnb, TypeScript parser, e um plugin de React hooks. Rodava tudo num Docker container como parte do CI. O problema era que o build demorava quatro minutos e meio em média, e ainda assim deixava passar um bug silencioso de variable shadowing que só aparecia em produção.
A solução foi adicionar o eslint-plugin-no-shadow com regras estritas e dividir o lint em duas fases: uma rápida no pre-commit e uma completa no CI. Isso cortou o tempo de feedback de quatro minutos para cerca de quarenta segundos na fase rápida, e o bug sumiu porque o linter passou a detectar variáveis com o mesmo nome em escopos aninhados. O que muita gente não considera é que analisar código JavaScript tem limitações sérias com dynamically typed code. O ESLint sozinho não consegue saber se uma função espera um objeto com a propriedade correta ou uma string. O TypeScript resolve isso parcialmente, mas se o projeto já não usa type annotations, migrar só para poder analisar melhor pode levar semanas.
Passo a passo para uma análise funcional
O primeiro passo é instalar as dependências no seu projeto. Se você já tem um package.json, rode npm install --save-dev eslint eslint-config-airbnb-base eslint-plugin-import @typescript-eslint/parser @typescript-eslint/eslint-plugin. Isso vai instalar o linter base mais as extensões mais usadas. Se o projeto for puramente JavaScript sem TypeScript, pule os dois pacotes que começam com @typescript-eslint. Depois, crie um arquivo .eslintrc.json na raiz do projeto. Comece com uma configuração mínima que funcione:
{ "extends": ["eslint:recommended", "airbnb-base"], "parserOptions": { "ecmaVersion": 2022, "sourceType": "module" }, "env": { "node": true, "es2022": true }, "rules": { "no-console": "warn", "prefer-const": "error", "no-var": "error" } } Esse arquivo já ativa regras que pegam os erros mais comuns: declaração de variáveis com var em vez de let ou const, console.log esquecido em código de produção, e variáveis que não são reatribuídas mas foram declaradas com let.
Rode o comando npx eslint . --ext .js,.jsx,.ts,.tsx --max-warnings 0. O flag --max-warnings 0 faz com que o comando retorne código de saída diferente de zero se houver qualquer warning, o que é essencial para CI. Sem esse flag, erros silenciosos se acumulam e viram dívida técnica que ninguém mais quer tocar. Um detalhe prático que não aparece nos tutoriais: arquivos gerados automaticamente, como os de node_modules, dist ou build, devem ser ignorados. Crie um .eslintignore com node_modules/ dist/ build/ coverage/. Se não fizer isso, o linter vai processar milhares de arquivos irrelevantes e o tempo de análise pode subir de trinta segundos para quinze minutos ou mais, dependendo do tamanho do projeto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para análise de qualidade além do lint, adicione o npm install --save-dev jest @testing-library/jest-dom. Testes unitários são parte da análise de código. Um arquivo sem testes não pode ser considerado analisado de forma completa, porque você não tem como saber se uma refatoração quebrou comportamento sem executar algo. Cobre funções puras primeiro. São mais fáceis de testar e dão o maior retorno. Uma função que calcula total de um carrinho de compras, por exemplo, deve ter pelo menos três casos de teste: carrinho vazio, carrinho com um item, e carrinho com múltiplos itens e diferentes preços. Se essa função passa em todos os casos, você tem confiança razoável de que a lógica central está correta.
Performance analysis funciona de forma diferente. Use o Chrome DevTools Performance tab para gravar uma sessão de uso real da aplicação. Olhe os picos de CPU e os long tasks que passam de cinquenta milissegundos. Long tasks assim bloqueiam a thread principal e causam jitter visível. A causa mais comum em projetos JavaScript é callback hell encadeado, loop síncrono pesado, ou parsing de JSON muito grande na thread principal. Uma vez encontrei um projeto onde um endpoint de API retornava um array de dez mil objetos e cada um era percorrido com um reduce antes de ser serializado. O reduce fazia uma conversão de moeda dentro do loop. Isso gerava um long task de duzentos milissegundos. A correção foi mover a conversão para o banco de dados com uma query SQL direta, reduzindo o payload para aproximadamente duzentos objetos e o tempo de processamento para menos de dez milissegundos. Análise de performance nesse nível exige olhar o código que gera os dados, não só o código que os consome.
Pegadinhas comuns e como evitar
Async/await mal usado é o erro mais frequente em código JavaScript moderno. Quando você usa await dentro de um map, cada iteração espera a anterior terminar. O resultado é linear em vez de paralelo. A correção é usar Promise.all com map, passando todas as promessas de uma vez e esperando o lote completo. Outro problema recorrente é o uso de any em TypeScript sem justification. Any desativa toda verificação de tipo e transforma o TypeScript em JavaScript disfarçado. Se você precisa de any, coloque um comentário explicando o motivo. Se não consegue justificar, refatore até que o tipo seja deduzido corretamente.
State management em React com useState para coisas que não precisam de re-renderização é outro padrão problemático. Variáveis que mudam durante o ciclo de vida de um componente mas não afetam o render devem ser refs, não state. O uso incorreto de state causa re-renderizações desnecessárias que degradam performance em interfaces complexas. Package-lock.json desatualizado é uma armadilha silenciosa. Se você atualiza dependências manualmente sem rodar npm install depois de mudar o package.json, o lock file pode conter versões incompatíveis. Sempre rode npm install depois de qualquer alteração no package.json antes de submeter código para review.
Quando a análise automática falha
Ferramentas estáticas não conseguem detectar problemas de lógica de negócio. Um código pode passar em todos os lint rules e ainda assim calcular o imposto errado porque a regra de negócio foi implementada com uma condição invertida. Testes de integração e code review humano são indispensáveis para cobrir esse gap. Dependências com vulnerabilidades conhecidas também são difíceis de capturar automaticamente num contexto de projeto real. O npm audit ajuda, mas ele só verifica o grafo direto de dependências. Dependências dethird party transitivas podem ter vulnerabilidades que o audit não sinaliza imediatamente. Use o npm audit --long para ver mais detalhes e Considere o Snyk ou o Dependabot como complemento para monitoramento contínuo.
O custo de manter uma configuração de lint rigorosa em projetos legados é alto. Projetos com décadas de código JavaScript sem tipagem, sem testes e com padrões misturados de ES5, ES6 e TypeScript podem levar semanas só para configurar o ambiente de análise. Nesse caso, o recomendado é começar com regras básicas, permitir warnings em vez de errors, e aumentar a rigidez gradualmente conforme o código novo é escrito. Tentar corrigir tudo de uma vez geralmente resulta em rejeição da equipe e a análise nunca é adotada.
