O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Refactoring

6.558 visualizações

Publicada em

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Refactoring

  1. 1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br Princípios do Refactoring
  2. 2. http://www.slideshare.net/rodrigobranas
  3. 3. @rodrigobranas rodrigo.branas@gmail.com http://www.agilecode.com.brFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCertificaçõesSCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM
  4. 4. Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 palestras em eventosLíder da área de desenvolvimento na GenneraAutor da revista Java MagazinePalestranteInstrutor da Academia Java e Agile da GlobalcodeCriador dos treinamentos de Clean Code, Selenium eMaven da Agile CodeTrabalhou com as empresas: EDS, HP, GM, Citibank,OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed,Suntech, Vale do Rio Doce, Senai, NET.
  5. 5. O que é Refactoring?
  6. 6. “Alteração feita na estrutura internado software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado sem alterar seu comportamento observável.” (Martin Fowler)
  7. 7. “Refactoring é a arte de evoluir o design do código existente.” (William C. Wake)
  8. 8. “Refactoring é uma forma de manterseu software sustentável e competitivo com o passar do tempo.” (Rodrigo Branas)
  9. 9. Refatorar é uma forma de investimento
  10. 10. Tempo investido refatorando é proporcional ao tempo economizado com o entendimento docódigo multiplicado pelo número de pessoas na equipe.
  11. 11. A fórmula matemática do refactoring: Tr = Te * tamanho da equipe 1 hora investida refatorando é proporcional a8 horas economizadas com o entendimento em uma equipe de 8 pessoas. Isso sem falar em flexibilidade, redução na quantidade de defeitos e reuso.
  12. 12. Infelizmente, o inverso também é verdadeiro
  13. 13. Como vender atividades derefactoring para o seu gerente?
  14. 14. Diálogo entre o Desenvolvedor e o GerenteDesenvolvedor: João, preciso fazer um refactoring no código!Gerente: Refactoring?! O que é isso, você vai melhorar a performance?Desenvolvedor: Não, não...Gerente: Vai deixar a interface mais bonita e mais fácil de ser utilizada?Desenvolvedor: Não...Gerente: Então? O que é isso?Desenvolvedor: “Vou fazer uma alteração na estrutura interna do software,para torná-lo mais fácil de ser entendido e menos custoso de sermodificado, sem alterar seu comportamento observável.” (Martin Fowler)Gerente: Não.
  15. 15. Refatore com um propósito, evite refatorar apenas por refatorar
  16. 16. Fique atento as oportunidades
  17. 17. Refatore na hora de adicionar novas funcionalidades
  18. 18. Refatore quando for corrigir um defeito
  19. 19. Refatore quando precisarentender uma parte do código
  20. 20. Os 7 principais inimigos da refatoração
  21. 21. Desconhecimento
  22. 22. Não se dar conta do problema é uma das principais causas. É comum ver desenvolvedoresexperientes que não dão atenção a qualidade do código.
  23. 23. Imediatismo
  24. 24. Pensar apenas em resolver oproblema, sem considerar que anatureza do desenvolvimento de software é a mudança.
  25. 25. Janelas Quebradas
  26. 26. Temos dificuldade em lidar com janelas quebradas. Seja numa dieta, relacionamento oudesenvolvimento de software, odesânimo das janelas quebradas leva ao fracasso.
  27. 27. Nível técnico baixo
  28. 28. É fácil culpar o estagiário. Épreciso ter pessoas com nível técnico alto e senso críticoapurado para zelar pelas boaspráticas e manter a ordem do código.
  29. 29. Falta de trabalho em equipe
  30. 30. O código pertence a equipe, não ao seu autor. Todos devem seresponsabilizar e zelar pelo bem comum.
  31. 31. Gerenciamento
  32. 32. Normalmente, seja por desconhecimento ou por pressãosuperior, iniciativas de refatoração sãocortadas pela gerência. Cuidado com o nível de maturidade técnica de quem toma as decisões.
  33. 33. Pressão comercial
  34. 34. Contratos mal feitos ou vendas que não consideram a capacidade técnica de entrega elevam o nível de pressão e também do imediatismo.
  35. 35. Quando você não deve refatorar?
  36. 36. Quando o código simplesmente não funciona, é instável
  37. 37. Se funciona, ninguém sabe ao certo como...
  38. 38. Próximo ao final do prazo de entrega
  39. 39. A maioria das empresas precisa contrair algumas dívidas para funcionar efetivamente
  40. 40. Mas cuidado com o aumentodo débito técnico, os juros são altos
  41. 41. Desafios da Refactoração

×