Code review em JavaScript: o que verificar e como dar feedback

Code review em JavaScript: o que verificar e como dar feedback para iniciantes

Code review (ou revisão de código) é o processo de verificação do código-fonte por um ou mais desenvolvedores antes que ele entre na branch principal do projeto. Para iniciantes, esse procedimento muitas vezes parece assustador: "E se eu deixar passar um bug?", "Como dizer a um colega que o código dele está ruim sem estragar o relacionamento?".

Neste artigo, vamos abordar o que observar durante um code review em JavaScript (incluindo Node.js) e como dar feedback de forma útil, não ofensiva. O material é voltado para desenvolvedores iniciantes que estão começando a participar de revisões.

O que verificar no código JavaScript: checklist para iniciantes

Para que a revisão seja estruturada, vamos dividir a verificação em vários blocos-chave. Não tente cobrir tudo de uma vez — comece pelos pontos mais críticos.

1. Funcionalidade e lógica

Antes de tudo, certifique-se de que o código resolve a tarefa proposta. Execute-o localmente (se possível) ou percorra mentalmente todos os ramos de execução. Aqui estão perguntas típicas:

\n
• Os casos limite são tratados corretamente (array vazio, null, undefined)?
\n
• Existem "números mágicos" (números sem explicação, como if (x > 86400) em vez de const ONE_DAY_IN_SECONDS = 86400)?
\n
• O código assíncrono funciona corretamente (Promise, async/await)?
\n

// Ruim: número mágico\nif (user.lastLogin < Date.now() - 86400000) { ... }\n\n// Bom: constante com nome\nconst ONE_DAY_MS = 24 * 60 * 60 * 1000;\nif (user.lastLogin < Date.now() - ONE_DAY_MS) { ... }

2. Estilo de código e formatação

Embora muitos projetos usem Prettier e ESLint, vale a pena verificar manualmente:

\n
• Conformidade com um estilo único (indentação, aspas, ponto e vírgula).
\n
• Nomes corretos para variáveis, funções e classes (camelCase para variáveis, PascalCase para classes).
\n
• Ausência de código comentado — ele apenas polui o arquivo.
\n

// Ruim: nome não informativo\nconst d = new Date();\nconst arr = getData(d);\n\n// Bom: nome descreve a essência\nconst currentDate = new Date();\nconst usersData = fetchUsersData(currentDate);

3. Desempenho e segurança

Para Node.js, são especialmente importantes:

\n
• Evitar operações bloqueantes na thread principal (leitura síncrona de arquivos, loops pesados).
\n
• Verificar vazamentos de memória (por exemplo, timers ou listeners de eventos esquecidos).
\n
• Validação de entrada do usuário (proteção contra SQL injection, XSS).
\n

// Ruim: leitura síncrona bloqueia o Event Loop\nconst data = fs.readFileSync('bigfile.json', 'utf8');\n\n// Bom: leitura assíncrona\nconst data = await fs.promises.readFile('bigfile.json', 'utf8');

Como dar feedback: princípios de uma revisão construtiva

Agora que você sabe o que verificar, vamos abordar a principal habilidade do code review — saber comunicar observações. Seu objetivo é melhorar o código, não se afirmar às custas do autor.

1. Seja específico e fundamentado

Em vez de "Este código está ruim", escreva: "Aqui há um potencial problema de desempenho: a chamada Array.find() dentro de um loop resulta em complexidade O(n²). Vamos substituir por Map". O autor entenderá exatamente o que está errado e como corrigir.

2. Use "mensagens-eu" e faça perguntas

Formulações como "Não tenho certeza se este código trata o caso de array vazio. Podemos adicionar uma verificação?" soam mais suaves do que "Você esqueceu de tratar o array vazio". Isso reduz a reação defensiva e estimula o diálogo.

3. Elogie boas soluções

Code review não é só crítica. Se você vir uma solução elegante ou uma arquitetura excelente, destaque isso. Por exemplo: "Ótima ideia extrair