Compartilhando conhecimento e unindo uma equipe por meio de code review

Compartilhando conhecimento e unindo uma equipe por meio de code review

Palestra apresentada no Darkmira Tour 2018 em Brasília

44d238e94ac021ed797b5d7ef2664dd5?s=128

Vinícius Alonso

April 16, 2018
Tweet

Transcript

  1. Compartilhando conhecimento e unindo uma equipe por meio do code

    review VINÍCIUS BAIL ALONSO
  2. Olá! EU SOU VINÍCIUS ALONSO Desenvolvedor Backend na CompuFácil Membro

    do PHP-SC
  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. QUAL O VALOR PARA MINHA EQUIPE? 2

  6. COMPARTILHAMENTO DE CONHECIMENTO Centralizar o conhecimento em um único membro

    pode prejudicar sua equipe.
  7. None
  8. CRIAÇÃO DE SOLUÇÕES ALTERNATIVAS PARA OS PROBLEMAS Debater nossas implementações

    é fundamental para melhorá-las.
  9. public function totalValue() { $total = 0; foreach ($this->items as

    $item) { $total += $item->totalValue(); } return $total; }
  10. public function totalValue() { $items = $this->items; return array_reduce($items, 'sum');

    }
  11. AUMENTO DO SENSO DE EQUIPE Se algo quebrar em produção

    de quem é a culpa?
  12. None
  13. QUAIS SÃO OS PAPÉIS DOS ENVOLVIDOS? 3

  14. AUTOR Quem implementou a feature, corrigiu o bug, etc e

    no fim enviou a PR.
  15. Autor Responsabilidades: ◦ Escrever um código de qualidade; ◦ Resolver

    o problema conforme o requisito; ◦ Fornecer contexto
  16. Fornecendo contexto .gitlab/merge_request_templates/feature.md

  17. REVISOR Deve instigar um debate sobre o trabalho do colega

    por meio da argumentação lógica.
  18. Revisor Responsabilidades: ◦ Perguntar, não dar ordens; ◦ Justificar as

    melhorias propostas; ◦ Ajudar com correções e mudanças
  19. PONTOS CHAVE PARA UM REVIEW DE QUALIDADE 4

  20. O que foi desenvolvido atende os requisitos? Melhor fazer errado

    a coisa certa do que fazer certo a coisa errada.
  21. O que foi desenvolvido atende os requisitos? Pontos a considerar:

    ◦ Cuidar para não introduzir defeitos no software; ◦ Preferencialmente, não fazer tarefas ocultas em nossa PR;
  22. O que foi desenvolvido atende os requisitos? Exemplo de requisito

    sem contexto
  23. Os testes escritos garantem que o que foi implementado está

    realmente funcionando? Devemos ser capazes de ver os requisitos nos testes.
  24. 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
  25. Os testes escritos garantem que o que foi implementado está

    realmente funcionando? public function testAddItem_shouldAddANewItem () { $product = new Product(['price' => 3000]); $item = new Item(['product' => $product, 'quantity' => 1]); $cart = new Cart(); $cart->addItem($item); $this->assertEquals( 1, $cart->countItems()); } Teste escrito com a biblioteca PHPUnit
  26. Os testes escritos garantem que o que foi implementado está

    realmente funcionando? public function testAddItem_shouldAddTwoItems() { $product1 = new Product(['price' => 3000]); $item1 = new Item(['product' => $product1, 'quantity' => 1]); $product2 = new Product(['price' => 200]); $item2 = new Item(['product' => $product2, 'quantity' => 2]); $cart = new Cart(); $cart->addItem($item1); $cart->addItem($item2); $this->assertEquals(2, $cart->countItems()); } Teste que repete o conceito do anterior
  27. 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?
  28. A solução empregada foi a melhor para o momento? Pontos

    a considerar: ◦ Clean Code ◦ YAGNI (you aren’t gonna need it) ◦ Arquitetura
  29. None
  30. AGILIDADE 5

  31. Uma das motivações do manifesto ágil “Individuals and interactions over

    processes and tools”
  32. Alguns dos princípios do manifesto ágil “Working software is the

    primary measure of progress” “Continuous attention to technical excellence and good design enhances agility” “The best architectures, requirements, and designs emerge from self-organizing teams”
  33. UMA FERRAMENTA 5

  34. Uma ferramenta https://github.com/danger/danger

  35. CONCLUSÃO

  36. 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
  37. Obrigado! PERGUNTAS? Você pode me encontrar Twitter: @alonsoemacao Github: @viniciusalonso

    Blog: https://medium.com/@vinciusalonso vba321@hotmail.com
  38. REFERÊNCIAS https://github.com/viniciusalonso/code-review-good-practices