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

Introdução: por que o code review é necessário em TypeScript?

O code review não é apenas uma verificação formal do código antes do merge. É uma ferramenta poderosa para melhorar a qualidade do projeto, compartilhar conhecimento na equipe e prevenir bugs nas fases iniciais. Quando se trata de TypeScript, o code review ganha uma importância especial: a tipagem estática, o poderoso sistema de genéricos e as configurações estritas do compilador permitem capturar muitos erros antes mesmo da execução da aplicação. No entanto, mesmo em TypeScript, existem armadilhas que podem ser facilmente ignoradas.

Neste artigo, vamos analisar o que observar ao revisar código TypeScript e como dar feedback de forma que ele seja útil, e não ofensivo.

1. Tipagem e genéricos: não deixe o any estragar tudo

Um dos principais objetivos do TypeScript é tornar os tipos explícitos. Se o código contém any, isso é quase sempre uma bandeira vermelha. Durante o code review, verifique:

• Ausência de any. Substitua por unknown com verificação de tipo posterior ou por um tipo específico.
• Correção dos genéricos. Certifique-se de que os parâmetros de tipo não são perdidos nem se tornam muito amplos. Por exemplo:

// Ruim: perde o tipo
function getFirst(arr: any[]): any {
    return arr[0];
}

// Bom: preserva o tipo através de genérico
function getFirst<T>(arr: T[]): T | undefined {
    return arr[0];
}

• Tipagem de respostas de API. Se um JSON chega do servidor, ele deve ser descrito por uma interface, e não por any.
• Utility types. Use Partial, Pick, Omit para trabalhar de forma flexível com objetos — isso reduz a duplicação de código.

Dica: ative no tsconfig.json as flags strict: true e noImplicitAny: true — isso eliminará a maioria dos problemas em nível de compilação.

2. Lógica e tratamento de erros: não silencie os problemas

TypeScript não protege contra erros lógicos, portanto, o code review deve verificar a lógica de negócio e o tratamento de exceções.

O que observar:

• Tratamento de casos limite. O que acontece se o array estiver vazio, o objeto for null ou a string estiver vazia? Exemplo:

// Ruim: não verifica a existência do elemento
function getUserName(users: User[], id: string): string {
    return users.find(u => u.id === id)!.name; // pode lançar erro
}

// Bom: verifica
function getUserName(users: User[], id: string): string | null {
    const user = users.find(u => u.id === id);
    return user ? user.name : null;
}

• Operações assíncronas. Certifique-se de que as promises são tratadas corretamente com async/await e que os erros são capturados em try/catch.
• Evitar mutações. Se a função não deve modificar os dados de entrada, use readonly e métodos imutáveis (por exemplo, map em vez de forEach com alteração do array externo).

3. Estilo de código e legibilidade: o código é escrito para pessoas

Mesmo um código perfeitamente tipado pode ser ilegível. O code review é um ótimo momento para discutir o estilo.

Pontos principais:

• Nomenclatura. Variáveis, funções e classes devem comunicar seu propósito. Evite nomes de uma letra (exceto para índices de loops). Exemplo: fetchUserData é melhor que getData.
• Tamanho das funções. Uma função não deve fazer mais de uma coisa. Se ela tiver mais de 20-30 linhas, é um motivo para considerar refatoração.
• Comentários. Comentários devem explicar por que o código foi escrito daquela forma, e não o que ele faz. Se o comentário duplica o código, remova-o.
• Formatação. Use ```