Ideia principal

Fazer merge de um código que nenhum integrante do time saberia explicar não é uma negligência de revisão: é um empréstimo. O time recebe a funcionalidade na hora e se compromete a pagar depois, em incapacidade de diagnóstico — no momento em que for preciso alterar, proteger ou retomar esse código sem saber por que ele foi escrito assim.

O passivo fica invisível enquanto nada quebra: a aplicação roda, as telas respondem, os testes passam. Dezenas de pull requests abertas durante a noite por um assistente e integradas sem que ninguém tenha verificado os impactos parecem adiantamento; são juros correndo.

Daí uma regra de merge simples, quase brutal: não integrar código que ninguém consegue explicar. Ela não pede uma documentação interminável — um pequeno orçamento de compreensão por funcionalidade basta: o contrato, os testes, a decisão de arquitetura, os limites conhecidos. O suficiente para que o raciocínio continue transmissível entre pessoas.

Por que isso importa

Isso devolve um preço imediato à incompreensão, no lugar e no momento em que a decisão é tomada. Enquanto o custo fica adiado, cada integração isolada parece razoável, e o passivo se acumula sem que nenhuma arbitragem o tenha aceitado.

Também dá um critério de revisão que não depende do nível técnico de quem revisa: a pergunta não é "esse código é bom?", mas "alguém aqui sabe dizer por que ele é assim?".

Nuances e limites

A regra esbarra numa zona cinzenta: explicar em que nível? Ninguém explica linha a linha o código de uma biblioteca de terceiros, e um time que exigisse esse grau em tudo não integraria mais nada. O objeto da explicação é a intenção e as fronteiras, não cada instrução.

E ela só vale se alguém tiver autoridade para bloquear uma integração. Num time em que o prazo manda, ela vira uma formalidade declarativa, e a explicação se reduz à caixinha marcada.

Questões em aberto

• Sobre que perímetro a explicação deve incidir — a funcionalidade, o módulo, a linha — para que a regra continue aplicável sem virar ritual?