Design Patterns: Pare de Paranoia para Código Perfeito (Parte 9)

Contexto

Estou nesta série escrevendo sobre padrões de projeto, sobre como você pode melhorar a escrita e a manutenção da base de código etc. Mas senti a necessidade de fazer uma pausa e falar da paranoia que todo programador já sofreu ou sofre: a busca pelo código perfeito.

Se você leu a Parte 1, já sabe: pattern é catálogo, não religião. Aqui o foco é outro: o problema aparece primeiro; o padrão vem depois, quando fizer sentido.

A paranoia do “código perfeito”

É comum confundir maturidade técnica com uma postura defensiva: antecipar todos os futuros possíveis, criar camadas e factories “por precaução”, sentir culpa por código simples. Isso não é disciplina; muitas vezes é medo. E medo costuma gerar complexidade acidental: você paga custo hoje para um “talvez” que nunca chega.

Primeiro o problema, depois o padrão

Um fluxo pragmático (e saudável) costuma seguir mais ou menos esta ordem: primeiro você faz funcionar com clareza, mesmo que simples. Depois você observa dor real — mudança frequente, bugs recorrentes, testes impossíveis, acoplamento incômodo. A partir daí você refatora guiado por sintoma, melhorando nomes, extraindo responsabilidades e desenhando limites. Só então faz sentido “nomear” o que nasceu: “isso aqui virou Strategy”, “isso aqui pede Adapter”, e assim por diante.

O ponto é que o padrão vira consequência de um problema que você sentiu, não um troféu que você precisa conquistar no dia 1.

Um exemplo bobo em código

Imagine um relatório que começa trivial:

<?php

function reportTotalSalesForLastMonth(): float
{
    // consulta SQL direta, retorna soma
    return 1234.56;
}

Explicação: para um MVP, isso pode ser perfeito: entrega valor, é testável o suficiente se você extrair o acesso a dados, e todo mundo entende.

Agora suponha que a dor real apareceu: 5 formatos diferentes de relatório, regras diferentes por cliente, e o método virou um monstro. Aí sim faz sentido evoluir para composição (por exemplo, Strategy para cálculo/agregação + Template Method para pipeline de exportação, dependendo do caso).

O ponto não é “Strategy desde o dia zero”. O ponto é: deixe a complexidade nascer onde ela existe.

Sinais de que você está antecipando demais

Alguns sinais aparecem cedo: você cria interfaces quando ainda não existem dois comportamentos reais, adiciona camadas porque “um dia pode precisar” e refatora sem falha observável (teste quebrando, feature lenta, bug, medo legítimo de mudança).

Sinais de que você não está antecipando demais

Por outro lado, às vezes o “peso” é justificável: o domínio já tem variações reais e está te cobrando, integrações externas estão sugando tempo com mudanças e o time não consegue evoluir sem medo.

Conclusão

Padrões são ferramentas de comunicação e manutenção. Eles brilham quando ancorados em problema real.