Refatoração de código TypeScript: quando e como transformar o caos em ordem

Introdução: quando o código começa a "cheirar mal"

Todo desenvolvedor conhece esse sentimento. Você abre um arquivo que escreveu há três meses e seu rosto se contrai. Em algum lugar no fundo da sua alma, você ouve um sussurro: "Não fui eu que escrevi isso, foi algum novato". Mas o retrovisor é implacável: foi você. O código funciona, os testes passam, mas a cada nova funcionalidade adicionada, você gasta cada vez mais tempo. Familiar?

Este é o momento de pensar em refatoração de código TypeScript. Não em reescrever tudo do zero (esse é o caminho para o inferno), mas em melhorias cirurgicamente precisas que tornam o código mais limpo, compreensível e seguro. Neste artigo, vamos analisar quando começar a refatoração, como fazê-lo sem dor e por que o TypeScript lhe dá superpoderes para esse processo.

Quando realizar a refatoração de código TypeScript?

Existe um mito de que a refatoração é uma tarefa separada na sprint. Na prática, a melhor refatoração é um processo contínuo. Mas existem sinais claros que gritam: "Pare! Precisa de ordem aqui!".

A regra dos três (e mais dois)

Se você copiou o mesmo trecho de código três vezes — extraia-o para uma função ou classe. Se você perceber que um colega copiou seu código — essa é a quarta vez. O TypeScript, com sua tipagem forte, torna essa regra especialmente importante: a duplicação de tipos leva à dessincronização de dados.

Sintomas de código "sujo" em TypeScript

• Caos de any: Se no seu projeto any aparece mais do que string — isso é uma bandeira vermelha. O TypeScript perde o sentido.
• Funções-monstro: Uma função com 200+ linhas que faz tudo: valida, analisa, envia requisição e desenha a interface.
• Números e strings "mágicos": if (status === 3) — o que é 3? Ninguém sabe, exceto o autor, que já foi demitido.
• Violação do princípio DRY: Interfaces idênticas espalhadas por 10 arquivos.
• Testes mais assustadores que o código: Se para testar uma função é preciso subir um servidor, um banco de dados e iniciar o Docker — você seguiu o caminho errado.

Lembre-se da regra principal: a refatoração de código TypeScript deve ser feita quando adicionar uma nova funcionalidade leva mais tempo do que escrevê-la do zero. Esse é o momento da verdade.

Princípios básicos: como não quebrar a produção

Antes de começar a refatoração, lembre-se dos três pilares que sustentam uma refatoração segura:

1. Testes são seu seguro. Sem cobertura de testes, refatoração é roleta-russa. Escreva pelo menos testes unitários básicos antes de começar.
2. Passos pequenos. Não tente refatorar o projeto inteiro em uma noite. Um módulo — um commit.
3. O compilador TypeScript é seu amigo. Use configurações estritas no tsconfig.json: strict: true — é seu detector de mentiras.

Técnicas práticas de refatoração com exemplos em TypeScript

Vamos ao que interessa — o código. Veremos três situações reais e mostraremos como melhorá-las.

1. Livrando-se de any: o poder dos genéricos

Exemplo ruim. A função aceita qualquer coisa e retorna qualquer coisa. Isso não é TypeScript, é JavaScript disfarçado.

// RUIM: any destrói a tipagemfunction getFirstElement(arr: any[]): any {  if (arr.length === 0) {    throw new Error('Array is empty');  }  return arr[0];}

const num = getFirstElement([1, 2, 3]); // num: anyconsole.log(num.toUpperCase()); // Erro em tempo de execução, mas o compilador silencia

Exemplo bom. Usamos genéricos. O código se torna mais seguro e a IDE sugere os tipos.

// BOM: genéricos salvamfunction getFirstElement<T>(arr: T[]): T {  if (arr.length === 0) {    throw new Error('Array is empty');  }  return arr[0];}

const num = getFirstElement([1, 2, 3]); // num: numberconsole.log(num.toFixed(2)); // Correto, compilador aprova