Como Identificar Acoplamento Ruim de Verdade

O problema

Tem código que parece organizado e ainda assim e um inferno para mudar.

Você altera uma regra pequena e descobre que precisa:

• mexer em cinco arquivos
• alinhar tres times
• entender duas exceções historicas
• torcer para nada colateral quebrar

Isso costuma receber vários nomes.

Mas, muitas vezes, o nome certo e acoplamento ruim.

Modelo mental

Acoplamento, por si só, não e defeito.

Todo sistema real tem dependências.

O problema começa quando a dependência fica cara demais.

Pense assim:

acoplamento ruim e o que aumenta demais o custo de entender, mudar, testar ou implantar uma alteracao

Essa definição ajuda mais do que sair procurando teoria abstrata demais.

Quebrando o problema

Olhe para o custo de mudança

Uma pergunta forte e esta:

“Para alterar esse comportamento com segurança, quantas coisas eu preciso conhecer ou coordenar ao mesmo tempo?”

Se a resposta e “coisa demais para uma mudança pequena”, já existe sinal de acoplamento caro.

Procure dependência escondida

Acoplamento ruim muitas vezes não aparece na assinatura da função.

Ele aparece em coisas como:

• flag global
• formato de dado assumido em vários pontos
• ordem implicita de chamadas
• regra compartilhada sem dono claro
• side effect distante

Ou seja, o problema nem sempre e quantidade de imports. As vezes e quantidade de surpresa escondida.

Observe a propagacao do impacto

Mudar campo simples e quebrar tela, job e integração ao mesmo tempo costuma dizer bastante.

Se o impacto se espalha demais para uma mudança modesta, o sistema esta conectando coisas demais ou escondendo fronteiras demais.

Diferencie proximidade útil de mistura ruim

Duas coisas estarem juntas não significa erro.

Se elas mudam pelo mesmo motivo de negócio, certa proximidade pode ser saudavel.

Acoplamento ruim aparece quando partes diferentes passam a exigir mudança conjunta sem uma boa razão clara.

Exemplo simples

Imagine um módulo de checkout onde a validação de cupom:

• decide regra de negócio
• chama gateway externo
• grava analytics
• mexe em estado de UI

No papel, tudo “funciona”.

Na prática, qualquer ajuste em desconto agora exige entender:

• promocao
• integração
• observabilidade
• interface

O problema não e só tamanho.

E mistura de responsabilidades fazendo uma alteracao pequena atravessar fronteiras demais.

Erros comuns

• Chamar de acoplamento ruim qualquer dependência visível.
• Julgar acoplamento só por quantidade de arquivos.
• Criar abstração nova sem provar onde esta o custo real de mudança.
• Ignorar acoplamento operacional entre times e fluxos de deploy.
• Medir design pela elegancia dos nomes em vez do efeito na manutenção.

Como um senior pensa

Quem tem mais experiência costuma usar acoplamento como lente de custo, não como palavra de palestra.

O raciocínio e mais ou menos assim:

“Não me importa só se essas partes conversam. Me importa o que acontece quando eu tento mudar uma delas. Se uma alteracao local exige contexto global, esse acoplamento esta caro demais.”

Essa visão aponta uma refatoração mais útil.

Porque para de discutir beleza e começa a discutir friccao real.

O que o entrevistador quer ver

Em entrevista, esse tema mede maturidade arquitetural.

O avaliador quer ver se você:

• entende acoplamento como custo de mudança
• enxerga dependência escondida
• sabe diferenciar fronteira útil de mistura confusa
• aponta sinais práticos, não só definição de livro

Uma resposta forte costuma soar assim:

“Eu procuro acoplamento ruim observando o custo de uma mudança simples. Se para alterar uma regra local eu preciso entender contexto demais ou tocar partes demais do sistema, esse e um bom sinal de que as fronteiras não estao saudaveis.”

Acoplamento ruim não e o que existe. E o que cobra caro toda vez que você precisa evoluir o sistema.

Quando o impacto se espalha demais, quase sempre a arquitetura esta contando uma história ruim sobre responsabilidade.