Como o code review pode fazer bem para sua equipe

Transcript

1. Como o code review pode fazer bem para sua equipe
2. Olá! EU SOU VINÍCIUS ALONSO
3. O QUE É CODE REVIEW? 1
4. “ É uma prática de revisão de trabalho de um programador antes de integrá-lo à base de código
5. 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
6. QUAL O VALOR PARA MINHA EQUIPE? 2
7. VALOR DO CODE REVIEW PARA UMA EQUIPE Valores: ◦ Compartilhamento de conhecimento; ◦ Criação de soluções alternativas; ◦ Aumento do senso de equipe
8. COMPARTILHAMENTO DE CONHECIMENTO Centralizar o conhecimento em um único membro pode prejudicar sua equipe.
10. CRIAÇÃO DE SOLUÇÕES ALTERNATIVAS PARA OS PROBLEMAS Debater nossas implementações é fundamental para melhorá-las.
11. def total_value total = 0 @items.each do |item| total += item.total_value end total end
12. def total_value @items.map(&:total_value) .reduce(:+) end
13. AUMENTO DO SENSO DE EQUIPE Se algo quebrar em produção de quem é a culpa?
15. QUAIS SÃO OS PAPÉIS DOS ENVOLVIDOS? 3
16. QUAIS SÃO OS PAPÉIS DOS ENVOLVIDOS? Papéis: ◦ Autor; ◦ Revisor
17. AUTOR Quem implementou a feature, corrigiu o bug, etc e no fim enviou a PR.
18. Autor Responsabilidades: ◦ Escrever um código de qualidade; ◦ Resolver o problema conforme o requisito; ◦ Testar os casos básicos; ◦ Fornecer contexto
19. Fornecendo contexto .github/PULL_REQUEST_TEMPLATE.md
20. REVISOR Deve instigar um debate sobre o trabalho do colega por meio da argumentação lógica.
21. Revisor Responsabilidades: ◦ Perguntar, não dar ordens; ◦ Justificar as melhorias propostas; ◦ Ajudar com correções e mudanças
22. PONTOS CHAVE PARA UM REVIEW DE QUALIDADE 4
23. 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?
24. O que foi desenvolvido atende os requisitos? Melhor fazer errado a coisa certa do que fazer certo a coisa errada.
25. 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
26. O que foi desenvolvido atende os requisitos? Exemplo de requisito
27. Os testes escritos garantem que o que foi implementado está realmente funcionando? Devemos ser capazes de ver os requisitos nos testes.
28. 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
29. 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
30. 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?
31. 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)
33. OUTROS PONTOS RELEVANTES SOBRE CODE REVIEW 5
34. 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
35. Automatize o que deve ser automatizado
36. Use os hooks do git a vontade
37. 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
38. Estude boas práticas para argumentar melhor
39. CONCLUSÃO
40. 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
41. Obrigado! PERGUNTAS? Você pode me encontrar Twitter: @alonsoemacao Github: @viniciusalonso vba321@hotmail.com
42. REFERÊNCIAS Estude boas práticas para argumentar melhor https://github.com/viniciusalonso/code-review-good-practices
43. POSTS https://medium.com/@vinciusalonso