Master the Code Review 📈

Master the Code Review

  • Crie um processo melhor ✅
  • Faça melhores Code Reviews 🔎
  • Escreva um código melhor ⭐

Why?

Why?

1.  Crie um processo melhor: para ajudar seu time a entregar um software melhor e mais rápido. 

2. 📈Faça melhores code reviews: que impulsionam a qualidade do código e eleva as skills de seus colegas.

3. Escreva um código melhor: em que é aprovado na primeira review.

Termos - Code Review

Google guidelines - Como realizar uma code review

https://google.github.io/eng-practices/review/reviewer/comments.html#courtesy

Plano de carreira - Dropbox

https://dropbox.github.io/dbx-career-framework/ic2_software_engineer.html

Plano de carreira - Dropbox

1. Crie um processo melhor para a revisão de código

Capacite seu time a entregar um software de alta qualidade, mais rápido

Tópicos

  • Por que meu time realiza code reviews?
  • Sinais de um processo de code review irregular 🚩
  • Como funciona um bom processo de code review 🚢

Por que meu time realiza code reviews?

  • 😞 Erros
  • 👥 Responsabilidade distribuída
  • 👍 Colaboração
  • 📋 Ensino

Sinais de um processo de code review irregular 🚩

💬 "LGTM! 👍" [3 segundos depois]

💬 "Esse código é horrível. Não tem como realizarmos a manutenção do que você escreveu."

 

💬 "Esse método é ilegível, nós devemos refatorar ele."

Sinais de um processo de code review irregular 🚩

  • Você não tem um processo de code review
  • Você tem uma lista grande de pequenos bugs
  • Raramente tem comentários em code reviews
  • Faz você se tornar ansioso
  • É comum 1 PR passar por muitos ciclos de revisão (7+)
  • Longas discussões; vai e volta;
  • Code reviews são bloqueadas por coisas minuciosas (exemplo estilo de código)

Sinais de um processo de code review incorreto 🚩

  • PR precisa ser pequena!
    • Mais fácil de revisar
    • Menos risco
    • Tempo efetivo para o autor

Como funciona um bom processo de code review 🚢

Sinais de um processo de code 

  • PR precisa ter o escopo adequado
    • Funcional; Incluir testes
    • Passar na build
    • Pode ser realizado o deploy e o roll back de forma segura

🚢 Boas code reviews - expectativas para um autor de PR

Sinais de um processo de code 

  • Incluir o que aquela PR resolve.
  • Incluir o motivo na descrição da PR.
  • Extras, se necessário
    • Tarefas relacionadas
    • Cobertura de testes
    • Print de telas
    • Rollback de forma segura

🚢 Boas code reviews - expectativas para um autor de PR

Sinais de um processo de code 

  • Marcar o revisor "correto"
  • Impulsionar a resolução de conflitos
  • Impulsionar a escrever um código melhor

🚢 Boas code reviews - expectativas para um autor de PR

Sinais de um processo de code 

  • Ser gentil
  • Ser minucioso
  • Exibir autoridade e responsabilidade
  • Priorizar a correção dos comentários (evitando levar + de 24/48 horas)
  • Favorecer o pragmatismo, e não perfeccionismo
  • Evitar comentar code style! Usar linters

🚢 Boas code reviews - Expectativas para um revisor de PR

Sinais de um processo de code 

  • Bloqueio justificado
    • PR muito grande
    • Falhas, gaps de teste, build quebradas
    • Riscos
    • Over-engineering, código e lógicas muito complexas, bibliotecas desnecessárias
  • Bloqueio injustificado
    • Críticas (especialmente code style)
    • Emergências
    • Utilizar "comentar e aprovar" quando for apropriado

🚢 Boas code reviews - Expectativas para um revisor de PR

  • Documentada no Github, Notion ou Wiki do time - colaboração com o time! (Documento compartilhado)
  • Boas guidelines tem:
    • Quando e como abrir uma code review
    • Tamanho e escopo das PR's. Example: database migrations, bug fix, feature
    • Expectativas para o autor e revisor das PR's
    • PR templates (github description)
    • Quando deve refatorar

