Introdução

Algumas pessoas acreditam que desenvolver software é simplesmente sentar na frente no computador e iniciar o processo de codificação. Outras acreditam fielmente que fazer software é como construir um carro – linha de montagem. Quem da área de desenvolvimento nunca leu algo parecido?!

Como em outras áreas, desenvolver software requer planejamento. Durante ciclo de vida da aplicação, as necessidades mudam, fazendo com que seja elaborado um novo planejamento.

Já deu para notar que, não existe um planejamento fixo em um ambiente de desenvolvimento de sw, isto é, não é como em uma linha de montagem – onde as tarefas são bem definidas e não mudam com frequência -, a medida que novos requisitos surgem, uma parte do projeto, ou senão todo o projeto, passa a sofrer alterações e para executá-las é necessário planejar.

Simples modificações em um sistema de software podem ferir a integridade da aplicação em relação ao modelo proposto inicialmente – sejam as modificações feitas sem planejamento ou sem compreensão do requisito. Ou seja, o comportamento observável do sistema muda.

Neste contexto, a refatoração auxilia no aperfeiçoamento do código-fonte minimizando as chances de novas falhas serem introduzidas no projeto. Entretanto, ela está ligada, também, ao processo evolutivo do software, pois quando utilizadas as técnicas de refatoração de forma correta, o software aumenta consideravelmente seu tempo de vida útil, sua extensibilidade e modularidade.

2. Definição

Fowler (2004) prega que, a refatoração somente é bem executada quando os passos que a antecedem são bem definidos.

“Com a refatoração, você descobre que o ponto de equilíbrio do trabalho muda. Descobre que o projeto, em vez de acontecer todo no início, ocorre continuamente durante o desenvolvimento. Aprende, com a construção do sistema, a como melhorar o projeto. A interação resultante leva a um programa que permanece bom à medida que o desenvolvimento continua.” (FOWLER, 2004)

A refatoração, portanto, é um processo de alteração de código-fonte de um sistema de software de modo que o comportamento observável não mude, mas que sua estrutura interna seja aperfeiçoada. Em essência, quando se usa esse processo, tende-se a melhorar o código-fonte, mesmo após este já ter sido escrito. (Fowler, 2004)

Folwer advoga 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.


3. Histórico

As primeiras publicações sobre o tema se deram ao longo da elaboração de uma metodologia de desenvolvimento de software voltado a um ambiente orientado a objetos. A metodologia em questão é conhecida como Programação Extrema (Extreme Programming – XP).


4. Testes Automatizados

É de praxe que desenvolvedores de sistema possuam a necessidade de fazer alterações em projetos que em andamento. Em muitos casos, essas alterações são realizadas sem qualquer formalismo, elevando, assim, o índice de complexidade do código-fonte do sistema. Código complexo, difícil de ser compreendido e modificado pode levar um projeto de software ao fracasso. Alterações mal executadas podem mudar totalmente o comportamento inicial de um sistema.

A pré-condição essencial parar refatorar é a existência de testes automatizados. Uma das maneiras mais eficientes de se garantir a integridade do comportamento externo do sistema de software é através do planejamento de casos de testes bem definidos. Planejar testes de qualidade aumenta, consideravelmente, a velocidade de programação, independentemente de se utilizar técnicas de refatoração, visto que, grande parte do tempo gasto no desenvolvimento de um sistema é no momento de se testar o software e, tendo testes automáticos esse esforço de tempo seria reduzido ao extremo.

Até mesmo para elaborar testes, deve haver um planejamento (utilizar técnicas como: menor valor absoluto, maior valor absoluto, dentre outras). Teste bem elaborados podem preservar a semântica do programa. Alguns desenvolvedores pregam que os testes devam ser planejados antes mesmo que uma linha de código tenha sido implementada. Dessa forma, o desenvolvedor se questiona sobre a necessidade de se alterar alguma coisa no requisito.

Fowler (2004) também prega que: “Um conjunto bem definido de testes é um poderoso detector de falhas que diminui bastante o tempo que se levaria para encontrá-las.”

Existem enumeras ferramentas que nos auxiliam na criação de testes, o que torna mais simples utilizar os testes como um artefato de apoio na construção de sistemas de software.

