A Refatoração na Informática

Resumo

 A Refatoração é uma prática utilizada por desenvolvedores em todo o mundo que visa a manutenção de softwares com a finalidade de torna-los mais seguros e eficazes, eliminado nessa manutenção os “bad smell” (maus cheiros) que são os erros de código, maiores responsáveis por bugs e lentidão em sistemas.  

As principais causas dos odores são os métodos longos, código duplicado e classes grandes. Na busca pela correção destes erros a verificação manual é a forma encontrada para solucionar o problema, porém este demanda muito tempo e nem sempre os resultados são satisfatórios pois uma busca meramente de observação humana é algo muito simples para a complexidade de alguns códigos muitos grandes como por exemplos códigos com classes e métodos longos e por isso inviabiliza a solução apenas por análise de desenvolvedores fazendo com que seja necessário a criação e a implementação de programas capazes de identificar e corrigir erros  e situações que tornam softwares inviáveis de serem executados.    

Introdução  

Refatoração, como originalmente definido por Martin Fowler e Kent Beck, é:  

Uma alteração feita na estrutura interna do software para torná-lo mais fácil de entender e mais barato para modificar sem alterar seu comportamento observável. É uma forma disciplinada de limpar código que minimiza as chances de introduzir bugs.

    A ideia principal de refatorar está em uma série de pequenas melhorias que mantém a estrutura inicial da regra de negócio realizando a manutenção do código. Cada refatoração faz pouca coisa, mas uma sequência de pequenas refatorações pode fazer uma diferença significativa. Uma vez que cada refatoração tem um escopo pequeno e é localizada existe um baixo risco associado. O sistema se mantém funcionando normalmente após cada refatoração, reduzindo as chances de o sistema sofrer um grande erro durante sua reestruturação.  

Refatorações Comuns:  

Padronizar nomes de variável.  

Encapsular código repetido num método.

Remover parâmetro não utilizado em um método.  

Generalizar um método (Exemplo: raizQuadrada (float x) => raiz (float x, ent.  índice))  

Enxugar comentários extensos.  

Evitar CTRL + C e CTRL + V de métodos e códigos.

O objetivo de refatorar um código seguidamente é manter o custo de manutenção baixo constantemente ao longo de bastante tempo. Refatorações buscam obter simplicidade, clareza e na maioria das vezes um melhor desempenho do código. Sem refatorações o código vai ficando mais desorganizado e quanto maior for a desorganização, mais difícil é de encontrar uma solução, ou seja, desorganização é como uma bola de neve, até atingir o limite em que o código fica praticamente ilegível. O custo da manutenção fica tão alto que a única solução é reescrever novamente toda a parte do código, desde o zero, isso é a última coisa que pretendemos em um desenvolvimento de software, mais que algumas vezes é necessário.  

       A fatoração se torna mais frequente na medida em que o programador vai ficando mais experiente e mais ambientado as rotinas, estas que devem estar sempre bem claras e definidas. Refatorações não devem ser usadas de qualquer modo e a todo o momento, mas quando fica perceptível que determinado pedaço do código está complicado de se ter um entendimento fácil. Bom programador surge só com trabalho, experiência e conhecimento das regras de desenvolvimento. Qualquer programador pode escrever código que seja facilmente entendido pelo computador. Já os bons programadores escrevem código em que os outros possam entender o significado sem a utilização de um “manual”.  

      Quando refatorar o código e encontrar quatro ou mais repetições já é um sinal de que pode ser necessário refatorar. Outro sinal é quando você tem necessidade de comentar partes do código para explicar o que está ocorrendo. Algumas ferramentas como o Netbeans, Eclipse e o Visual Studio já possuem atalhos para as refatorações mais comuns como Renomear, Extrair superclasse, Introduzir objeto parâmetro. A ideia da refatorações traz grandes melhorias na qualidade do código de um programador e na qualidade do software onde muitas vezes contribui muito para um melhor desempenho do software.  

Por Douglas Garcia de Souza  

Artigo do Seminário de Engenharia de Software 2011-2

Revisão Thiarlei Macedo | Fonte Micreiros.com    

Materiais e métodos  

        Apresentamos inicialmente uma análise de problemas de código orientado a objetos. Essa análise, apesar de não poder ser aproveitada diretamente em códigos declarativos como a NCL, deve servir de inspiração para a criação de uma taxonomia de problemas. Posteriormente, discutiremos sobre possíveis abordagens para se escrever regras de inspeção em linguagens baseadas em XML e também seus prós e contras.  

Problemas de qualidade de código    

Martin Fowler e Kent Beck deram uma importante contribuição para o assunto, catalogando diversos problemas de código orientado a objetos (Fowler et al. 1999), denominados por eles como maus cheiros (Bad Smells). Além disso, esse catálogo contém possíveis soluções para cada mau cheiro, chamadas de refatoração (Refactoring). Refatoração é uma modificação feita na estrutura interna de um software para torná-lo mais fácil de se entender e mais barato de se modificar sem alterar seu comportamento externo. O Martin Fowler (Fowler et al. 1999) p. 53 Podemos entender os maus cheiros como uma metáfora normalmente usada para descrever projetos de software ruins e más práticas de programação.  

Os maus cheiros normalmente podem ser vistos como uma indicação de problemas de código que podem ser resolvidos por meio da refatoração. Para cada mau cheiro descrito na literatura (Fowler et al. 1999), existe um detalhamento de quais refatorações podem ser aplicadas a um modo de resolvê- los. Porém, essas refatorações não serão apresentadas por não fazerem parte do escopo deste trabalho. Muitos ambientes de desenvolvimento modernos oferecem refatorações automáticas como uma de suas funcionalidades.  

XML Schemas  

        Para aproveitar melhor o uso de tecnologias XML, que já possuem diversas ferramentas disponíveis e reduzir o esforço de implementação, abordaremos o problema de criar um sistema de críticas para NCL de outra forma. Podemos ver esse problema como o problema de estender um XML Schema, de modo que, este Schema se torne mais expressivo e possa representar, além de restrições sintáticas ou léxicas, também restrições semânticas.  Como exemplo, considere uma restrição semântica dos atributos top, bottom e height de (o mesmo se aplica aos atributos left, right e width). Quando estes três atributos aparecem juntos no mesmo elemento, podem causar inconsistências em relação ao real tamanho. Essa restrição não é possível de ser avaliada usando um XML Schema. Para expressar essa restrição, as opções disponíveis, de nosso conhecimento, são: outra linguagem baseada no Schema, como por exemplo o Schematron; uma linguagem de programação de uso geral; Transformações em Folhas de Estilo XML (XSLT).