Refatoração refere-se à reestruturação do código-fonte de um software sem alterar seu comportamento externo, visando melhorar aspectos como legibilidade, manutenibilidade e design. O documento descreve os princípios e origens da refatoração, exemplos de técnicas como renomear variáveis e extrair métodos, além de discutir vantagens como redução de duplicação e aumento da simplicidade do código.

1. REFACTORY REFATORAÇÃO

2. Princípios - Definição Refactoring (Refatoração): mudança feita na estrutura interna do software para torná-lo fácil de entender e simples de modificar, sem mudar o comportamento observável. Transformações pequenas, que feitas ao longo do tempo e em seqüência, alteram a estrutura do código.

3. Conceito Refatoração/ Refatoring: É o processo de reescrever um programa de computador para melhorar sua estrutura ou legibilidade, preservando assim seu comportamento. (Martin Fowler)

4. Origens Surgiu na comunidade de Smalltalk nos anos 80/90. Desenvolveu-se formalmente na Universidade de Illinois em Urbana-Champaign. (EUA) Grupo do Prof. Ralph Johnson. - Tese de PhD de William Opdyke (1992). - John Brant e Don Roberts: - The Refactoring Browser Tool Kent Beck (XP) na indústria.

5. Refatoração sempre existiu? Não tinha nome Estava implícito A novidade, era poder criar um vocabulário comum e catalogá-los Utilizar mais sistematicamente Aprender novas técnicas, ensinar uns aos outros Sim.

6. Refatorar... Gera: Simplicidade Flexibilidade Clareza Desempenho

7. Na Engenharia de Software (E.S.), refatorar, significa: Modificar o código fonte, sem mudar seu comportamento externo. E é algumas vezes informalmente referido como " cleaning it up "

8. Melhorias não-funcionais: Simplicidade Clareza - “O compilador não se importa se o código está feio ou limpo, porém os seres humanos sim"

9. Não repara erros Não adiciona novas funcionalidades Melhora a compreensão, consistência interna, documentação e clareza do código fonte. Tornando-o mais fácil para manutenções futuras. Refatoring/ Refatoração

10. Por que refatorar? Melhora o design Facilita a compreensão Ajuda a achar bugs Ajuda a programar mais rápido (XP)

11. Porquê fazer refactoring? Facilitar a inserção de código novo e novas funcionalidades. Melhorar o desenho do código existente. Compreender melhor o código. Tornar o código mais agradável de manipular, menos aborrecido de lidar, tanto individualmente como colaborativamente. “ Limpar e arrumar” o código. Baixar o “défice de design” devido a não se fazer na altura certa e dose certa: o remover de duplicação, simplificar e clarificar o intuito do código. Evoluir uma arquitetura existente.

12. Quando refatorar? Quando se quer adicionar funcionalidades - Para melhor compreender o código a modificar - Para melhorar o design do código existente e assim facilitar a adição das novas funcionalidades Quando se precisa consertar um bug Para melhor compreender o código com o “bug” e assim o identificar Quando se está revisando o código Melhorar o código existente, ou Jogar fora e começar do 0 (zero). “ É de sua responsabilidade analisar a situação e decidir quando será a hora exata de optar por um ou por outro”.

13. OBS.: A refatoração, não é feita só para os exemplos anteriores. Dependendo da empresa que trabalha e do grau de maturidade do software que ela produz, você deve estar acostumado a usar um padrão definido para desenvolver o código, isto surge conforme o tempo. O que significa que existe código não-padronizado e já padronizado

14. “Qualquer tolo pode escrever código que um computador pode compreender, mas bons programadores escrevem códigos que os seres humanos possam compreender." [Fowler 2000]

15. Passos de Refatoração Cada passo é trivial Demora alguns segundos ou alguns poucos minutos para ser realizado Operações sistemáticas e óbvias Ter um bom vocabulário de refatoração e aplicar criteriosamente e sistematicamente

16. Aplicações na Refatoração Melhorar o código antigo e/ou feito por outros programadores. Desenvolvimento incremental... À la XP (Programação Extrema) O passo de refatoração é tão simples que parece que ele não ajudará muito. Quando juntado 50 passos bem escolhidos em seqüência, o código melhora rapidamente

17. O Primeiro Passo em Qualquer Refatoração Antes de começar a refatoração, verifique se você tem um conjunto sólido de testes para verificar a funcionalidade do código a ser refatorado. Refatorações podem adicionar erros. Os testes vão ajudá-lo a detectar erros se eles forem criados.

18. Mais passos para testes Testes de unidade: ajudam (mas não garantem) a não introduzir bugs no código. Uso dos framework X-Unit : jUnit, pyUnit, cppUnit ... Automação de refactorings aumentou quando as verificações formais foram feitas.

19. Para uma boa Refatoração Os passos devem estar bem definidos: Identificar o local a ser refatorado Definir as refatorações a serem implementadas Garantir a integridade do comportamento observável Aplicar as refatorações escolhidas Confirmar a preservação do comportamento observável após a implementação da refatoração

20. Principio Básico Refatoração muda o programa em passos pequenos. Se você comete um erro, é fácil consertar. Três repetições? Está na hora de refatorar. Quando você sente que é preciso escrever um comentário para explicar o código melhor, tente refatorar primeiro.

21. Principio Básico Bad-smells => Refatoração a ser aplicada Código duplicado => Extração do método, Substituir o algoritmo Método muito longo => Extract Method, Replace Temp With Query, Introduce Parameter Object Classe muito grande => Extract Class, Extract Subclass, Extract Interface, Duplicate Observed Data Intimidade Inapropriada => Move Method, Move Field, Replace Inheritance With Delegation Comentários => Extract Method, Introduce Assertion Muitos parâmetros => Replace Parameter with Method, Preseve Whole Object, Introduce Parameter Object Quando há “bad-smells” (código cheira) mau, refatore-o!

