Ideia principal

Um mesmo objeto é descrito em quatro lugares de um produto, e cada um diz o que os outros calam. O núcleo do código carrega as regras — o que é proibido, o que é obrigatório, o que dispara o quê. O banco de dados carrega os campos, a unicidade, o que não pode ficar vazio. As telas carregam as validações de formulário, os campos condicionais, os botões desabilitados, as listas de opções. As traduções carregam as palavras realmente exibidas ao usuário, em todos os idiomas.

Uma regra pode perfeitamente existir em apenas um desses quatro lugares. Ler o núcleo do código e parar por aí — o reflexo mais natural, tanto de um desenvolvedor quanto de um agente — deixa sair, portanto, uma descrição que parece completa e não é.

Uma ordem de leitura se impõe: as telas depois do código, e antes de encerrar o assunto. A comparação é feita objeto por objeto, nunca pasta por pasta, porque o recorte da interface não coincide com o do servidor.

Por que isso importa

É uma condição de conclusão oponível: "essa parte está pronta" vira algo verificável linha a linha, uma parte e um lugar por linha, em vez de declarado. Um acompanhamento nessa granularidade sobrevive à interrupção do trabalho e evita refazer duas vezes a mesma leitura.

E é isso que coloca as quatro fontes frente a frente, portanto o que torna visíveis suas contradições.

Nuances e limites

O critério mede a profundidade, nunca a largura. Dá para ter lido os quatro lugares em uma minoria das partes do produto e ignorar todo o resto — caso em que a regra está perfeitamente respeitada e o trabalho, muito incompleto.

O número quatro não é uma lei: ele corresponde aos lugares onde aquele produto deposita informação. Uma arquitetura diferente — mensagens trocadas entre serviços, motor de regras externalizado — acrescentaria outros.

Questões em aberto

• Como reconhecer, em uma arquitetura desconhecida, a lista dos lugares onde a informação se deposita, antes de ter começado a lê-los?