Skip to content

Instantly share code, notes, and snippets.

@airton
Created June 9, 2017 22:22
Show Gist options
  • Save airton/3df2ee9a6f43ecd119061353e2fe3700 to your computer and use it in GitHub Desktop.
Save airton/3df2ee9a6f43ecd119061353e2fe3700 to your computer and use it in GitHub Desktop.
Code Review

###Code Review

É uma técnica onde o desenvolvedor tem seu código revisado por outro desenvolvedor antes de commitar o código.

O commitador deve explicar cada arquivo que está sendo commitado, tanto do ponto de vista técnico quanto de negócio.

Cada trecho de código apontado como alteração pelo "diff" deve ser devidamente explicado ao revisor.

É papel do revisor questionar sobre o código, sugerir melhorias e exigir detalhes sobre a regra de negócio.

É papel do commiter saber explicar seu código bem como a regra de negócio; escutar as sugestões do revisor e aplicá-las SEMPRE que possível.

Q: Parar dois profissionais não seria ineficiente?

A curto prazo, o code review pode ser visto como perda de tempo, porém a médio prazo os ganhos superam as desvatagens. Com o passar do tempo, e conforme os devs vão se habituando a fazer o code review, o processo passa a ser parte do dia a dia de todos, levando cada vez menos tempo para ser concluido.

Também sugere-se que os commits não sejam muito grandes, pois dificultará a explicação e compreensão dos envolvidos. Commits longos devem ser feitos SOMENTE se estritamente necessários, como alterações no core da aplicação

###Objetivo

  • Funciona como um pré teste
  • Filtrar erros superficiais, potencialmente graves
  • Previnir quebra do build
  • Aumentar a capacitação dos desenvolvedores
  • Procedimento informal de qualidade ainda na fase de desenvolvimento

###Vantagens

  • Aumento de produtividade: menos problemas
  • Sem custo adicional para a empresa
  • Compartilhar conhecimento técnico
  • Compartilhar conhecimento do produto
  • Self improvement: Você acaba identificando deficiências enquanto explica seu próprio código

###Como funciona

  • O commiter deve solicitar a alguem que revise seu código
  • Ele deve dar uma visão geral sobre do que se trata esse commit. Que problema está sendo resolvido, etc;
  • O review não costuma demorar mais do que 15 minutos. Se esse tempo for ultrapassado, o commit pode estar muito grande. Nesse caso, esse hábito precisa ser evitado;
  • O revisor deve se empenhar em tirar dúvidas, fazer sugestões, se relevante, e entender o motivo da alteração;
  • O commiter deve se preocupar em descrever o que a mudança está resolvendo, estar aberto para receber sugestões e apto a avaliar se as sugestões são de fato relevantes
  • Em caso de discórdia, os envolvidos devem entrar em concenso, mesmo que seja necessário uma segunda etapa futura, para resolver pendÊncias do commit atual
  • Opcionalmente, adicionar o nome do revisor no comentário do commit

###O que sugerir

  • uso correto de APIs;
  • coerência com melhores práticas;
  • coerência com convenção de desenvolvimento;

###O que não sugerir

  • Alternativa da solução de negócio;
  • Opinião sobre o problema;
  • Opinião sobre a forma que o indivíduo trabalha;

###Como aderir sem traumas

  • O commiter deve escolher uma pessoa conhecida para revisar o código, para facilitar a comunicação
  • Ambos devem estipular um tempo médio de 15 a 20 minutos. Tempo razoável para esclarecimento de dúvidas
  • O code review deve ser acompanhado por uma pessoa familiarizada com o processo para dar orientações
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment