Ideia principal

Falamos muitas vezes das boas práticas de software como de um estoque estável: bastaria documentá-las, colocá-las no arquivo de diretrizes de um assistente de desenvolvimento e pedir a ele que as aplicasse.

A história delas diz outra coisa. Os design patterns clássicos respondiam a um mundo de software específico; a nuvem, os sistemas distribuídos, o assíncrono, os microsserviços e as arquiteturas orientadas a eventos fizeram aparecer outro, e foi preciso inventar a idempotência, os retries, os circuit breakers, as sagas, a observabilidade, a resiliência distribuída. Nenhuma dessas práticas saiu de uma releitura das anteriores: elas nasceram de sistemas reais, de panes, de migrações difíceis, de restrições de operação e de acordos dolorosos.

Para inventar uma boa prática, conhecer as antigas não basta, portanto. É preciso sentir por que elas não bastam mais, o que supõe ter sido exposto a um campo que resiste — e saber distinguir o momento em que um pattern é uma resposta elegante daquele em que ele é só complexidade inútil.

Por que isso importa

Isso separa duas capacidades que confundimos assim que uma ferramenta sabe recitar o catálogo: aplicar uma prática e produzir uma nova. Um assistente que compara soluções, identifica recorrências e documenta práticas emergentes ajuda na primeira; nada estabelece que ele cubra a segunda antes que o campo tenha tornado a necessidade legível.

Isso também quantifica um custo invisível para um time que não enfrenta mais diretamente a operação: ele herda os patterns existentes e perde o mecanismo que permitia inventar outros — uma perda que só se constata na geração tecnológica seguinte.

Nuances e limites

O campo não precisa ser vivido em primeira pessoa para ensinar: um post-mortem sério, um rastro de operação, o incidente público de outra empresa transportam uma parte da resistência. O que eles transmitem com certeza é o pattern já encontrado; a capacidade deles de fazer emergir o próximo ainda está por demonstrar.

E nem toda resistência produz prática: muitos incidentes deixam só uma correção local, porque ninguém tomou o tempo de tirar dali uma regra.

Questões em aberto

• O que, numa pane, faz com que ela gere uma prática reutilizável em vez de uma correção esquecida no mês seguinte?