Em muitos anos escrevendo e revisando código, aprendi alguns segredos para criar pull requests melhores e revisar o código com mais eficiência.
Coloquei todos esses segredos em meu novo livro Pull Requests and Code Review , mas você encontrará aqui uma prévia com essas 13 dicas, que você já pode usar em sua atividade de desenvolvedor.
Você consegue pensar em mais dicas? Compartilhe-os nos comentários 😉
Um rascunho de RP ajuda você a organizar suas ideias e documentar seu progresso, enquanto você ainda trabalha em seu recurso.
A melhor maneira de obter uma revisão rápida e eficiente é manter seu PR pequeno e bem documentado (com todo o contexto necessário). Você também aumentará suas chances de futuros PRs entregando ótimos códigos agora!
Encontre todas essas dicas e muito mais, com mais exemplos da vida real e insights acionáveis em meu livro gratuito Pull Requests and Code Review: Best Practices for Developers, from Junior to Team Lead .
Coloque-se no lugar do seu revisor, antecipe as perguntas e comente seu próprio código quando achar que isso pode ajudá-lo.
Não atribua seu PR ao mundo inteiro. Escolha seus revisores com cuidado para obter uma revisão relevante, sem esperar muito pela aprovação.
Esteja aberto a comentários, peça esclarecimentos, diga quando discordar (com respeito) e sempre responda aos comentários.
Todo mundo tem muitos PRs para revisar e pouco tempo livre para isso. Se você revisar outros PRs, aumentará as chances de que o seu também seja revisado.
Como desenvolvedor júnior, você pode informar outras pessoas quando não entender parte do código, pois isso deve ser compreensível para qualquer desenvolvedor da equipe.
Mais sobre isso em minha postagem Como fazer revisão de código como desenvolvedor júnior? .
O objetivo da revisão de código é verificar bugs e casos extremos e desafiar a implementação. Ele não deve ser usado para criticar pequenas preferências de formatação ou estilo, nem para discussões arquitetônicas em larga escala.
Use “por que não” em vez de “você deveria”, seja aberto e positivo e sempre sugira uma alternativa quando pedir uma mudança.
Nem todos os comentários exigem alterações e nem todas as alterações solicitadas são necessárias para que o PR seja aprovado. Seja claro em seu comentário se a mudança não for urgente.
Antes de tornar sua avaliação pública, releia cada comentário: verifique o tom que você usa e certifique-se de fornecer todo o contexto para ajudar o remetente do PR.
Você não quer que o revisor espere pela sua aprovação dois dias depois de fazer todas as alterações solicitadas. Ao revisá-lo, presuma que você o aprovará assim que todas as correções forem feitas.
Quando um tópico de comentário se torna um debate em seu PR, é melhor interrompê-lo e sugerir continuar a discussão em outro lugar, por exemplo, em um tópico do Slack. Se necessário, dedique uma reunião a isso e/ou envolva terceiros.
É isso! O que você achou dessas dicas? Você consegue pensar em uma dica que gostaria de dar a outros desenvolvedores?
Compartilhe-os aqui nos comentários 👇
Se você gostou dessas dicas e quer aprender um pouco mais, confira meu livro Pull Requests and Code Review , é grátis!
Também publicado aqui .