MENLO PARK, Califórnia — Os assistentes de programação ficaram bons em produzir código que parece certo. A pergunta mais difícil para o desenvolvedor que precisa fazer o merge é se alguém conferiu. O Remy, agente de programação da Corepass, responde com o que equivale a uma trilha de evidências: um registro das verificações que executou, do que mudou quando uma delas falhou e um relato explícito do que não verificou.
Esse comportamento, descrito na página do produto do Remy, segue uma ordem fixa. Depois de alterar o código, o Remy executa os testes, a checagem de tipos ou o build pertinentes. Se algo falhar, ele procura a causa, corrige e executa de novo a mesma verificação — não outra, diferente e mais fácil. A página do produto descreve o último passo sem rodeios: “Depois, ele diz o que foi executado, qual foi o resultado e o que não verificou.”
- Executar verificaçõesTestes, checagem de tipos ou o build
- Encontrar a causaQuando uma verificação falha
- Corrigir e repetirA mesma verificação, outra vez
- RelatarO que foi executado, qual foi o resultado, o que não foi verificado
A verificação que falhou é a que roda de novo
Por que repetir a mesma verificação importa
A insistência em executar de novo a verificação idêntica é o ponto central. Uma correção seguida de um teste diferente, ou de nenhum teste, deixa em aberto se a falha original desapareceu. Repetir a verificação que falhou liga a correção à evidência de que ela funcionou e coloca essa evidência onde o revisor pode vê-la.
“Depois, ele diz o que foi executado, qual foi o resultado e o que não verificou.”
Dizer o que não foi verificado
A última parte do relatório talvez seja a menos comum entre as ferramentas de programação. A nota final do Remy separa o que foi verificado do que não foi; na própria demonstração do produto, uma tarefa termina com duas listas, uma intitulada “Verificado” e outra “Não verificado”. Uma mudança em código que nenhum teste cobre, por exemplo, seria apontada como não verificada em vez de ser ignorada.
Revisão antes do merge
A verificação é uma camada. A documentação do Remy descreve um modo separado de revisão de código que relata os achados por gravidade, cada um com sua localização, seu impacto e a evidência que o sustenta. No fluxo de trabalho da página do produto, um bot de revisão, o Bugbot, lê o diff e procura o que os testes deixaram passar antes de o pull request sair.
A Corepass inclui “Manter o trabalho revisável” entre os princípios com que constrói, e o relatório de verificação é a expressão mais clara disso no produto: o agente faz as verificações, e o desenvolvedor recebe o registro de que precisa para decidir se faz o merge.