Aprendendo revisão de código com as guidelines do Google
Um guia para melhorar a performance do seu time através de melhoria contínua
O que veremos?
- O que é afinal um Code Review?
- Para que serve o Code Review?
- Princípios de um bom Code Review
- Quais os principais pontos devo buscar no code review?
- Quais são as etapas básicas?
- Velocidade é importante!
- Discutir também!
- Papel de quem está escrevendo um PR
- Como lidar com os comentários do revisor
Mobile Engineer @ Sanar
lucianomlima
@lucianomlima
-
Startup nas áreas de saúde e educação.
-
Temos como objetivo empoderar os profissionais da saúde
-
Mais de 250 funcionários
-
Escritórios em Salvador e São Paulo
-
Temos desenvolvedores trabalhando remotamente em todo o país
-
Muuuuitas vagas abertas
O que é um Code Review
"É o processo onde alguém, diferente do autor do código, examina o código."
Para que serve?
Manter a qualidade do código e dos produtos
Garantir que todo o código se mantém saudável e em constante melhoria ao longo do tempo
Ajuda no compartilhamento de conhecimento entre o time
Toda a discussão envolvida pode ser utilizada como documentação das decisões tomadas
Princípios
Dados e fatos técnicos tem maior relevância sobre opiniões e preferências pessoais
Style Guide é autoridade absoluta – consistência por todo o projeto
Design de Software deve ser baseado em dados ou em princípios sólidos de engenharia
Caso não tenha um padrão estabelecido, deve-se seguir o aplicado atualmente
Objetivos
Desenvolvedores precisam ter progresso em suas atividades
Quem revisa precisa garantir que a qualidade do código não vai cair ao longo do tempo
O código não precisa estar perfeito!
"If you never submit an improvement to a codebase, then the codebase never improves"
Se o revisor impedir que as mudanças ocorram, isso pode gerar uma falta de incentivo à mudanças no futuro
Objetivos
Código fonte tende a se degradar ao longo do tempo, principalmente quando há restrições de tempo
Se algo relacionado à atividade pode ser melhorada, é obrigação de quem revisar comentar sobre a melhoria
Ao invés de buscar perfeição, devemos buscar melhoria contínua.
Quem revisa deve ter liberdade para comentar sobre o que pode ser melhorado
Principal regra
"Em geral, revisores devem favorecer a aprovação de um código assim que ele chegar em um estado onde definitivamente melhore a integridade do código como um todo, mesmo que a mudança não esteja perfeita"
Resolvendo conflitos 🤝
Desenvolvedor e revisor devem tentar entrar em consenso sobre algum conflito
Não deve-se esperar que algum conflito seja resolvido apenas através de comentários
As vezes é necessário discutir com todo o time, pedir por uma opinião de algum gerente ou pedir pela ajuda de alguém mais experiente no assunto
Principais pontos
Design
Funcionalidade
Complexidade
Testes
Nomenclatura
Principais pontos
Comentários
Estilização (style guide)
Documentação
Contexto
Encorajamento
Etapas básicas
1 - Tenha uma visão geral do código
2 - Revise as partes principais
3 - Dê uma olhada no restante
Velocidade é importante! ⚡️
Por que code reviews precisam ser rápidos?
O quão rápido precisam ser?
Velocidade vs Interrupção
Respostas rápidas
Velocidade é importante! ⚡️
Aprovação com ressalvas (LGTM)
Pull Requests longos
Code review fica mais rápido com o tempo
Em caso de emergência...
Discutir também!
Seja claro e útil com quem você está revisando.
Faça comentários sobre o código, não sobre o autor do mesmo
Explique o porquê, dê exemplos
É responsabilidade do autor corrigir os problemas, não do revisor.
Discutir também!
Mas você como revisor deve ajudar chegar a solução do problema
Se for necessário pedir uma explicação sobre o código, está é uma oportunidade de escrever o mesmo de uma forma mais clara
Nem sempre sua sugestão vai ser aceita
Defenda sua opinião, mas com argumentos
Discutir também!
O autor ficar chateado com a insistência do revisor pode ser indício de que o comentário não foi feito de forma educada
Deixar a limpeza para depois é uma das principais formas de criar débitos técnicos. Sempre que possível, peça pela limpeza o quanto antes
Revisões rigorosas geram mais reclamações, com o tempo o rigor é bem visto pelo time
Papel de quem escreve
➣ Descreva bem seu PR
- Descreva brevemente o objetivo do PR
- Use o corpo do PR para explicar o problema e qual a solução escolhida
- Evite descrições genéricas
"Fix build" "Add patch" "Remove code"
- Revise seu próprio PR
Papel de quem escreve
➣ Crie PR pequenos
- Revisões mais rápidas
- Revisões mais detalhadas/objetivas
- Menor chance de deixar passar bugs
- Menos tempo será desperdiçado
Papel de quem escreve
➣ Crie PR pequenos
- Mais simples para integrar
- Mais simples de manter o padrão
- Menos rodadas de revisão
- Mais simples para desfazer em caso de problemas inesperados
Papel de quem escreve
➣ Quando um PR é pequeno?
➣ Quando um PR grande é permitido?
➣ Divida por agrupamento
➣ Isole PR de refatoração
Papel de quem escreve
➣ Evite separar testes relacionados ao código do PR
➣ Não permita que seu código quebre o build
➣ Antes de enviar um PR grande, discuta com seu time
Lidando com os comentários
➣ Não leve para o lado pessoal
- Não responda de forma agressiva
- Peça uma revisão educada e útil
- Pense na crítica ao código como uma tentativa de ajuda a você e ao projeto, não um ataque pessoal a você ou suas habilidades
Lidando com os comentários
➣ Corrija o que estiver errado
- Tente deixar seu código mais claro
- Comentário no código pode ajudar, mas evite
- Sempre pense nos futuros desenvolvedores que podem ter dificuldade em entender seu código
Lidando com os comentários
➣ Pense de forma independente
- A revisão está de fato apontando uma melhoria no seu código?
- O comentário do revisor está claro?
- Sua implementação está correta?
Então explique com mais detalhes
- Sugestões são sempre sugestões
Resumo 🖊
Está descrito de forma clara o objetivo do PR?
A qualidade e saúde foi mantida no PR?
A solução está com um bom design?
O código está simples? Outro desenvolvedor consegue entender sem dificuldades?
O código atende ao que foi solicitado?
Resumo 🖊
A nomenclatura utilizada está correta?
Os comentários são de fato úteis e claros?
O código está seguindo o style guide?
A documentação foi devidamente atualizada?
O código está coberto por testes?
Dicas finais
Quando possível, escolha os melhores revisores
Caso queira uma outra opinião, marque a pessoa no seu PR
Programação em par pode servir como um code-review