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

Code review em TypeScript: o que verificar e como dar feedback na prática

Code review não é apenas uma formalidade, mas uma ferramenta poderosa para melhorar a qualidade do código. Em TypeScript, com seu rico sistema de tipos, a revisão pode ser especialmente eficaz. Neste artigo, vamos abordar o que observar ao revisar código TypeScript e como dar feedback para que seja útil, e não ofensivo. Todos os exemplos são com código real.

1. Tipos e anotações: evite `any` e use rigor

A primeira coisa que chama a atenção em uma revisão de código TypeScript são os tipos. TypeScript foi criado para capturar erros em tempo de compilação, portanto any é uma bandeira vermelha.

O que verificar:

\n
• Presença de any. Cada any deve ser justificado. Se for migração de JS — ok, mas em código novo — não.
\n
• Correção dos tipos. Não use string onde for necessário enum ou union type.
\n
• Tipagem excessiva. TypeScript consegue inferir tipos. Não escreva const x: number = 5 — escreva const x = 5.
\n
• Configurações rigorosas. Verifique se no tsconfig.json estão habilitados strict: true, noImplicitAny, strictNullChecks.
\n

Exemplo de código ruim:

function processData(data: any) {\n  return data.name.toLowerCase();\n}

Como corrigir:

interface User {\n  name: string;\n}\n\nfunction processData(data: User): string {\n  return data.name.toLowerCase();\n}

Como dar feedback:

Em vez de "Você está usando any, isso é ruim", diga: "Aqui o any desativa a verificação de tipos. Vamos descrever a interface User — isso aumentará a segurança e a legibilidade do código".

2. Trabalhando com null e undefined: strictNullChecks salva vidas

Erros de Cannot read property of undefined são clássicos. TypeScript com strictNullChecks ajuda a evitá-los, mas apenas se o desenvolvedor tratar corretamente os valores anuláveis.

O que verificar:

\n
• Verificação de null/undefined antes de acessar propriedades.
\n
• Uso de optional chaining (?.) — é moderno e seguro.
\n
• Operador ! (non-null assertion) — use apenas se tiver 100% de certeza que o valor não é null. Melhor substituir por uma verificação explícita.
\n
• Uso correto de ?? (nullish coalescing) em vez de || para valores padrão.
\n

Exemplo de código ruim:

function getCity(user: User | null): string {\n  return user!.address!.city; // Perigoso!\n}

Como corrigir:

function getCity(user: User | null): string {\n  return user?.address?.city ?? 'Unknown';\n}

Como dar feedback:

"O uso de ! aqui é arriscado — se user for null, ocorrerá um erro. Vamos substituir por ?. e ?? — é seguro e legível".

3. Genéricos e tipos utilitários: não complique sem necessidade

Genéricos são um recurso poderoso, mas é fácil complicá-los demais. O revisor deve buscar o equilíbrio entre flexibilidade e legibilidade.

O que verificar:

\n
• Complexidade excessiva. Se o genérico é usado apenas uma vez, talvez não seja necessário.
\n
• Uso correto de extends — restrinja os genéricos para que não aceitem qualquer coisa.
\n
• Tipos utilitários (Partial, Pick, Omit, Record) — seu uso simplifica o código.
\n
• Tipos de valores de retorno — uma função com gené