Serie 1:Boas Práticas com Refactoring

Olá Pessoal! Hoje vou falar sobre uma técnica que alguns conhecem  apenas teoricamente, uns usam constantemente e outros que nunca ouviram falar. A  nova série do blog é Refactoring. Ops!O que é  isso?  

Refactoring é o modo de você mudar a estrutura interna de seu software sem alterar seu comportamento observável. Você usa essa técnica quando você quer melhorar a legibilidade do código do software. Mas vale lembrar que Refactoring não usada para consertar erros e sim para prevenção. Com ou sem Refactoring seu software deve funcionar da mesma forma de antes ter aplicado a técnica.

 Nem todos os programadores conhecem  ou sabem aplicar a técnica refactoring, devo confessar que não conhecia a técnica antes de novembro/2007. Mas após uma discussão com um amigo sobre o assunto me interessei sobre o tema, dei inicio aos estudos que virou tema de minha monografia e que passou ser uma pratica constante no desenvolvimento de software. Tornou-se uma mania ao ver um código bagunçado e refatorá-lo. Vale salientar que não sou um experts na técnica me considero um mero estudante e curioso com a técnica. 

Espero que gostem da série Refactoring e que ela venha contribuir no seu ambiente de desenvolvimento de software. 
Let’s GO…

Summary

This article presents the technical of refactoring. Refactoring is one process of the restructure the system without changes your operation. Second Fowler (2004) refactoring into the software more easy of understand and change. One user or a programmer not is capable of say that something changed in the software. The technical of the refactoring help in the legible of code. For Fowler the refactoring is one element-key in process of the developing of software.

Sites/Livros:

http://www.refactoring.com

Livro Fowler

Introdução

Algumas profissionais de T.I acreditam que desenvolver um software é sentar na frente do computador e sair codificando. Já alguns acreditam que desenvolver software deve seguir o mesmo processo de linha de montagem de carro como  no filme tempos modernos.

Mas  bons desenvolvedores de software sabem que esse não  é o caminho correto. Desenvolver software requer planejamento e esse pode ser alterado de acordo com o ciclo de vida do software então o ambiente de desenvolvimento não é algo estático. Quando nasce um novo requisito uma parte do projeto ou todo o projeto passa a sofrer alterações e para executar esses novos requisitos é necessário planejar. Senão você desenvolvedor pode entrar em buraco sem saída com o software.

Para não entramos nesse “buraco” temos a refatoração que vem auxiliar no aperfeiçoamento do código-fonte minimizando as chances de novas falhas serem introduzidas no projeto. Refactoring contribuir para processo evolutivo do software, pois as técnicas de refatoração quando aplicada  de forma correta ao software aumenta consideravelmente seu tempo de vida útil, sua extensibilidade e modularidade.

Definição

Refatoração é o processo de reestruturar o sistema sem alterar suas funcionalidades. Mas Fowler (2004) vai um pouco mais além. Segundo este autor refatoração torna o Software mais fácil de entender e modificar. Para ele, apenas as mudanças feitas para tornar o Software mais fácil de entender são consideradas refatoração. A refatoração não altera o comportamento observável do Software. Esse ainda executa a mesma função de antes. Qualquer usuário seja ele final ou programador não é capaz de dizer que algo mudou.

Fowler defende que a refatoração é um elemento-chave no processo de inteiro desenvolvimento de software. O autor vai além e afirma que um bom projeto vem antes mesmo de sua codificação. Desenvolver software requer planejamento. É importante dizer que  refatorar é um “alicate de prata” que ajuda a manter o código seguro, porém a técnica de refatoração não cura todos os problemas no desenvolvimento de Software, mas é uma ferramenta valiosa.

Refatoramos para:

– Melhorar o projeto do Software: um projeto sem refatoração termina por se deteriorar à medida que as pessoas alteram o código e sem uma compreensão total do projeto, do código, acaba desestruturando. A refatoração é uma forma para estruturar o código;

– Tornar o Software mais fácil de entender a nível de código eliminado códigos duplicados;

– Encontrar falhas rapidamente, a partir do melhoramento do código;

– Programar mais rapidamente;         

Quando Refatorar