5. Quando Refatorar

Há situações em que o código está tão confuso que seria mais fácil reescrevê-lo, novamente, do que refatorá-lo. Um sinal claro da necessidade de reescrever ocorre quando o código simplesmente não funciona ou funciona de forma inesperada. Somente se descobre isso à medida em que o sistema é testado e vendo que o código está tão cheio de falhas que não é possível estabilizá-lo. Deve ser ressaltado que um código tem que funcionar corretamente na maior parte do tempo antes de ser refatorado.

Outra situação em que se deve evitar a refatoração há quando estiver próximo de um prazo final. Nesse ponto, o ganho de produtividade gerado pela refatoração apareceria após o prazo final e seria, portanto, tarde demais.

Antes de refatorar é aconselhável que se já tenha em mãos um sólido plano de testes de modo a comprovar a integridade do resultado obtido ao final da refatoração executada. Se não possuir um conjunto de testes, evite refatorar.

5.1 Bad-Smells

Kent Beck (apud Fowler, 2004), 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”).

Definido por Martin Fowler e Kent Beck, o termo “bad-smell” (maus cheiros) se refere às características encontradas nas estruturas de códigos que devem ser refatorados.

Os “bad-smells” que podem ser encontrado no livro do Martin Fowler (2004) são:

* Código Duplicado;

* Método Longo;

* Classes Grandes;

* Lista de Parâmetros Longa;

* Alteração Divergente;

* Cirurgia com Rifle

* Grupos de Dados;

* Inveja dos Dados;

* Obsessão Primitiva;

* Comandos Switch;

* Hierarquias Paralelas de Herança;

* Classe Ociosa;

* Generalidade Especulativa;

* Campo Temporário;

* Cadeias de Mensagens;

* Intermediário;

* Intimidade Inadequada;

* Classes Alternativas com Interfaces Diferentes;

* Biblioteca de Classes Incompleta

* Classes de Dados;

* Herança Recusada;

* Comentários.

6. Utilização

Para aplicar a refatoração, um conjunto de passos devem estar bem definidos. Tais como:

* Identificar o local a ser refatorado;

* Definir as refatorações a serem implementadas;

* Garantir a integridade do comportamento observável;

* Aplicar as refatoraçoes escolhidas;

* Confirmar a preservação do comportamento observável após a implementação da refatoração.

Através de um exemplo prático, pode-se analisar o funcionamento de algumas técnicas de refatoração.

7. Vantagens e Desvantagens

7.1 Vantagens:

A refatoração detém inúmeras vantagens, quando aplicada corretamente. Dentre alguns propósitos vantajosos, apresentados por Fowler (2004), encontram-se:

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

7.2 Desvantagens

Martin Fowler dedica uma seção de seu livro para apresentar os problemas levantados quando fazemos refatoração. “Quando você aprende uma técnica nova que aumenta bastante sua produtividade, é duro ver quando ela não se aplica. Normalmente você a aprende dentro de um contexto específico, em apenas um simples projeto. É difícil ver o que faz a técnica ser menos efetiva, até mesmo prejudicial” • (FOWLER, 2004).

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

É difícil apontar limitações sobre a utilização de refatoração quando suas técnicas são aplicadas em sistemas de software. As desvantagens conhecidas foram encontradas a partir de experimentos e, é através da experimentação que se espera, cada vez mais, que novas desvantagens sejam encontradas para que se possa buscar soluções, aperfeiçoá-las e saber quando não se deve aplicá-las.

Dentre as desvantagens apresentadas por Martin Fowler encontram-se:

* Banco de Dados;

* Alterando interfaces;

Mesmo apresentando limitações, a utilização da refatoração não é invalidada, até mesmo porque as vantagens obtidas são extremamente válidas.

Conclusão

Refatoração de código vem se popularizando cada vez mais entre os desenvolvedores de software. Mas, não se trata de um assunto novo, sob a ótica de atividade de manutenção de código fonte. O constante crescimento de adeptos da refatoração consiste no fato de ser um artefato para desenvolvimento bastante poderoso e, ao mesmo tempo, um artefato para manutenção de códigos já existentes.

Fonte de leitura: Martin Fowler

Screencast: Refatoração na Prática