A Síndrome do Desenvolvedor que Refatora Tudo (E Nunca Entrega Nada)

Ou: Como transformei um bug de 5 minutos em 3 semanas de "melhorias"

Sabe aquela task que era pra ser simples? "Corrigir o botão de login que não está funcionando no Safari". Estimativa: 30 minutos. Realidade: 2 semanas depois, você reescreveu todo o sistema de autenticação, implementou um design pattern que viu no Medium, migrou pra TypeScript, adicionou testes end-to-end, e o botão... bem, o botão ainda não funciona no Safari.

Se identificou? Bem-vindo ao clube dos Refactoring Addicts Anonymous.

Como Tudo Começou: A Inocência Perdida

Era uma terça-feira tranquila. Ticket simples no Jira: "Botão de login quebrado no Safari". Pensei: "Moleza, deve ser CSS".

Abri o código.

function login() {
// TODO: refatorar isso aqui
var usuario = document.getElementById('user').value;
var senha = document.getElementById('pass').value;
if(usuario == 'admin' && senha == '123') {
  alert('Bem vindo!');
}
}

Meus olhos sangraram. Meu coração acelerou. Minha mente gritou: "ISSO É UM CRIME CONTRA A HUMANIDADE!"

E foi aí que tudo desandou.

Os 7 Estágios da Refatoração Compulsiva

Estágio 1: Negação

"Só vou arrumar esse if aqui rapidinho..."

5 minutos depois, você já trocou var por const, adicionou arrow functions, e criou um hook customizado useAuth().

Estágio 2: Raiva

"QUEM FOI O ANIMAL QUE ESCREVEU ISSO?!"

(Você abre o git blame... era você há 6 meses. Constrangimento intenso.)

Estágio 3: Barganha

"Ok, vou só organizar esses arquivos por feature antes de mexer no código..."

Agora você está criando uma pasta src/features/auth/components/molecules/ porque viu um artigo sobre Atomic Design.

Estágio 4: Depressão

"Por que eu fiz isso? O prazo é amanhã..."

Você tem 47 arquivos modificados, 3 branches abertas, e o botão ainda não funciona.

Estágio 5: Teste (Literal)

"Já que estou aqui, vou adicionar testes..."

Três dias depois, você tem 100% de code coverage mas zero funcionalidades novas.

Estágio 6: Mais Refatoração

"Sabe o que falta? Um design pattern!"

Implementa Factory, Strategy, Observer, e considera seriamente adicionar um Singleton (mas lembra que aprendeu que isso é anti-pattern).

Estágio 7: Aceitação (???)

"Vou fazer um commit e fingir que sempre foi essa a task..."

Commit message: feat: improve authentication system architecture and add comprehensive test coverage (esconde que o bug original ainda existe)

A Anatomia de Uma Refatoração Desnecessária

O Gatilho: Código "Feio"

Todo desenvolvedor tem um limite do que considera "código aceitável". O meu é bem baixo. Se eu vejo:

Função com mais de 10 linhas → REFATORA
Variável chamada data ou info → REFATORA
If aninhado → REFATORA ONTEM
Comentário dizendo // gambiarra → PARADA CARDÍACA + REFATORA

A Espiral: "Já Que Estou Aqui..."

Essa é a frase mais perigosa da programação. Mais perigosa que rm -rf /. Mais perigosa que DROP TABLE.

"Já que estou aqui, vou..."
→ Renomear essas variáveis
→ Extrair essa função
  → Criar esse componente
    → Adicionar TypeScript
      → Configurar ESLint
        → Atualizar todas as dependências
          → Migrar pra Vite
            → Reescrever tudo em Rust

O Resultado: Overengineering Artístico

Você começou com:

function soma(a, b) {
return a + b;
}

Terminou com:

interface ICalculationStrategy {
execute(operands: number[]): number;
}

class AdditionStrategy implements ICalculationStrategy {
execute(operands: number[]): number {
  return operands.reduce((acc, curr) => acc + curr, 0);
}
}

class CalculatorFactory {
static createCalculator(type: 'addition' | 'subtraction'): ICalculationStrategy {
  // 50 linhas depois...
}
}

Para somar 2 + 2.

Por Que Fazemos Isso? (A Psicologia do Dev)

1. Perfeccionismo Disfarçado de Profissionalismo

Convencemos a nós mesmos que estamos "fazendo o trabalho direito". Na verdade, temos medo de julgar nosso código futuro. Aquela voz na cabeça: "Daqui 6 meses vou olhar isso e querer me demitir".

Spoiler: você VAI querer se demitir de qualquer jeito. Aceite.

2. Procrastinação Produtiva

Refatorar é a forma socialmente aceitável de procrastinar. Ninguém vai te julgar por "melhorar a qualidade do código". Mas todos sabemos a verdade: você tá fugindo daquela feature complicada que prometeu entregar.

3. Síndrome do Impostor Reversa

"Se eu escrever código simples, vão pensar que sou júnior. Preciso mostrar que sei design patterns!"

Plot twist: código simples que funciona é sinal de dev sênior. Overengineering é sinal de insegurança.

4. A Ilusão do Controle

Bugs são assustadores. Novos requisitos são imprevisíveis. Mas refatoração? Ah, refatoração você controla. É seu cantinho seguro onde você é o rei.

Até o PM perguntar cadê a feature.

Casos Reais de Refatoração que Saíram do Controle

Caso 1: O Dev que Reinventou o React

Ticket: Adicionar loading spinner no botão

Resultado: Framework proprietário de gerenciamento de estado baseado em observables

Tempo: 3 sprints

Status do spinner: Pendente

Caso 2: A Migração Infinita

Ticket: Atualizar versão do Node

