Refactory Worshop

Slide 1: REFACTORY REFATORAÇÃO

Slide 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.

Slide 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)

Slide 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.

Slide 5: Refatoração sempre existiu? Sim. • 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

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

Slide 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"

Slide 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"

Slide 9: Refatoring/ Refatoração • 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.

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

Slide 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.

Slide 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”.

Slide 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

Slide 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]

Slide 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

Slide 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

Slide 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.

Slide 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.

Slide 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

Slide 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.

Slide 21: Principio Básico Quando há “bad-smells” (código cheira) mau, refatore-o! 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

Slide 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.

Slide 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.

Slide 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)

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

Slide 26: Formato dos Refactorings • Nome • Resumo • Motivação • Mecânica • Exemplos

Slide 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.”

Slide 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”!

Slide 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

Slide 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

Slide 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.

Slide 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.

Slide 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...

Slide 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".

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

Slide 36: Reordenar Parâmetros

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

Slide 40: Resultado da Extração do Método

Slide 41: “Go To Definition”

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

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

Slide 44: O Parâmetro foi removido

Slide 45: Encapsular Campo Atributo da classe a ser encapsulada

Slide 46: Tela de propriedades do campo a ser encapsulado

Slide 47: Tela de Preview

Slide 48: Resultado Encapsulamento

Slide 49: Extrair Interface

Slide 50: Resultado de Extração da Interface

Slide 51: Interface Criada

Slide 52: Promover Variável Local para Parâmetros

Slide 53: Resultado da Variável

Slide 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)

Slide 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

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