Pro Yearly is on sale from $80 to $50! »

Refatoração (PHPSP+Talks)

Refatoração (PHPSP+Talks)

Talk apresentada no PHPSP+Talks.

049fbbe4e5fb94c45d6ccd656290d6fb?s=128

Davi Marcondes Moreira

April 18, 2017
Tweet

Transcript

  1. Refatoração PHPSP Talks 2017-04-18 Davi Marcondes Moreira @devdrops

  2. Introdução

  3. None
  4. Broken Window Theory Por James Q Wilson e George L

    Kelling, Março 1982 https://en.wikipedia.org/wiki/Broken_windows_theory “Desordem gera desordem.”
  5. Refatoração: O que é? • Processo de reestruturar o código

    sem alterar seu comportamento.
  6. Refatoração: O que é? • Processo de reestruturar o código

    sem alterar seu comportamento. Mas IMHO também é: • Sempre deixar a casa melhor do que você encontrou. • Tornar o software mais confiável para você e para quem vai mexer nele amanhã.
  7. Além dos sistemas legados

  8. Correções • Débito técnico (o famoso TODO) • Vulnerabilidades e

    bugs • Acúmulo de más práticas
  9. Correções • Débito técnico (o famoso TODO) • Vulnerabilidades e

    bugs • Acúmulo de más práticas Melhorias • Atualização de dependências • Melhorar performance • Diminuir complexidade (o código deve ser simples)
  10. Correções • Débito técnico (o famoso TODO) • Vulnerabilidades e

    bugs • Acúmulo de más práticas Melhorias • Atualização de dependências • Melhorar performance • Diminuir complexidade (o código deve ser simples) Criação • TDD: red, green, e, qual era o terceiro mesmo?
  11. Correções • Débito técnico (o famoso TODO) • Vulnerabilidades e

    bugs • Acúmulo de más práticas Melhorias • Atualização de dependências • Melhorar performance • Diminuir complexidade (o código deve ser simples) Criação • TDD: red, green, e, qual era o terceiro mesmo? Refactor.
  12. Trabalho em equipe

  13. Colaboração • Refatorar não é uma atividade isolada. ◦ Pedir

    ajuda aos colegas ◦ Discutir em grupo/equipe ◦ Alinhar métricas e regras ▪ Mínimo de % na cobertura de testes, padrões de estilo ◦ Não ser negligente e assumir responsabilidade
  14. Ferramentas para toda obra

  15. None
  16. None
  17. None
  18. None
  19. None
  20. None
  21. None
  22. None
  23. None
  24. Métodos (simples porém úteis)

  25. 1. Renomeando métodos • Usando forma mais claras, curtas e

    concisas, ou mesmo verbosas se necessário. • Ser o mais explícito possível. • Em casos críticos, reescreva a nova chamada dentro do método antigo, depreciando o método anterior e evitando quebrar compatibilidades enquanto a adoção do novo método é feita por toda a equipe.
  26. 1. Renomeando métodos // Classe usada por toda a aplicação

    class Foo { public function oldScaryMethod( $foo, $bar, $baz ) { // Complexidade no contexto } } // Chamada encapsulada em outro método class Foo { public function newMethod( $foo ) { // Podemos agir aqui $this->oldScaryMethod(...); } public function oldScaryMethod(...) { // Complexidade isolada } }
  27. 2. Extrair responsabilidades de um método em um novo(a) método/classe

    • Identificar que parte de um código pode ser reescrita em outro lugar, reduzindo a complexidade. • Abre espaço para refletir sobre princípios como 'o que de fato isso deveria estar fazendo?', 'qual a verdadeira responsabilidade desse método?' e encaixar boas práticas como SRP de orientação à objetos.
  28. 3. Eliminar código morto • Código que não tem mais

    uso, ou é fruto de copiar de uma parte específica do projeto para outra, que ficou para trás. • Não ter medo de excluir código. Partes antigas podem ser recuperadas pelo SCV. • Requer uma boa estratégia de teste.
  29. Benefícios

  30. Entregas pontuais O código fica mais compreensível, organizado e flexível

    à mudanças.
  31. Entregas pontuais O código fica mais compreensível, organizado e flexível

    à mudanças. Confiança ao editar o código Maior visibilidade dos problemas.
  32. Entregas pontuais O código fica mais compreensível, organizado e flexível

    à mudanças. Confiança ao editar o código Maior visibilidade dos problemas. Garantia de qualidade Fim da síndrome da casa de vidro.
  33. Entregas pontuais O código fica mais compreensível, organizado e flexível

    à mudanças. Confiança ao editar o código Maior visibilidade dos problemas. Garantia de qualidade Fim da síndrome da casa de vidro. Uma bela noite de sono =P
  34. Conclusões

  35. No episódio de hoje… • Tudo o que se precisa

    é intenção. • Refatoração acontece em vários momentos. E todos podem e devem ajudar. • Quanto mais cedo e pontual, mais fácil de fazer. • Nem toda refatoração é simples, e cada caso precisa ser muito bem analisado para verificar todo impacto e esforço.. • "A única certeza sobre software é que ele muda."
  36. Muito obrigado! =P @devdrops devdrops.me/about Gostou? Estamos contratando! venhapara@pagar.me