Como o code review pode fazer bem para sua equipe

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Olá! EU SOU VINÍCIUS ALONSO

Slide 3

Slide 3 text

O QUE É CODE REVIEW? 1

Slide 4

Slide 4 text

“ É uma prática de revisão de trabalho de um programador antes de integrá-lo à base de código

Slide 5

Slide 5 text

COMO ACONTECE? Passo a passo: ◦ O dev inicia uma tarefa em um novo branch; ◦ Trabalha nela; ◦ No fim envia uma Pull Request (PR) A partir disso começa o code review, onde seus pares revisarão sua PR

Slide 6

Slide 6 text

QUAL O VALOR PARA MINHA EQUIPE? 2

Slide 7

Slide 7 text

VALOR DO CODE REVIEW PARA UMA EQUIPE Valores: ◦ Compartilhamento de conhecimento; ◦ Criação de soluções alternativas; ◦ Aumento do senso de equipe

Slide 8

Slide 8 text

COMPARTILHAMENTO DE CONHECIMENTO Centralizar o conhecimento em um único membro pode prejudicar sua equipe.

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

CRIAÇÃO DE SOLUÇÕES ALTERNATIVAS PARA OS PROBLEMAS Debater nossas implementações é fundamental para melhorá-las.

Slide 11

Slide 11 text

def total_value total = 0 @items.each do |item| total += item.total_value end total end

Slide 12

Slide 12 text

def total_value @items.map(&:total_value) .reduce(:+) end

Slide 13

Slide 13 text

AUMENTO DO SENSO DE EQUIPE Se algo quebrar em produção de quem é a culpa?

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

QUAIS SÃO OS PAPÉIS DOS ENVOLVIDOS? 3

Slide 16

Slide 16 text

QUAIS SÃO OS PAPÉIS DOS ENVOLVIDOS? Papéis: ◦ Autor; ◦ Revisor

Slide 17

Slide 17 text

AUTOR Quem implementou a feature, corrigiu o bug, etc e no fim enviou a PR.

Slide 18

Slide 18 text

Autor Responsabilidades: ◦ Escrever um código de qualidade; ◦ Resolver o problema conforme o requisito; ◦ Testar os casos básicos; ◦ Fornecer contexto

Slide 19

Slide 19 text

Fornecendo contexto .github/PULL_REQUEST_TEMPLATE.md

Slide 20

Slide 20 text

REVISOR Deve instigar um debate sobre o trabalho do colega por meio da argumentação lógica.

Slide 21

Slide 21 text

Revisor Responsabilidades: ◦ Perguntar, não dar ordens; ◦ Justificar as melhorias propostas; ◦ Ajudar com correções e mudanças

Slide 22

Slide 22 text

PONTOS CHAVE PARA UM REVIEW DE QUALIDADE 4

Slide 23

Slide 23 text

Pontos chave para um review de qualidade Pontos: ◦ O que foi desenvolvido atende os requisitos? ◦ Os testes escritos garantem que o que foi implementado está realmente funcionando? ◦ A solução empregada foi a melhor para o momento?

Slide 24

Slide 24 text

O que foi desenvolvido atende os requisitos? Melhor fazer errado a coisa certa do que fazer certo a coisa errada.

Slide 25

Slide 25 text

O que foi desenvolvido atende os requisitos? Pontos a considerar: ◦ Se o código não cumpre o requisito, podemos adicionar um defeito ao nosso software; ◦ Preferencialmente, não deve conter tarefas ocultas em nossa PR

Slide 26

Slide 26 text

O que foi desenvolvido atende os requisitos? Exemplo de requisito

Slide 27

Slide 27 text

Os testes escritos garantem que o que foi implementado está realmente funcionando? Devemos ser capazes de ver os requisitos nos testes.

Slide 28

Slide 28 text

Os testes escritos garantem que o que foi implementado está realmente funcionando? Pontos a considerar: ◦ O testes devem cobrir os fluxos básicos; ◦ Tanto o caminho feliz como alguns caminhos de erro; ◦ Testes que não quebram não valem de nada

Slide 29

Slide 29 text

Os testes escritos garantem que o que foi implementado está realmente funcionando? describe "#add_item" do it 'contain 1 new item' do product = instance_double('Product', name: 'Notebook', price: 3000) item = instance_double('Item', product: product, quantity: 1) expect do cart.add_item(item) end.to change{ cart.items.length }.from(0).to(1) end end Teste escrito com a biblioteca Rspec

Slide 30

Slide 30 text

A solução empregada foi a melhor para o momento? O código escrito foi atende o que precisamos agora, sem criar um débito técnico?

Slide 31

Slide 31 text

A solução empregada foi a melhor para o momento? Pontos a considerar: ◦ O código escrito está claro seguindo o Clean Code? ◦ Lembre-se do YAGNI (you aren’t gonna need it)

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

OUTROS PONTOS RELEVANTES SOBRE CODE REVIEW 5

Slide 34

Slide 34 text

Outros pontos relevantes sobre code review Pontos: ◦ Automatize o que deve ser automatizado ◦ Use os hooks do git a vontade ◦ Estude boas práticas para argumentar melhor

Slide 35

Slide 35 text

Automatize o que deve ser automatizado

Slide 36

Slide 36 text

Use os hooks do git a vontade

Slide 37

Slide 37 text

Use os hooks do git a vontade #!/usr/bin/env ruby require 'english' require 'rubocop' ADDED_OR_MODIFIED = /A|AM|^M/.freeze changed_files = `git status --porcelain`.split(/\n/). select { |file_name_with_status| file_name_with_status =~ ADDED_OR_MODIFIED }. map { |file_name_with_status| file_name_with_status.split(' ')[1] }. select { |file_name| File.extname(file_name) == '.rb' }.join(' ') system("rubocop #{changed_files}") unless changed_files.empty? exit $CHILD_STATUS.to_s[-1].to_i

Slide 38

Slide 38 text

Estude boas práticas para argumentar melhor

Slide 39

Slide 39 text

CONCLUSÃO

Slide 40

Slide 40 text

Conclusão Pontos: ◦ Code review traz muitos benefícios para sua equipe ◦ Devemos focar no que a máquina não pode fazer ◦ Para a prática acontecer de maneira saudável precisamos de indivíduos motivados a melhorar

Slide 41

Slide 41 text

Obrigado! PERGUNTAS? Você pode me encontrar Twitter: @alonsoemacao Github: @viniciusalonso [email protected]

Slide 42

Slide 42 text

REFERÊNCIAS Estude boas práticas para argumentar melhor https://github.com/viniciusalonso/code-review-good-practices

Slide 43

Slide 43 text

POSTS https://medium.com/@vinciusalonso