Reuso Sem Complicar

O problema

Reuso de código parece vitoria fácil no começo.

Você ve duas features parecidas e a vontade aparece na hora:

“Já vou juntar isso para não repetir.”

As vezes isso ajuda.

Muitas vezes, não.

Porque reusar cedo demais não elimina custo.

Só muda o lugar onde esse custo vai aparecer.

E ele costuma voltar assim:

• acoplamento escondido
• parametro opcional demais
• comportamento especial
• manutenção mais cara

Modelo mental

Pensa assim:

reuso bom compartilha lógica que pertence ao mesmo problema e muda pelos mesmos motivos.

Esse ponto importa mais do que a semelhanca visual.

Duas funções podem parecer irmas hoje e, ainda assim, pertencer a dominios diferentes.

Antes de extrair uma camada compartilhada, a pergunta mais útil costuma ser:

eu estou removendo duplicação real de dominio ou só colando coisas que hoje parecem parecidas?

Quebrando o problema

Veja se a responsabilidade e realmente a mesma

Esse e o primeiro filtro.

Não basta os dois trechos montarem um objeto parecido ou chamarem a mesma API.

O que importa e:

• eles existem para resolver o mesmo tipo de problema?
• fazem parte do mesmo fluxo de negócio?

Se a resposta for não, o reuso pode virar maquiagem arquitetural.

Veja se vao mudar pelos mesmos motivos

Esse e o teste que mais evita acoplamento ruim.

Quando dois trechos evoluem por motivos diferentes, juntar cedo demais costuma criar uma camada que parece limpa por fora e vira negociação por dentro.

Cada nova diferença entra como:

• flag
• exceção
• parametro
• branch especial

E o que era para simplificar vira centro de confusao.

Compare custo de repetição com custo da camada nova

Um pouco de repetição local pode custar menos do que:

• criar um helper
• nomear um helper
• explicar a abstração
• ensinar quando ela serve ou não

Tem muito caso em que copiar uma função curta e ajustar duas linhas sai mais barato do que obrigar o time inteiro a aprender uma camada nova.

Reuso bom reduz manutenção e pergunta

Uma camada boa deixa o código mais fácil de mudar e de ler.

Uma camada ruim faz o leitor perguntar:

• o que isso cobre de verdade?
• quais casos ficaram de fora?
• por que esse parametro existe?
• quando essa utilidade não deve ser usada?

Se o reuso aumentou o número de perguntas, ele provavelmente piorou o sistema.

Exemplo simples

Imagina dois fluxos de envio de email.

Os dois:

• montam mensagem
• chamam um provedor
• registram log

Parece o mesmo problema.

Mas olhando melhor:

• um envia boas-vindas
• outro dispara alerta crítico de segurança

No papel, os dois sao “envio de email”.

Na prática, podem ter exigencias bem diferentes de:

• prioridade
• retry
• auditoria
• template

Se você junta cedo demais, esconde essas diferencas atras de uma função genérica que vai ficando cheia de condições.

Nesse caso, deixar separado por mais tempo pode ser a decisão mais limpa.

Erros comuns

• Extrair cedo demais só porque duas funções se parecem hoje.
• Compartilhar lógica que logo vai mudar por motivos diferentes.
• Criar uma utilidade “flexivel” que precisa de parametro opcional demais para funcionar.
• Tratar duplicação pequena como pecado maior do que acoplamento estrutural.

Como um senior pensa

Quem tem mais experiência usa reuso com desconfiança saudavel, não por reflexo.

O calculo costuma ser assim:

Se entender essa camada compartilhada custa mais do que copiar e ajustar uma função curta, essa abstração já começou perdendo.

Senioridade aqui não e fazer o código parecer mais elegante no diagrama.

E saber quando o ganho de compartilhamento compensa o custo mental e o acoplamento que ele traz.

O que o entrevistador quer ver

Em entrevista de design, arquitetura ou manutenção de código, esse tema separa bem resposta madura de resposta automática.

O avaliador quer ver se você:

• diferencia semelhanca visual de responsabilidade real
• pensa em motivo de mudança, não só em DRY
• considera custo de leitura e manutenção
• sabe defender duplicação honesta quando ela ainda e a opcao mais barata

Uma resposta forte costuma soar assim:

Eu compartilho lógica quando ela pertence ao mesmo problema e quando espero que continue mudando pelos mesmos motivos. Se hoje os trechos só parecem parecidos, mas a chance de divergirem e alta, prefiro manter separado por mais tempo.

Reuso só vale quando diminui manutenção futura sem multiplicar confusao no presente.