Refatoração é a melhor amiga do programador para que seu projeto não acumule débitos técnicos com o passar do tempo e chegue um momento em que a cada novo pedido do cliente sejam perdidas várias horas de sono preocupado com a grande dificuldade para alterar o software e os prováveis bugs que surgirão.

O propósito da refatoração é exatamente melhorar a legibilidade do código e aumentar a facilidade de modificá-lo, para que esse tipo de situação não venha a acontecer.

Muitos projetos acumulam tantos débitos técnicos que os patrocinadores acabam decidindo abandonar o código existente e desenvolver um novo sistema, na esperança de que esse novo código possibilite o dinamismo e tenha a confiabilidade que seu negócio exige. Então, para garantir que nossos projetos continuem atendendo as necessidades de nossos clientes no futuro, devemos nos preocupar hoje em desenvolver com qualidade e as refatorações são parte desse caminho.

Uma refatoração é uma alteração no código exclusivamente com o propósito de melhorá-lo, uma refatoração nunca deve alterar o comportamento esperado do software. Kent Beck usa a metáfora dos dois chapéus para ilustrar que o desenvolvedor deve vestir um chapéu e manter o foco naquela função. Quando veste o chapéu da refatoração, nunca devem ser introduzidas novas funcionalidades ao software. Já se estiver adicionando funcionalidades, o código existente nunca deve receber alterações que não estejam diretamente relacionadas à nova funcionalidade.

A maioria dos programadores acaba tendo a impressão de que já utiliza refatoração, apenas não tinha consciência disso, mas o diferencial que eles precisam atentar é a disciplina.

As refatorações quando utilizadas corretamente não geram grandes riscos ao projeto, pois são roteiros de execução bem definidos para cada tipo de alteração. Essas alterações normalmente são necessárias em contextos parecidos e sua necessidade pode ser identificada utilizando o que Kent Beck e Martin Fowler chamam de maus cheiros. Maus cheiros são “certas estruturas no código que sugiram a (às vezes elas gritam pela) possibilidade de refatoração”. Não vou me aprofundar explicando cada um deles, detalhes sobre os maus cheiros podem ser encontrados nos sites wiki.java.net, soberit.hut.fi e c2.com. Para exemplificar, cito alguns maus cheiros muito comuns em softwares:

  • Código duplicado
  • Métodos longos
  • Classes grandes
  • Quantidade exagerada de parâmetros
  • Baixa coesão
  • Alto acoplamento

Outro ponto importante para garantir a tranquilidade ao executar refatoração é a existência de testes unitários. O código deve estar funcionando corretamente antes da refatoração e deverá continuar assim após a mesma. A única coisa que pode lhe garantir que essas situações foram atendidas é um conjunto suficiente de testes unitários sendo executados com sucesso antes e após a refatoração.

Mas chega de papo furado e vamos a algumas refatorações. Cada refatoração tem um nome e descreve uma motivação e os passos a serem executados para chegar ao resultado esperado. Existem inúmeras refatorações além das que abordarei abaixo, um catálogo com muitas delas e explicações mais completas pode ser encontrado no livro “Refatoração – Aperfeiçoando o Projeto de Código Existente” de Martin Fowler e no site sourcemaking.com.

Uma das refatorações mais simples de serem feitas é a introdução de variável explicativa. Ela deve ser utilizada quando há uma expressão complexa no código que dificulta seu entendimento. O procedimento a ser feito é armazenar a expressão complexa ou parte dela em uma variável temporária com um nome que seja explicativo.

Outra refatoração, dessa vez entre as mais utilizadas, é a extração de método, utilizada quando há um método muito longo, necessidade de utilizar parte do código de outro método da mesma classe ou para melhorar a legibilidade de um trecho de código. Você deve criar um novo método com um nome explicativo sobre a utilidade do mesmo, mover o trecho de código para esse método e referenciar esse novo método em todos os lugares onde aquele trecho se repetia. O trabalho contrário também é uma refatoração, se chama internalizar método. Quando um método tem boa legibilidade e não é referenciado em mais de um ponto do código, podemos mover seu corpo para dentro do método que o referencia e apagá-lo.

Como último exemplo, cito a refatoração chamada subir método na hierarquia, utilizada quando há uma hierarquia de classes e duas (ou mais) classes irmãs implementam métodos com mesmo comportamento, nesse caso devemos eleger uma dessas implementações, movê-la para a classe pai e remover as demais.

Existem tantas refatorações que é impossível ter na cabeça detalhes de todas elas, mas entender a importância de utilizá-las e como utilizá-las já é suficiente para aumentar significativamente a qualidade do código produzido e possibilitar uma caminhada sem traumas aos projetos nos quais incentivam essas práticas.

zp8497586rq