Refatoração (Pagar.me Talks)

Refatoração (Pagar.me Talks)

Material usado no Pagar.me Talks (https://www.youtube.com/watch?v=D7X2hDf3mCQ)

049fbbe4e5fb94c45d6ccd656290d6fb?s=128

Davi Marcondes Moreira

November 14, 2016
Tweet

Transcript

  1. Refatoração Pagar.me 2016-11-14 Davi Marcondes Moreira @devdrops

  2. Introdução

  3. None
  4. Objetivos principais: 1. Sempre deixar a casa melhor do que

    você encontrou. 2. Tornar o software mais confiável para você e para quem vai mexer nele amanhã.
  5. Além dos sistemas legados

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

    bugs • Acúmulo de más práticas
  7. 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)
  8. 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?
  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) Criação • TDD: red, green, e, qual era o terceiro mesmo? Refactor.
  10. Trabalho em equipe

  11. 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
  12. Ferramentas para toda obra

  13. None
  14. None
  15. None
  16. None
  17. None
  18. Métodos (pequenos porém úteis)

  19. 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.
  20. 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.
  21. 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.
  22. Benefícios

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

    à mudanças. Confiança e seguranç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
  24. Conclusão

  25. 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."
  26. Muito obrigado! =P @devdrops devdrops.me/about