3. Refatoração (última fornada)

3. Refatoração

É o processo de alteração de um sistema de software de modo que o comportamento observável do código não mude, mas que sua estrutura interna seja melhorada. É uma maneira disciplinada de aperfeiçoar o código que minimiza a chance de introdução de falhas. Em essência, refatorar é melhorar o projeto do código após este ter sido escrito. [Fowler, Refatoracão]

Tornar o código mais fácil de entender e modificar, estes são os objetivos diretos da refatoração. Qualquer alteração no código que não vise estes objetivos, não pode ser considerada uma refatoração.

Ao programar, podemos ter código que funciona corretamente, mas que é difícil de entender por uma deficiência qualquer. A refatoração deve necessariamente ajudar a tornar o código mais legível, corrigindo deficiências estruturais, por exemplo.

As técnicas de refatoração incluem, entre outras coisas, metodologias para detectar (“farejar”) possíveis problemas no código.

 

3.1. Refatoração e TDD

O processo de Refatoração depende substancialmente da existência de testes de unidade e aceitação. Sem estes testes, fica muito difícil ter a segurança de que a refatoração foi feita corretamente, ou seja, não modificou o comportamento (funcionalidade) do código, nem inseriu qualquer tipo de erro num código que anteriormente estava funcionalmente correto.

A Refatoração e a TDD são conceitos intimamente relacionados, ou seja, são dependentes e não funcionam de forma ótima, um sem o outro.

TDD pode ser utilizado sem refatoração, mas neste caso torna-se muito difícil fazer algo de qualidade(correto). Isto acontece porque com TDD codifica-se primeiro algo muito simples, apenas o suficiente para passar nos testes previamente escritos. Depois disso, melhora-se o código até que este fique com a qualidade mínima desejada, e a melhor maneira de melhorar um código que está funcionando é via refatoração.

A Refatoração pode ser utilizada sem TDD, mas neste caso há uma grande possibilidade de ocorrerem problemas. Os testes expõem claramente quais as funcionalidades, facilitando o trabalho de mudar a implementação sem alterar o comportamento. Os teste também funcionam como um sistema de monitoramente bastante eficiente, já que alertam quando e onde um erro foi introduzido. Mesmo quando existe a intenção de escrever os testes antes de refatorar, mas não como no TDD, ou seja, deixa-se para escrever os testar depois das funcionalidades, não se está agindo da melhor forma. Primeiro porque é muito comum esquecer de escrever algum dos testes, segundo porque também é comum neste caso, escrever vários testes desnecessários.

Existe o argumento de que essa fortíssima dependência da refatoração em relação aos testes não existe, pois a refatoração foi formalmente definida antes que o conceito de TDD fosse formalizado.

Realmente, a refatoração é mais antiga que o TDD. O primeiro trabalho detalhado e formal sobre refatoração, foi a tese de doutorado de William Opdyke, publicada em 1993. Já a TDD só alcança um patamar mais formal em meados de 2000, o que torna a refatoração formal e correta antes mesmo da TDD existir.

A grande falha do argumento acima é que TDD vai além dos testes. TDD é uma forma disciplinada de desenvolver software claro e que funciona, baseada fundamentalmente em testes automatizados. Porém os testes sempre existiram, não surgiram com a computação e muito menos com a TDD.

Aplicar refatoração de forma disciplinada, em pequenos passos, seguindo corretamente os bons catálogos, garante altos ganhos e poucos erros. Porém, apesar de menor que no desenvolvimento sem refatoração, o risco de ocorrerem erros existe e não pode ser ignorado. Por isso a dependência em relação aos testes automatizados e conseqüentemente, caso deseje-se algo mais robusto, em relação a TDD.

A conclusão é que aplicar refatoração a um sistema seguindo o que manda o TDD é totalmente compatível, além de muito mais fácil e eficiente. E, como visto no capitulo anterior, a recíproca também é verdadeira, ou seja, aplicar TDD a um sistema seguindo o que manda a refatoração é ótimo. São práticas intimamente relacionadas e complementares, pois ambas objetivam tornar o código mais claro (limpo, fácil de entender, manter) e funcional, sendo que com TDD garante-se a funcionalidade contínua e com a refatoração garante-se a clareza do código.

 

3.2. Vantagens Indiretas

A refatoração acaba trazendo outros benefícios, que podem ser considerados indiretos, porque derivam da busca por um código mais fácil de entender e modificar.

:: Projetos Concluídos

Neste caso, a refatoração faz bem para o projeto de duas formas:

1. Melhorando de forma significativa um projeto mal elaborado. Ou seja, ao refatorar continuamente um projeto é possível corrigir problemas graves em sistemas já prontos, caso estes existam. Esta característica contraria uma máxima do desenvolvimento tradicional que diz ser praticamente inviável, do ponto do vista do custo / benefício, corrigir problemas de projeto em softwares concluídos.

2. Impedindo que o projeto se deteriore com as possíveis alterações que tendem a ocorrer ao longo do tempo.

 

:: Projetos em Implementação

Neste caso, a refatoração impede que os problemas presentes no projeto sejam codificados, ou seja, conhecendo-se as técnicas de refatoração, pode-se encontrar e corrigir os possíveis problemas de um projeto durante a própria implementação deste.

 

É claro que quanto pior estiver o projeto, maior a quantidade de refatorações necessárias para torná-lo fácil de entender e modificar. Ou seja, um projeto bem feito só trás benefícios, mas mesmo nos casos em que o projeto é ruim, refatorar continuamente permite detectar e corrigir muitos dos problemas presentes.

 

:: Aprendizado

Refatorar ajuda a tornar mais fácil a tarefa bastante comum de analisar e entender código legado. É possível através da refatoração, progressivamente ir tornando mais claros e fáceis de entender os trechos de código de um sistema legado, à medida que estes forem sendo analisados e entendidos. Nesse processo, é preciso investir intensamente no aprendizado do que o código realmente faz e aplicar este aprendizado no próprio código, através da própria refatoração.

Ou seja, a refatoração permite documentar de forma incremental e através do próprio código, o aprendizado das funcionalidades de um sistema.

Num nível mais alto, a refatoração permite aprender também sobre a estrutura do projeto, já que à medida que trechos de código vão sendo entendidos, fica muito mais fácil entender o projeto como um todo.

 

:: Depuração

Refatorar ajuda na melhora e no entendimento do código, conseqüentemente também ajuda no processo de depuração, pois é muito mais rápido e fácil encontrar uma falha num código claro e fácil de entender.

 

:: Velocidade

Refatorar torna mais rápido desenvolver software por todos os motivos explicados acima. Quando temos código e projeto:

· Mais claros e fáceis de entender;

· Com maior nível de conhecimento pelos desenvolvedores;

· Com menos falhas.

Conseqüentemente teremos maior velocidade de desenvolvimento e manutenção, e é claro, menores custos.

[BECK, 2002]
[FOWLER, 2004]
[HUNT, 2004]
[TELES, 2004]

\o ‘s,
ViniciusAC.

Anúncios

3 comentários sobre “3. Refatoração (última fornada)

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s