Para Fowler (2004) decidir quando começar a refatorar e quando  parar é tão importante quanto à mecânica de refatoração. Explicar como apagar uma variável de instancia ou criar uma hierarquia é questões simples, porém tentar explicar quando deve fazer, não é algo tão consolidado. Em seu livro Fowler apresenta os problemas que podem ser resolvidos por uma refatoração, mas cabe ao analista de sistemas, programador, desenvolvedor a própria percepção sobre quantas variáveis de instâncias são demais, quantas linhas de código em um método são excessivos.  Abaixo vou apresentar algumas das dicas que considerei importantes citadas Kent Beck um dos criadores da Programação Extrema (Extreme Programming – XP), afirma que refatoração deve ser utilizada quando o “código cheira mal” (do inglês “bad smells in code”).

A refatoração deve acontecer quando…

Código duplicado: Quando tem o mesmo código em mais de um lugar, dificultando a manutenção e aumentando o numero de falhas durante a manutenção do Software.

Método longo: Quando um método tem muito código. Quanto maior for o método, mais difícil é entendê-lo.

Classes grandes: Quando uma classe tem muita coisa a fazer, normalmente há existência de muitas variáveis de instâncias.

Comando switch: Os comandos switch essencialmente levam a duplicação. É comum encontrar o mesmo comando switch espalhado por diversos lugares do mesmo programa.

Comentários: Os comentários nos conduzem ao código ruim. Comentários que estão no código sem explicar o porquê, são considerados supérfluos.

Nesse momento você pode estar se perguntado: “Tudo bem vi quando refatorar  e  onde a técnica pode contribuir para meu software, mais o por que de  fazer tudo isso?”

Veja…

Segundo Maia (2004) o custo e a complexidade de se manter um Software são amplamente reconhecidos. Estima-se que cerca de 50% do tempo de um engenheiro de Software é gasto com tarefas de manutenção e compreensão de código e que ao longo das últimas três décadas mais de 60% dos custos de desenvolvimento de Software das organizações foram gastos com manutenção. Refatoração é o processo de mudar um Software de tal forma que melhore a estrutura interna sem, contudo alterar o comportamento externo. Portanto, é uma forma disciplinada de re-organizar o código, minimizando as chances de introduzir erros. Refatorar tem a vantagem de melhorar a estrutura do código, facilitando o reuso e diminuindo o tempo gasto com tarefas de manutenção. O termo refatoração é aplicado a sistemas orientados a objetos; para outros paradigmas de programação esse mesmo processo é descrito como reestruturação.

Percebeu o por quê?

Bom pessoal! Vou ficando por aqui, o assunto Refactoring é um pouco extenso e não pretendo abordar todo em um único post para não ficar cansativo. No próximo mostrarei mais sobre Refactoring  falando sobre as vantagens /desvantagens e as ferramentas  disponíveis.

Um abraço a todos!

Referencias:

Fowler

Maia, P. H. (2004). REFAX:Um arcabouço para desenvolvimento de ferramamentas de refatoração baseado XML. Programa de Pós Graduação em Ciência da Computação . Ceará, Fortaleza: UFC

6 comentários em “Serie 1:Boas Práticas com Refactoring”

  1. Achei muito interessante o que foi dito, teve uma ótima visão de Refactoring, pena que não foi tão a fundo do assunto.
    Esse assunto tem uma amplitude muito grande e como nosso amigo Camilo Lopes ressaltou é de grande importância a ênfase no assunto.
    Tópico curto porem com uma boa quantidade de conteúdo.

  2. olá Eduardo,
    Obrigado por acessar o blog! Essa é a primeira parte sobre Refactoring, conforme falei no post na proxima semana abordarei outros pontos… que se acrescentasse nessa primeira coluna ia ficar muito grande o post.. hehe! A ideia foi dar so um gostinho de quero +.
    Msa refactoring é uma tecnica crucial no ambiente de desenvolvimento porem acredito que de 10 uns 2 ou 3 desenvolvedores usam refactoring de modo padrao.

    flw! Abraço!

  3. Ola Camilo,

    No caso do Switch, eu entendo que ele faça isso. Mas agora nao me vem nenhuma solução alternativa na cabeça, cita uma? Pense num sono a essa hora da noite, rsrsrs.

    Blog favoritado. Quero ver essa sua série sobre refactoring. Boa sorte e abraços!

  4. olá Sergio,
    Obrigado por acessar o blog! Bom segundo Fowler para solução do switch temos o recurso enum :d Que evita a questao de ter codigo duplicados e sim pensarmos eh verdade ja que enum é um tipo de class especial entao posso ter um enum geral para minha aplicacao e importa-lo e dai criar as referencias… e o melhor nao tenho codigo codigo duplicado aonde mudar algo em um switch sair mudando em 20 classes que esta usando o mesmo switch..

    abraço!

Deixe um comentário

O seu endereço de e-mail não será publicado.