Code review em JavaScript: o que verificar para o código não quebrar

Code review em JavaScript: o que verificar para o código não quebrar

Você já abriu um pull request de outra pessoa e sentiu tudo se contrair por dentro? Como se estivesse olhando para um emaranhado de fios, onde cada nó é um bug em potencial. Code review em JavaScript não é apenas uma marcação no gerenciador de tarefas. É sua última linha de defesa contra o caos. Especialmente no mundo dinâmico do JS, onde a tipagem é uma ilusão e o comportamento "mágico" é a norma.

Neste artigo, vou contar no que realmente prestar atenção ao revisar código JavaScript. Esqueça as discussões sem sentido sobre tabs vs espaços. Vamos falar sobre coisas que afetam diretamente a estabilidade, legibilidade e desempenho. Este é o checklist de code review que eu mesmo uso.

1. Pureza das funções e ausência de efeitos colaterais

O primeiro e mais importante ponto. A função deve fazer exatamente uma coisa e fazê-la bem. Se você vir uma função que ao mesmo tempo valida dados, envia uma requisição para o servidor e atualiza o estado global — isso é um sinal de alerta.

O que verificar:

\n
• Número de argumentos: Idealmente — 0, no máximo — 3. Se for mais, coloque em um objeto de configuração.
\n
• Mutação dos dados de entrada: A função não deve alterar o array ou objeto passado. Isso é um bug difícil de detectar.
\n
• Efeitos colaterais: Qualquer alteração no mundo externo (console.log, escrita em arquivo, alteração do DOM) deve ser explícita e justificada.
\n

Exemplo ruim:

let totalUsers = 0;\n\nfunction processUsers(users) {\n    for (let i = 0; i < users.length; i++) {\n        users[i].active = true; // Mutação dos dados de entrada!\n        totalUsers++;           // Efeito colateral!\n        console.log(users[i]);  // Mais um efeito colateral\n    }\n    return users;\n}

Exemplo bom:

function activateUsers(users) {\n    return users.map(user => ({ ...user, active: true }));\n}\n\n// Uso:\nconst activeUsers = activateUsers(users);\nconsole.log(`Ativados: ${activeUsers.length}`);

Lembre-se: funções puras são a base de um código previsível. Se no code review você vir mutação — escreva um comentário sem medo. Essa é uma das principais causas de bugs difíceis de encontrar em JavaScript.

2. Assincronicidade: Promises e async/await

JS é o rei da assincronicidade, mas também o rei do callback hell. Ao revisar, preste atenção em como as operações assíncronas são tratadas. Verificação de código JavaScript sem analisar cadeias de Promises é perda de tempo.

Bandeiras vermelhas:

\n
• Ausência de tratamento de erros: Sem .catch() ou try/catch. Mais cedo ou mais tarde, isso derrubará a aplicação.
\n
• Promises aninhadas: Se você vir .then() dentro de .then() — é motivo para refatoração.
\n
• await esquecido: Função marcada como async, mas com chamadas internas sem await. Resultado: undefined em vez de dados.
\n

Exemplo ruim (ausência de tratamento de erros):

async function fetchUserData(userId) {\n    const response = await fetch(`/api/users/${userId}`);\n    const data = await response.json();\n    return data;\n}

Exemplo bom:

async function fetchUserData(userId) {\n    try {\n        const response = await fetch(`/api/users/${userId}`);\n        if (!response.ok) {\n            throw new Error(`Erro HTTP! status: ${response.status}`);\n        }\n        return await response.json();\n    } catch (error) {\n        console.error('Erro ao carregar usuário:', error);\n        throw error; // Repassa adiante, mas registra\n    }\n}

Dica para o revisor: sempre exija uma explicação do porquê o try/c