O que Revisão Humana faz?
Para cada alteração, pergunte: qual requisito ela atende, qual comportamento altera e pode um mecanismo existente fazer o trabalho?
Solicitações apenas de revisão não autorizam edições. Siga as convenções do projeto e o escopo do usuário, incluindo limites de teste e publicação.
Rastreie o comportamento
Compare os caminhos de execução antigo e novo, incluindo chamadores e ramos de bypass. Distinga entre passar um objeto, passar uma fábrica e invocá-la. Estabeleça quem possui o estado, quando ele é carregado e quais operações veem uma substituição.
Investigue duplicação aparente antes de removê-la. Qual alteração anterior tornou esta operação necessária? Uma nova implementação pode ter perdido uma verificação implícita de inicialização ou limpeza. Verifique ramos antes de afirmar que o trabalho acontece duas vezes.
Verifique o momento da falha, novas tentativas, limpeza de recursos e se a causa original chega ao usuário. Um erro movido da inicialização para a configuração da conexão pode alterar o comportamento mesmo quando ambos os caminhos eventualmente falham. Verifique consumidores antes de tratar um tipo de exceção interna como requisito de compatibilidade.
Simplifique a camada responsável
Primeiro inspecione o que o componente receptor já suporta. Se seu contrato for suficiente, corrija o que o chamador fornece em vez de adicionar outra responsabilidade ao receptor. Não mova trabalho para um construtor compartilhado apenas para fazer os chamadores parecerem iguais.
Justifique cada operação, campo, ramo ou abstração adicionada pela tarefa atual. Para remoções, verifique chamadores dependentes e garantias. Prefira um contrato compatível existente; mantenha adaptadores que realizam uma conversão significativa ou impõem um contrato.
Acompanhe o estado e o trabalho por todo o caminho afetado. Remover um cache não corrige estado obsoleto se um chamador captura o mesmo valor em um closure. Por outro lado, um provedor dinâmico e um fallback baseado em arquivo podem carregar intencionalmente em momentos diferentes. Unificá-los pode introduzir uma regressão.
Julgue a simplicidade pelos conceitos, proprietários de estado e indireção que um leitor precisa rastrear. Um diff menor nem sempre é um design mais claro. Evite formatação não relacionada e preparação para tarefas futuras.
Teste o requisito
Cada teste deve contar um caso coerente por meio de seu nome, entradas, ações e resultado esperado. Mantenha apenas a configuração e as asserções que estabelecem esse caso. Várias fases pertencem juntas quando a garantia precisa delas, como recuperação após falha; casos não relacionados não pertencem.
Mantenha o menor conjunto que distingue os comportamentos necessários e regressões. Contagens de chamadas internas importam apenas quando expressam um requisito, como carregar uma vez. Confirme que uma falha injetada realmente ocorreu: um timeout ou socket fechado sozinho pode passar pelo motivo errado.
Ordene os testes por comportamento relacionado para que o leitor carregue contexto útil para o próximo. Use nomes concretos em vez de comentários explicativos. Trate um comentário como um incentivo para melhorar o código primeiro; mantenha razões que não podem ser expressas claramente em nomes ou estrutura.
Antes de adicionar uma fixture, espera, asserção ou auxiliar de recurso personalizado, procure por uma estrutura ou facilidade de classe base existente. Prefira código direto. Compartilhe configuração repetitiva quando permanecer compreensível, mas mantenha entradas e ações específicas do cenário visíveis. Evite callbacks, flags ou auxiliares de propósito geral que economizam linhas ocultando o caso.
Sincronize no evento que a asserção precisa, não em um atraso ou em um evento anterior em outra thread. Preserve a limpeza em caso de falha. Leia os testes finais em sequência sem o diff e verifique se seu propósito está claro sem a conversa.
Explique e entregue
Mantenha comentários que explicam uma razão não óbvia e evitam uma simplificação plausível incorreta. Remova narração de operações óbvias. Mantenha contratos de API precisos e instruções do usuário acionáveis; leia as seções editadas sem o diff para verificar se são autossuficientes.
Trate tanto o diagnóstico do usuário quanto sua primeira impressão como hipóteses. Relate descobertas apoiadas com um cenário desencadeador, consequência, evidência e a menor correção útil. Separe defeitos de perguntas abertas e melhorias opcionais. Nenhuma descoberta é um resultado válido.
Para um redesenho substancial, explique uma execução concreta, o que se torna mais simples e o custo comportamental ou de compatibilidade. Resolva escolhas fora do escopo acordado com o usuário; continue correções autorizadas de rotina sem outra aprovação.
Após correções, leia o fluxo completo afetado e o diff final. Relate conclusões, verificações executadas e lacunas restantes, em vez de narrar uma pergunta para cada linha.