Ideia principal

Como se escreve uma API neste time? Como tratamos os erros? Como escrevemos um job assíncrono? Como testamos uma chamada a um serviço externo? Enquanto essas respostas ficarem implícitas, elas serão reconstituídas a cada vez — e um assistente de desenvolvimento, que não tem motivo nenhum para preferir a convenção local a outra qualquer, propõe uma diferente a cada funcionalidade.

O resultado não é uma falha de qualidade funcionalidade por funcionalidade: cada solução pode estar correta isoladamente. O resultado é um time que mantém várias arquiteturas dentro de um único produto, sem que nenhuma decisão tenha assumido essa pluralidade.

O que falta é um catálogo dos patterns autorizados, decidido pelo time e escrito. Decidido, porque um inventário do que o código já contém apenas ratifica a dispersão; escrito, porque a convenção não formulada não se transmite nem a quem chega nem a uma ferramenta.

Por que isso importa

Isso desloca o alvo do esforço de homogeneidade: a revisão caso a caso não alcança uma vazão de geração, um referencial a montante alcança.

Também revela um custo que a aceleração esconde. A lentidão impunha uma homogeneidade de fato — reinventar a cada vez custava caro demais, então copiávamos o módulo ao lado. Esse freio cai quando produzir não custa mais nada, e nada o substitui enquanto a convenção não virar decisão.

Nuances e limites

Um catálogo grande demais vira estorvo: ele congela escolhas que o contexto deveria poder reabrir, e acaba ignorado porque ninguém o mantém atualizado. O valor dele está na pequena lista de perguntas recorrentes, não na exaustividade.

E a homogeneidade não é um fim. Num perímetro exploratório, deixar várias maneiras de fazer conviverem por um tempo é um meio legítimo de comparar — desde que a escolha depois seja decidida e registrada.

Questões em aberto

• Quem arbitra a entrada de um novo pattern no catálogo, e a que sinal um time reconhece que uma entrada existente deixou de servir?