Quando Extrair Abstração e Quando Deixar Simples

O problema

Tem um momento bem comum no desenvolvimento:

você ve duas coisas parecidas e pensa:

“Já vou abstrair agora para não repetir.”

As vezes isso ajuda.

Muitas vezes, não.

Porque a abstração chega antes do entendimento.

E quando isso acontece, o time ganha:

• uma camada a mais
• nomes bonitos
• menos clareza
• mais custo para mudar

Modelo mental

Pense assim:

abstrair e comprimir um padrão que já ficou claro o suficiente para merecer uma forma própria

Se o padrão ainda não esta claro, a abstração não comprime entendimento.

Ela comprime dúvida.

E dúvida comprimida costuma voltar em forma de:

• prop opcional demais
• parametro estranho
• condição especial
• API interna confusa

Quebrando o problema

Veja se as partes mudam pelo mesmo motivo

Esse e o teste mais útil.

Se dois trechos parecem parecidos, mas devem evoluir por motivos diferentes, abstrair pode colar coisas que precisavam continuar separadas.

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

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

• criar helper
• nomear helper
• explicar helper
• ajustar helper quando o terceiro caso chegar

Nem toda duplicação merece uma arquitetura em volta.

Prefira simplicidade enquanto o padrão amadurece

Se você ainda esta descobrindo as variações, o código direto muitas vezes ensina mais do que a camada genérica.

Depois que o padrão estiver claro, abstrair fica bem mais fácil.

Abstração boa reduz pergunta

Uma camada boa faz o leitor perguntar menos.

Uma camada ruim faz o leitor perguntar:

• o que isso faz?
• quando não funciona?
• por que esse parametro existe?

Se a abstração aumentou o número de perguntas, ela piorou o código.

Exemplo simples

Imagine tres fluxos que enviam notificação.

Todos parecem ter este formato:

• montar mensagem
• chamar provedor
• registrar resultado

A vontade inicial e criar logo um sendNotification() super genérico.

Mas, olhando melhor:

• um fluxo e marketing
• outro e alerta de segurança
• outro e confirmação operacional

As regras de retry, auditoria e prioridade já sao diferentes.

Nesse momento, talvez o melhor seja deixar mais simples e explícito.

Quando ficar claro o que realmente e comum, ai sim faz sentido extrair a camada certa.

Erros comuns

• Abstrair cedo demais só para cumprir DRY.
• Tratar repetição pequena como pecado maior do que confusao estrutural.
• Juntar comportamentos que mudam por motivos diferentes.
• Criar API genérica demais com parametro, flag e exceção demais.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Essa abstração esta nascendo porque o padrão amadureceu ou porque eu estou desconfortavel vendo repetição?”

Essa diferença importa muito.

Senioridade aqui não e fazer o código parecer mais sofisticado.

E saber quando ainda vale deixar simples.

O que o entrevistador quer ver

Em entrevista, esse tema mede julgamento de design.

O avaliador quer ver se você:

• diferencia repetição aceitavel de acoplamento perigoso
• evita abstração prematura
• pensa em custo de manutenção, não só em elegancia
• sabe defender simplicidade sem parecer improviso

Uma resposta forte costuma soar assim:

“Eu extraio abstração quando o padrão já esta claro e quando a nova camada reduz leitura e manutenção. Se ainda estou descobrindo as variações, prefiro deixar mais simples por um tempo.”

Abstração boa reduz custo. Abstração cedo demais só redistribui confusao.

Tem hora em que o jeito mais senior de escrever código e resistir a vontade de ser esperto cedo demais.