Resultado: Migração completa pra monorepo com Nx, microserviços, GraphQL Federation

Tempo: 8 meses

Versão do Node: Ainda a antiga

Caso 3: O Teste que Virou Filosofia

Ticket: Adicionar teste unitário pra função de validação

Resultado: TDD religioso, 100% coverage, integração com SonarQube, CI/CD complexo

Tempo: 1 mês

Bugs encontrados pelos testes: 0

Bugs em produção: 7

O Teste Definitivo: Você é um Refactoring Addict?

Marque quantas se aplicam:

[ ] Já reescreveu código que funcionava perfeitamente
[ ] Tem branches com nome refactor-* mais antigas que 3 meses
[ ] Já discutiu por mais de 1 hora se variável deve ser user ou userData
[ ] Implementou design pattern só porque leu sobre ele no fim de semana
[ ] Tem mais arquivos de configuração que arquivos de código
[ ] Já migrou de framework/biblioteca sem necessidade real
[ ] Sente prazer físico ao ver git diff com mais linhas deletadas que adicionadas
[ ] Considera "organizar imports" uma task válida
[ ] Já perdeu prazo porque estava "melhorando a arquitetura"
[ ] Lê sobre Clean Code antes de dormir

0-3: Você é normal (ou está mentindo)

4-6: Refactoring Enthusiast - controlável

7-8: Refactoring Addict - procure ajuda

9-10: Você É o problema do time (mas o código tá lindo)

Como Se Recuperar: Um Guia Prático

Passo 1: Admita o Problema

"Meu nome é João, e eu refatoro código que funciona."

[Aplausos do grupo de apoio]

Passo 2: A Regra dos 3 Whys

Antes de refatorar, pergunte 3 vezes "por quê?":

Por que preciso refatorar isso? "Porque está feio"
Por que está feio? "Porque não segue o padrão X"
Por que precisa seguir o padrão X? "Porque... hmm... porque sim?"

Se não tem resposta clara, não refatore.

Passo 3: O Princípio do "Funciona? Não Mexe"

Código legado é como um Jenga. Pode estar feio, pode estar torto, mas está de pé. Você realmente quer ser o cara que derrubou a torre?

Passo 4: Refatoração com Propósito

Refatore apenas quando:

Vai adicionar feature nova na área
Tem bug recorrente ali
Está afetando performance
Tem testes cobrindo (se não tem, adicione ANTES)

Passo 5: Time-boxing

"Vou refatorar isso por NO MÁXIMO 2 horas". Use timer. Seja sério.

Se em 2 horas não terminou, reverta e aceite que o código vai viver assim.

Passo 6: Code Review Honesto

Pergunte pro colega: "Isso realmente melhorou ou só mudou?"

Se a resposta for "mudou", reverta com dignidade.

A Sabedoria dos Anciãos

Conversando com devs seniores de verdade (aqueles com cabelos grisalhos de tanto lidar com legacy), descobri pérolas:

"Código bom é código que funciona e que outros entendem. Código perfeito não existe, então para de tentar." - Dev Sênior, 45 anos, 3 refatorações falhadas

"Jovem, já vi sistemas legados horríveis rodando há 15 anos gerando milhões. Já vi códigos lindos que duraram 3 meses. Priorize valor." - Arquiteto de Software que já viu de tudo

"Se você não sente vergonha do código que escreveu há 6 meses, é porque não evoluiu." - Sabedoria popular dev

A Reflexão Final: Equilíbrio

Refatoração não é vilã. Código limpo não é besteira. O problema é o extremo.

Código perfeito que nunca é entregue = 0 valor

Código "feio" em produção gerando receita = valor real

A verdade está no meio:

Refatore quando agregar valor (performance, manutenibilidade, bugs)
Não refatore por ego ou tédio
Entregue primeiro, melhore depois
Code review serve pra isso também
Technical debt existe, mas não precisa pagar tudo hoje

O Mantra do Dev Equilibrado

function desenvolver() {
while (true) {
  if (funciona && entrega_valor) {
    commit();
    deploy();
    break; // SIM, BREAK. PARE DE MEXER.
  }
  
  if (tem_bug || impacta_negocio) {
    refatorar();
  } else {
    // DEIXA QUIETO, PELO AMOR
    break;
  }
}
}

Epílogo: O Bug do Safari

Ah sim, o bug do Safari que começou tudo isso.

Era um event.preventDefault() faltando.

Uma linha.

UMA. LINHA.

Descobri isso 2 semanas depois, quando finalmente parei de refatorar e olhei o erro no console.

TL;DR (Para Refactoring Addicts com déficit de atenção)

Refatorar compulsivamente é procrastinação fantasiada
Código perfeito não existe, código que entrega valor sim
"Já que estou aqui..." é a frase mais perigosa da programação
Overengineering geralmente vem de insegurança
Se funciona e tem testes, deixa quieto
Entregue primeiro, melhore depois
Aquele código "feio" pode estar pagando seu salário há anos

A verdadeira refatoração é interna: aprenda a aceitar que nem tudo precisa ser perfeito.

Sobre o autor: Um desenvolvedor em recuperação que já reescreveu o mesmo sistema 4 vezes "pra ficar melhor". Atualmente em terapia e aprendendo a fazer commits sem incluir 47 arquivos não relacionados. Baby steps.

Dedicado a todos os devs que já perderam um fim de semana inteiro refatorando um projeto pessoal que ninguém usa.

P.S.: Se você chegou até aqui sem pular nada, provavelmente é do tipo que lê documentação completa antes de usar uma lib. Respeito. (Mas você também pode ser um Refactoring Addict em negação.)

#Programação #DevLife #CleanCode #Refactoring #Humor #DesenvolvimentoDeSoftware #CodeQuality #TechDebt