🚢 Boas code reviews - Guidelines

🚢 Boas code reviews - Guidelines

https://github.com/renangabriel27/code-review-guideline

🚢 Boas code reviews - Guidelines

  • Definir as expectativas para o Autor
  • Definir as expectativas para os Revisores
  • Documentar a code review guidelines para seu time

🚢 Boas code reviews - Recap

  • Diminuiu o número de bugs
  • Diminuiu o número de ciclos de revisões
  • Velocidade de um novo dev em onboarding
  • Qualidade da discussão 

Key Performance Indicators - Estamos no caminho?

Final da parte 1

2. Faça melhores code reviews

Impulsionar a qualidade do código e elevar as skills do time

2. Tópicos

  • O que olhar em uma code review 🔎
  • Como realizar uma code review (passo a passo) ⚙
  • Escrever comentários eficazes nas code reviews 📝

O que olhar em uma code review🔎  

  • Falhas primeiro
  • Legibilidade do código
  • Oportunidades de aprendizado

"diff"

O que procurar

O que procurar

  • Escopo - exemplo: Task no Jira
  • Build, check, tests
  • Conflitos
  • Screenshots
  • Ela resolve o problema - o problema certo?
  • Regras de negócio gaps
  • Mudanças de comportamento inesperadas
  • Otimização - perfomance
  • Documentação
  • Responsividade
  • Design/Figma
  • Complexidade / over-engineering
  • Code Style?

O que procurar - Gaps de legibildade

O que procurar - Gaps de legibildade

  • Intenção precisa ser óbvia
  • Defina nomes significativos
  • Convenções
  • Implementação e testes

O que procurar - Recap

  • Tomar propriedade
  • Falhas
  • Gaps de legibilidade

Como revisar (Contexto)

  • Leia a descrição da code review, e as tasks relacionadas
  • Verifique se você é o revisor apropriado
  • Reserve um tempo
  • Otimização para velocidade ou qualidade?

Como revisar (Leia para entender)

  • Comece pelo ponto  crucial
  • Leia aleatoriamente
  • Leia classe por classe depois que você entender
  • Falhas - você é um detetive 

Como revisar (Comentando)

  • Escreva comentários 
  • Reescreva comentários 
  • Deixe comentários positivos 👍 
  • Faça uma decisão clara sobre aprovação ✅

Escrever comentários eficazes - why?

 

  • Reduzir desentendimentos
  • Colegas vão respeitar sua opinião
  • Exemplo prático de um bom trabalho

Comentário eficazes - O código, não a pessoa

❌ "Você não checou o valor null."

 

✅ "Esse valor do input pode ser null, causando um erro de servidor. Se o valor for null, você poderia lançar um erro client/side."
Ou
✅ "O que poderia acontecer se for setado um valor null?"

Comentário eficazes - Críticas

❌ "Mude o nome da variável."

✅ "Mudança, não bloqueante:

Eu recomendaria mudar o nome da variável de `purchaseStatus` para `orderStatus`. A variável armazena o status de um pedido, não a compra."

Comentário eficazes - Explique o motivo

❌ "Use o Promise.all"

 

✅ "Promise.all nesse caso de várias requisições vai rodar todas elas de forma assíncrona e finalizar somente depois de todas terem rodado, otimizando a velocidade do carregamento da página"

Comentário eficazes - Explique o motivo + background

❌ "Use o Promise.all"


✅ "Promise.all nesse caso de várias requisições vai rodar todas elas de forma assíncrona e finalizar somente depois de todas terem rodado, otimizando a velocidade do carregamento da página.

Para mais contexto: https://dev.to/cristuker/javascript-porque-usar-promiseall-4jc3"

Comentário eficazes - Explique o motivo + background

Comentário eficazes - Recap

 

  • Comente sobre o código, não a pessoa
  • Propor um caminho para seguir ou colaborar
  • Explique os motivos
  • Forneça um background

Referências

Dúvidas?

Copy of Master the Code Review

By Renan Gabriel

Copy of Master the Code Review

  • 16