Revisão de código TypeScript: 10 erros que irritam os seniors

Introdução: Por que sua revisão de código TypeScript parece uma luz vermelha no painel?

Você já enviou um pull request e, uma hora depois, recebeu 20 comentários de um desenvolvedor senior, metade começando com "isso pode ser melhorado"? Familiar? Se você escreve em TypeScript, mas seu código ainda faz seus colegas quererem reescrevê-lo do zero — este artigo é para você.

Nós, no PythonLib, frequentemente nos deparamos com situações em que desenvolvedores, mesmo conhecendo a sintaxe do TypeScript, cometem os mesmos erros. Esses erros não quebram o código, mas o tornam ilegível, inseguro e difícil de manter. Hoje, mostrarei 10 comentários típicos que seniors escrevem em code review TypeScript e como evitá-los. Prepare-se para a refatoração!

1. "Any" — seu inimigo, não seu amigo

A reclamação mais comum em qualquer revisão de código TypeScript é o uso de any. Parece mais fácil escrever const data: any = await fetch(...) do que lidar com tipos. Mas os seniors veem isso como uma bandeira vermelha.

Ruim:

function processUser(user: any) {  console.log(user.name.toUpperCase());}

Bom:

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

Por que isso é importante? TypeScript perde todo o sentido se você usa any. Você está literalmente desativando o sistema de tipos. Se os dados vêm de uma API — crie uma interface. Se o tipo é complexo — use unknown com verificações. Esta é uma das principais regras de TypeScript best practices.

2. Ignorar o strict mode

Muitos projetos desativam o modo estrito no tsconfig.json porque "é mais rápido" ou "os tipos irritam". Um desenvolvedor senior TypeScript notará imediatamente que seu código não verifica null e undefined.

Ruim (strict: false):

function getLength(str: string) {  return str.length; // str pode ser null, e isso quebrará}

Bom (strict: true):

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

Dica: Ative strict: true no tsconfig.json. Isso forçará você a escrever código mais seguro. Em uma revisão de código TypeScript, isso será um ponto positivo, não negativo.

3. Mágica com tipos: complexidade excessiva

Às vezes, desenvolvedores tentam mostrar o quão bons são e escrevem tipos que até os seniors coçam a cabeça. Por exemplo, tipos condicionais com genéricos aninhados onde uma interface simples resolveria.

Ruim (over-engineering):

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

Bom (simplicidade):

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

Seniors valorizam a legibilidade do código. Se seu tipo pode ser substituído por uma interface com três campos — faça isso. Não complique sem necessidade.

4. Tratamento incorreto de erros

Um erro típico em code review TypeScript é o try-catch com any ou um bloco catch vazio. Seniors apontarão isso imediatamente.

Ruim:

try {  const data = await fetchData();} catch (e) {  console.log('Erro');}

Bom:

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('Erro desconhecido', error);  }}

Use unknown para erros. Isso é