Salve! Salve! Dando continuidade a série Refactoring, hoje vou abordar as vantagens/desvantagens e as ferramentas que temos disponíveis. Quero chamar atenção no primeiro tópico do post: Vantagem da Refatoração. Quis fazer um pouco diferente ao invés de pegar as vantagens de refactoring e tentar convencê-lo de usar ou apenas mostrá-las. Acabei fazendo diferente, não vou dizer de forma direta as vantagens de refactoring você como bom programador vai refletir sobre as abordagens dentro do tópico, e daí percebam onde entra o porquê de você adotar refactoring e seus respectivos benefícios no seu ambiente de desenvolvimento.
O motivo que fiz isso é que alguns/muitos profissionais de T.I sabem da existência de refactoring, sabem das vantagens que assistiu em alguma palestra ou leu um artigo na web/revista, porém após ter visto nada mudou em sua vida como programador. E eu sou apenas mais um transmitindo aquilo que ele já viu várias vezes.
O que quero é que você programador/analista etc. após ler reflita, pegue um código seu e se pergunte será preciso refatorar meu software?
Let’s GO…
Summary
This article presents the vantages/disadvantage and the tool that have available for refactoring. The list of the tool is in the end this article.
There are four parts that became the program hard of work. See below:
– Program that is hard of read the level of code
– Program that have the logic duplicate
– Logic conditional: program with logic conditional complex is hard of work.
The tool for refactoring help the project letting more elastic.
Vantagens da Refatoração
Refatorar é o processo de pegar um programa em produção e agregar a ele valor, não por meio da alteração de seu comportamento mais dando qualidades que nos permitem continuar desenvolvendo rapidamente. É preciso ter programas fáceis de ler a nível de código e que tenham a lógica especificada em apenas um lugar.
“Programas têm dois tipos de valor: o que eles fazem por você hoje e o que podem fazer por você amanhã, na maior parte das vezes quando estamos desenvolvendo um Software focalizamos no queremos que o programa faça hoje.” (Beck,2000)
Nas palavras de Beck [2000 apud Fowler, 2004, pg.58] “Se você consegue fazer hoje o trabalho de hoje, mas o faz de uma maneira na qual possivelmente não conseguirá fazer amanhã o trabalho de amanhã, é considerado perdido”. Para este autor refatorar é uma maneira de sair dessa situação. (se achou confusa a citação acima leia com mais calma, parece frase de índio então busque ler pausadamente buscando o gancho e perceba o que está entre linhas sobre afirmação do Dr. Beck. Frases de Drs. são assim mesmo rsrs)
Beck (2000), identifica quatro partes que torna os programas difíceis de trabalhar/modificar:
– Programas que são difíceis de ler à nível de código
– Programas que tem lógica duplicada
– Inclusão de novas funcionalidades: Programas que para inclusão de novas funcionalidades, requerem a alteração de código existente, são difíceis de modificar
– Lógica condicional: Programas com lógica condicionais complexas são difíceis de modificar.
Existe ou não existe vantagem de aplicar refactoring?
Desvantagem
Segundo Fowler (2004) não há experiências em quantidade suficiente para definir onde as limitações se aplicam a técnica de refatoração. Abaixo apresento algumas das áreas citadas por Fowler onde este autor considera que são difíceis (isso não quer dizer que é impossível) de aplicar a técnica de refatoração.
– Banco de dados: É uma área problemática para refatoração. A maioria das aplicações comerciais são altamente acopladas ao esquema do banco de dados que as suporta. Esse é um motivo pelo qual bancos de dados são difíceis de modificar. O outro motivo é a migração de dados, onde alterar o esquema do banco de dados lhe força a migrar os dados, o que pode ser uma tarefa longa e pesada. (Observe que há profissionais, cientistas trabalhando nesse caso, confira a matéria sobre o tema no blog Visão ágil)
–Alterando interface: Um problema com a interface é se estiver sendo usada por código que não é possível encontrar e alterar. Tendo assim se torna uma interface publicada onde não é mais possível alterá-la com segurança e sim apenas modificar a chamada nos métodos que a invocam e isso dificulta o processo de refatoração. Se uma refatoração alterar uma interface publicada tem que conservar tanto a interface antiga quanto a nova e isso leva ao caminho da duplicação de código.
– Linguagens não orientadas a objetos: São mais difíceis de reestruturar, pois fluxos de controle e de dados são fortemente interligados e por causa disso as reestruturações são limitadas a nível de função ou bloco de código.
Há outras áreas citadas por Fowler que você encontra no livro do autor.
Ferramentas para Refatoração
Mas Camilo eu tenho uma duvida, vou ter que refatorar na “mão grande”?
R- Também. Mas não é a única opção.
Você já imaginou refatorando um programa com 2 mil linhas de códigos? É complicado e pode atrasar o projeto certo? Para isso temos as algumas ferramentas automatizadas para refatoração. Antes de apresentar as ferramentas que dão suporte à linguagem Java, veremos o que alguns autores dizem a respeito do uso dessa técnica e no final temos o objetivo geral das ferramentas.
Refatorar com suporte de uma ferramenta automatizada é diferente da refatoração manual. Primeiro que a refatoração à mão consome muito tempo em programas grandes. (Fowler, 2004)
As ferramentas automatizadas diminuem o risco de erros e inconsistência no código, além de poupar um grande trabalho em se tratando de sistemas com centenas ou milhares de linhas de códigos. (Beck,2000)
Segundo Roberts (1997 apud Fowler, 2004, pg.342) com as ferramentas de refatoração automática o projeto se torna mais elástico, já que alterá-lo é muito menos custoso, sendo assim estender o projeto adicionar flexibilidade no futuro sem grandes custos. Para este autor o principal propósito de uma ferramenta de refatoração é permitir ao programador, refatorar código sem ter que testar novamente o programa.
Abaixo a relação das ferramentas de refatoração para Software Java:
List tool:
-XRefactoring (xref-tech)
– IntelliJ IDEA (IntelliJ IDEA)
-IBM Visual Age for Java (IBM)
Abraço a todos! Vou ficando por aqui espero que tenham gostando e até próximo post (o ultimo da série Refactoring).
Thanks!
Referências
IntelliJ IDEA. (s.d.). http://www.jetbrains.com/idea/index.html
IBM. (s.d.). http://www-142.ibm.com
xref-tech. (s.d.). http://www.xref-tech.com/
Fowler (2004)
“Banco de dados: É uma área problemática para refatoração. As maiorias das aplicações”
Acredito que o correto é: “A maioria das aplicações…”
Até.
Camilo,
Essa passagem:
“Para este autor o principal propósito de uma ferramenta de refatoração é permitir ao programador, refatorar código sem ter que testar novamente o programa.”
Vai meio contra aquilo que o próprio Fowler prega no livro todo de Refactoring; que são “baby steps”(pequenas mudanças) seguidos de testes (automatizados se possível).
Eu sei que o uso de “ferramentas” facilita e muito a refatoração(desculpem a tradução), mas dizer que podem ser utilizadas sem precisar testar novamente, acho exagero.
hehe Leonardo! Palavras do Fowler, eu testo mesmo, assim, qualquer refatoração que aplico teste para ver se o programa funciona como antes…
flw! abraço!