Trilha 02Lição 4 / 6

Revise código gerado por IA

Inspecione a alteração real, seus limites de confiança e suas evidências antes de aceitá-la.

Prática12 minRevisado

Publicado por Como escrevemos

Confira seu entendimentoUm endpoint verifica se o usuário está autenticado e depois carrega um registro pelo ID fornecido na requisição. O que você deve verificar?Faça o exercício
Um endpoint verifica se o usuário está autenticado e depois carrega um registro pelo ID fornecido na requisição. O que você deve verificar?

O que você vai aprender

  • Revisar o comportamento e a autoridade antes do estilo.
  • Identificar uma verificação de autorização ausente em um exemplo pequeno.
  • Separar um resumo gerado de evidências verificadas.

Leia o requisito antes do resumo

Comece pelo comportamento solicitado e pelos critérios de aceitação. Depois, inspecione o diff real. O resumo de um agente pode ajudar na navegação, mas pode omitir alterações ou descrever verificações de forma imprecisa.

Confirme a branch e o commit em revisão. Verifique alterações de configuração, dependências, infraestrutura e testes, além do código da aplicação. Uma funcionalidade visualmente pequena pode incluir uma grande mudança nas permissões ou no comportamento de deployment.

Revise primeiro o comportamento com consequências mais graves. Formatação e nomes importam, mas não devem desviar a atenção de um limite de dados ausente.

Rastreie a identidade até o 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 usuário autenticado. Ela não mostra uma decisão de autorização para a fatura. O revisor deve inspecionar se outra camada impõe essa decisão. O valor de usuário não utilizado é motivo para investigar, não prova isolada de um defeito explorável.

Rastreie a requisição no sistema real. Identifique o usuário e a organização a partir de fontes confiáveis. Verifique como a consulta limita o acesso ao registro solicitado. Inspecione o comportamento de erro e os testes de requisições proibidas.

Não presuma que um botão oculto protege a API. Quem faz uma chamada pode enviar uma requisição sem usar a interface. Não presuma que um ID válido de registro concede acesso.

Pergunte quais evidências poderiam rejeitar a alteração

Um teste que passa pode usar uma fixture de administrador ou um mock de autorização. Verifique se ele exercita o limite importante. Acrescente um caso com outra organização e um caminho real de autorização quando for adequado.

Para uma alteração de interface, inspecione o resultado renderizado. Verifique o uso por teclado, os estados vazios, o comportamento de carregamento e os erros. Uma verificação de tipos não comprova que um diálogo é utilizável pelo teclado.

Para uma alteração de dependência, verifique por que ela é necessária. Revise a versão, a licença e os achados de segurança. Não aceite uma atualização sem relação com a tarefa apenas porque o agente a gerou durante o trabalho.

Mantenha a revisão independente

Um segundo modelo pode identificar problemas úteis. Também pode repetir premissas da implementação. Dê ao revisor o requisito e o diff. Evite dizer que a alteração já está correta.

Exija que os achados identifiquem um caminho concreto de falha e o código relevante. Trate alertas sem fundamento como perguntas a investigar. Trate uma aprovação confiante como outra opinião até que as afirmações importantes tenham evidências.

A revisão humana continua sendo uma decisão de responsabilidade. O revisor deve entender a alteração o suficiente para explicar seu comportamento, riscos e verificação. Se o diff for grande demais, reduza o escopo ou divida-o em alterações que possam ser revisadas.

Conclua a revisão na versão final

Após uma correção, execute novamente as verificações afetadas. Inspecione se a correção cria um novo problema. Garanta que a revisão exigida se aplique à versão final conforme a política do repositório.

Registre a decisão de aceitação em termos de comportamento e evidências. Registre qualquer limitação restante com um responsável e uma próxima ação. Não transforme uma questão não resolvida em uma 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 ausente antes de examinar uma alteração real.

Faça o exercício

Abra o exercício de revisão de código no laboratório prático. Identifique quem faz a requisição, o recurso solicitado e o limite confiável da organização. Depois, inspecione um PR real pequeno com o mesmo método. Use apenas código que você tenha autorização para revisar.

Baixar planilha de exercício (Markdown)
Confira seu entendimento ↑

Continuar aprendendo

Fontes e leituras adicionais

Leituras relacionadas da Taiga

← Lição anterior: Use testes como evidência