22. Mais Princípios Básicos Os testes tem que ser automáticos e ser capazes de se auto-verificarem. A saída deve ser ok “ Ok” ou A lista precisa das coisas que deram errado. Quando os testes funcionam, sua saída deve ser apenas uma lista enxuta de “OKs”. Uma bateria de testes é um exterminador de bugs que pode lhe economizar muito tempo. Quando você recebe um aviso de bug, primeiro escreva um teste que reflita esse bug. Pense nas situações limítrofes onde as coisas podem dar errado e concentre os seus testes ali.

23. Dicas... Quando você tem que adicionar uma funcionalidade a um programa e o código do programa não está estruturado de uma forma que torne a implementação desta funcionalidade conveniente, primeiro refatore de modo a facilitar a implementação da funcionalidade, e só depois, implemente-a.

24. Exemplos de Refatoração Mudanças no nome das variáveis Pequenas mudanças arquiteturais Encapsular o código repetido em um novo método Generalização de métodos raisQuadrada (float x) => raiz (float x, int n)

25. Direções possíveis para refactoring Refactoring “to” (para) ... Refactoring “towards” (no sentido de) ... Refactoring “away” (de) ...

26. Formato dos Refactorings Nome Resumo Motivação Mecânica Exemplos

27. Refactoring + Patterns " Refatorar para padrões, é um método revolucionário para a aplicação de padrões que combina a utilidade de padrões de design com a descoberta do desenvolvimento iterativo e refatoração continua .”

28. Design patterns Existem muitas formas possíveis de implementar/ instanciar um padrão de software, umas mais simples, outras mais complexas e mais próximas da estrutura sugerida no padrão. Implementações minimalistas fazem parte de prática de design Evolutivo. Muitas vezes, uma implementação não-baseada em design patterns tem que evoluir para poder incluir um padrão. Neste caso, pode-se fazer refactoring do design para uma implementação simples de um padrão. Isto é “Refactoring to Patterns”!

29. Catálogo de “Refactorings to Patterns” Creation = Criação Simplification = Simplificação Generalization = Generalização Protection = Defesa/ proteção Accumulation = Acumulação Utilities = Utilitários

30. Vantagens de Refatorar: Redução de código duplicado Aumenta a simplicidade do código Melhora o desempenho Aumenta a legibilidade do código Melhora o projeto de software

31. OBS.: Aparentemente, o assunto que diz respeito à refatoração, somente apresenta vantagens em sua utilização, mas à medida que o assunto segue se difundindo pela comunidade, desvantagens aparecem.

32. Desvantagens de Refatorar : Banco de Dados Alterando interfaces OBS.: Mesmo apresentando limitações, a utilização da refatoração não é invalidada, até mesmo porque as vantagens obtidas são extremamente válidas.

33. Dificuldades de refactoring Bases de dados - Aplicações fortemente dependentes dos esquemas das BDs Alterações na interface das classes - Quando não se tem acesso a todo o código que usa uma interface, em que se pretende alterar o refactoring dessa interface, pode ser complicado. Não publicar interfaces prematuramente. Modificar o seu código de propriedade políticas, é um bom refactoring. O Código Não Funciona - Nesta situação, de nada serve o refactoring...

34. Rename Marque o nome do atributo, propriedade, método ou parâmetro; clique com o botão direito do mouse em cima da marcação e selecione a opção "Refactor" e a sub-opção "Rename";Abrirá a seguinte caixa de dialogo: No campo "New name" especifique o nome desejado para ser renomeado e clique em "OK".

35. Será exibido a caixa de dialogo para Preview: Clique no Botão "Apply".

36. Reordenar Parâmetros

39. Extrair Método Marcar o texto a ser extraído para um método

40. Resultado da Extração do Método

41. “Go To Definition”

42. Remover Parâmetros Selecionar e clicar no botão “Remove”

43. Após o clique do botão "Remove" Clique do botão "OK"

44. O Parâmetro foi removido

45. Encapsular Campo Atributo da classe a ser encapsulada

46. Tela de propriedades do campo a ser encapsulado

47. Tela de Preview

48. Resultado Encapsulamento

49. Extrair Interface

50. Resultado de Extração da Interface

51. Interface Criada

52. Promover Variável Local para Parâmetros

53. Resultado da Variável

54. Refatoração... ...Atualmente é um dos preceitos básicos de X.P. ...Não está limitado, qualquer um pode e deve usar em qualquer contexto ...Pode ser usado em qualquer linguagem (orientada a objeto)

55. Referências M. Fowler - Refactoring Home http://www.refactoring.com Joshua Kerievsky - Refactoring to Patterns - http://industriallogic.com/xp/refactoring/catalog.html Sven Gorts e Philippe T’Seyen - Refactoring Thumbnails http://www.refactoring.be/thumbnails.html Gene Garcia - Smells to Refactorings http://wiki.java.net/bin/view/People/SmellsToRefactorings Eclipse - http://www.eclipse.org Refactoring Seminários do aSide @ UFBA Universidade Federal da Bahia Mauricio B. C. Vieira, Christina von Flach Chavez (vieira|flach)@im.ufba.br Bibliografia: Martin Fowler. Refactoring: improving the design of existing code. Addison-Wesley. 2000. Revista .Net Magazine Ano 03 – 38ª edição Matéria: Refactoring – Conceito e aplicação prática

56. Workshop sobre Refactory Alin H. S. Rocha Estagiário .Net Email: AROCHA@DBA.COM.BR