Reveja código gerado por IA

Leia o requisito antes do resumo

Comece pelo comportamento pedido e pelos critérios de aceitação. Inspecione depois o diff real. O resumo de um agente pode ajudar a orientar a leitura, mas pode omitir alterações ou descrever as verificações de forma incorreta.

Confirme o branch e o commit em revisão. Além do código da aplicação, verifique alterações à configuração, às dependências, à infraestrutura e aos testes. Uma pequena funcionalidade visível pode incluir uma grande alteração às permissões ou ao comportamento do deployment.

Reveja primeiro o comportamento com consequências mais graves. A formatação e os nomes importam, mas não devem desviar a atenção de um limite de dados em falta.

Siga a identidade até ao recurso

Considere este endpoint fictício e incompleto. O exemplo ilustra um problema de revisão; não é código de produção.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

A função obtém um utilizador autenticado. Não mostra uma decisão de autorização para a fatura. O revisor tem de inspecionar se outra camada impõe essa decisão. O valor de utilizador não usado é uma razão para investigar, não uma prova, por si só, de um defeito explorável.

Siga o pedido pelo sistema real. Identifique o utilizador e a organização de confiança. Verifique como a consulta limita o acesso ao registo pedido. Inspecione o comportamento em caso de erro e os testes para pedidos proibidos.

Não assuma que um botão oculto protege a API. Quem chama a API pode enviar um pedido sem usar a interface. Não assuma que um ID de registo válido concede acesso.

Pergunte que provas poderiam rejeitar a alteração

Um teste que passa pode usar uma fixture de administrador ou um mock de autorização. Verifique se exercita o limite importante. Quando for adequado, acrescente um caso com outra organização e um percurso de autorização real.

Numa alteração de interface, inspecione o resultado apresentado. Verifique a utilização com teclado, os estados vazios, o carregamento e os erros. Uma verificação de tipos não demonstra que uma caixa de diálogo é utilizável com teclado.

Numa alteração de dependência, confirme por que é necessária. Reveja a versão, a licença e os resultados da análise de segurança. Não aceite uma atualização sem relação com a tarefa só porque o agente a gerou durante o trabalho.

Mantenha a revisão independente

Um segundo modelo pode identificar problemas relevantes. Também pode repetir pressupostos da implementação. Forneça ao revisor o requisito e o diff. Evite dizer-lhe que a alteração já está correta.

Exija que as observações identifiquem um percurso de falha concreto e o código relevante. Trate avisos sem fundamento como perguntas a investigar. Trate uma aprovação confiante como mais uma opinião até existirem provas das afirmações importantes.

A revisão humana continua a ser uma decisão de responsabilidade. O revisor deve compreender o suficiente da alteração para explicar o comportamento, os riscos e a verificação. Se o diff for demasiado grande, reduza o âmbito ou divida-o em alterações que possam ser revistas.

Conclua a revisão sobre a versão final do código

Após uma correção, repita as verificações afetadas. Inspecione se a correção cria um novo problema. Garanta que a revisão exigida se aplica à versão final do código, de acordo com a política do repositório.

Escreva a decisão de aceitação em termos de comportamento e provas. Registe qualquer limitação restante com um responsável e uma ação seguinte. Não transforme uma questão por resolver numa afirmação de que todas as verificações passaram.

Use o exercício de revisão de código para praticar a identificação da decisão em falta antes de examinar uma alteração real.