Refatoração de código JavaScript: quando e como não quebrar o projeto

Seu código funciona — mas isso não significa que ele é bom

Você escreveu um script. Ele é executado. Os clientes estão satisfeitos. Mas passa um mês, e você olha com horror para aquela função que cresceu para 200 linhas. Nela estão misturadas requisições à API, manipulações do DOM e alguma mágica com datas. Familiar?

Bem-vindo ao mundo onde a refatoração de código JavaScript não é um capricho de perfeccionista, mas uma necessidade vital. Se você quer que seu projeto viva por muito tempo e não desmorone na primeira alteração, este artigo é para você.

O que é refatoração e o que ela não é

Vamos começar pelo principal. Refatoração de código JavaScript é o processo de alterar a estrutura interna de um programa sem modificar seu comportamento externo. Você não adiciona novas funcionalidades, não corrige bugs. Você apenas torna o código mais limpo, compreensível e fácil de manter.

Muitos confundem refatoração com reescrita. São coisas diferentes. Reescrita é quando você descarta o código antigo e escreve um novo do zero. Refatoração é evolução, não revolução. Você altera o código em pequenos passos, verificando a cada vez que nada quebrou.

Quando realizar a refatoração de JavaScript?

Aqui estão alguns sinais claros de que seu código está pedindo socorro:

\n
• Regra de três. Se você está copiando o mesmo trecho de código pela terceira vez — é hora de extraí-lo para uma função separada.
\n
• Função-monstro. Uma função com mais de 30–40 linhas que não pode ser lida de uma só vez.
\n
• "Números mágicos". Números como 86400000 ou 42 espalhados pelo código sem comentários ou constantes.
\n
• Variáveis globais. Se você tem medo de alterar uma variável porque não sabe onde mais ela é usada.
\n
• Testes. Se você tem medo de fazer alterações porque não há testes automatizados — este é o primeiro sinal de alerta.
\n

Mas também há situações em que a refatoração não é necessária: antes de um prazo final, em produção sem testes, ou quando o código foi escrito às pressas para um protótipo que será descartado amanhã.

Técnicas de refatoração de JavaScript: do simples ao complexo

1. Extração de Função (Extract Function)

A técnica mais popular e segura. Você encontra um fragmento de código que pode ser agrupado e o extrai para uma função separada.

// ANTES da refatoração\nfunction calculateInvoice(items) {\n  let total = 0;\n  for (let item of items) {\n    total += item.price * item.quantity;\n  }\n  let discount = 0;\n  if (total > 1000) {\n    discount = total * 0.1;\n  }\n  return total - discount;\n}\n\n// DEPOIS da refatoração\nfunction calculateSubtotal(items) {\n  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);\n}\n\nfunction calculateDiscount(total) {\n  return total > 1000 ? total * 0.1 : 0;\n}\n\nfunction calculateInvoice(items) {\n  const subtotal = calculateSubtotal(items);\n  const discount = calculateDiscount(subtotal);\n  return subtotal - discount;\n}\n

O que mudou? Agora cada função é responsável por uma única ação. Você pode reutilizar calculateSubtotal em outro lugar, e calculateDiscount pode ser facilmente testada separadamente.

2. Substituição de números mágicos por constantes

Nunca use números "soltos" no código. Em um mês, você mesmo não se lembrará do que significa 86400000.

// RUIM\nif (Date.now() - lastLogin > 86400000) {\n  // solicitar novo login\n}\n\n// BOM\nconst MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000;\nconst ONE_DAY_MS = 86400000; // ou apenas uma constante legível\n\nif (Date.now() - lastLogin > ONE_DAY_MS) {\n  // solicitar novo login\n}\n

3. Simplificação de estruturas condicionais

Condicionais if-else complexas e aninhadas são o maior inimigo da legibilidade. Use retorno antecipado (early return) e operadores ternários.

<