O documento apresenta Rodrigo Branas, palestrante e instrutor de desenvolvimento Java e Agile. Ele discute princípios do refactoring como forma de manter o código sustentável e competitivo ao longo do tempo, e como vender atividades de refactoring para a gerência enfatizando benefícios como redução de custos e flexibilidade. Também lista sete inimigos da refatoração como desconhecimento, imediatismo, janelas quebradas, nível técnico baixo, falta de trabalho em equipe, gerenciamento e pressão comercial.

1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br
Princípios do Refactoring

2. http://www.slideshare.net/rodrigobranas

3. @rodrigobranas
rodrigo.branas@gmail.com
http://www.agilecode.com.br
Formação Acadêmica
Ciências da Computação – UFSC
Gerenciamento de Projetos - FGV
Certificações
SCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM

4. Rodrigo Branas – rodrigo.branas@gmail.com
10 anos de experiência na plataforma Java
1000 horas em sala de aula
Mais de 50 palestras em eventos
Líder da área de desenvolvimento na Gennera
Autor da revista Java Magazine
Palestrante
Instrutor da Academia Java e Agile da Globalcode
Criador dos treinamentos de Clean Code, Selenium e
Maven da Agile Code
Trabalhou com as empresas: EDS, HP, GM, Citibank,
OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed,
Suntech, Vale do Rio Doce, Senai, NET.

5. O que é Refactoring?

6. “Alteração feita na estrutura interna
do 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. “Refactoring é a arte de evoluir o
design do código existente.”
(William C. Wake)

8. “Refactoring é uma forma de manter
seu software sustentável e competitivo
com o passar do tempo.”
(Rodrigo Branas)

9. Refatorar é uma forma de
investimento

10. Tempo investido refatorando é proporcional ao
tempo economizado com o entendimento do
código multiplicado pelo número de pessoas na
equipe.

11. A fórmula matemática do refactoring:
Tr = Te * tamanho da equipe
1 hora investida refatorando é proporcional a
8 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. Infelizmente, o inverso também é
verdadeiro

13. Como vender atividades de
refactoring para o seu gerente?

14. Diálogo entre o Desenvolvedor e o Gerente
Desenvolvedor: 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 ser
modificado, sem alterar seu comportamento observável.” (Martin Fowler)
Gerente: Não.

15. Refatore com um propósito, evite
refatorar apenas por refatorar

16. Fique atento as oportunidades

17. Refatore na hora de adicionar
novas funcionalidades

18. Refatore quando for
corrigir um defeito

19. Refatore quando precisar
entender uma parte do código

20. Os 7 principais inimigos da
refatoração

21. Desconhecimento

22. Não se dar conta do problema é
uma das principais causas. É
comum ver desenvolvedores
experientes que não dão atenção
a qualidade do código.

23. Imediatismo

24. Pensar apenas em resolver o
problema, sem considerar que a
natureza do desenvolvimento de
software é a mudança.

25. Janelas Quebradas

26. Temos dificuldade em lidar com
janelas quebradas. Seja numa
dieta, relacionamento ou
desenvolvimento de software, o
desânimo das janelas quebradas
leva ao fracasso.

27. Nível técnico baixo

28. É fácil culpar o estagiário. É
preciso ter pessoas com nível
técnico alto e senso crítico
apurado para zelar pelas boas
práticas e manter a ordem do
código.

29. Falta de trabalho em equipe

30. O código pertence a equipe, não
ao seu autor. Todos devem se
responsabilizar e zelar pelo bem
comum.

31. Gerenciamento

32. Normalmente, seja por
desconhecimento ou por pressão
superior, iniciativas de refatoração são
cortadas pela gerência. Cuidado com o
nível de maturidade técnica de quem
toma as decisões.

33. Pressão comercial

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. Quando você não deve
refatorar?

36. Quando o código simplesmente
não funciona, é instável

38. Se funciona, ninguém sabe ao
certo como...

40. Próximo ao final do prazo de
entrega

41. A maioria das empresas precisa
contrair algumas dívidas para
funcionar efetivamente

42. Mas cuidado com o aumento
do débito técnico, os juros são altos

43. Desafios da Refactoração