Refactoring, uma necessidade

Quantas vezes você já precisou adicionar uma nova funcionalidade àquela opção do sistema que você nem lembrava mais que existia, mas que o seu cliente usa e resolveu solicitar uma modificação? Trata-se de um código complexo, com muitos desvios condicionais, métodos enormes e com muitas variáveis... Daí você pensa: “Tô lascado! Nem lembro mais o que faz esta rotina...” E o pior é que quase sempre que isso ocorre, você não tem nenhum comentário, nem qualquer outro tipo de documentação do código. O que fazer? É aí que entra a refatoração ou refactoring.

Mas, afinal de contas, o que é refactoring?

Segundo Martin Fowler, ‘é uma mudança feita na estrutura interna de um software pra fazê-lo mais fácil de entender e/ou modificar sem, contudo, modificar o seu comportamento externo.’
A refatoração envolve várias coisas:

• Remover de duplicação de código;
• Simplificar uma lógica complexa;
• Tornar claro o objetivo de um trecho de código que antes não era tão claro.
  

Às vezes, pode até mesmo envolver uma simples modificação do nome de uma variável, para tornar claro o seu objetivo ou o que ela contém. Outras vezes, pode ser um conjunto de pequenas modificações com o objetivo de otimizar um projeto de software mas que pode, no entanto, constituir uma grande modificação no final.

Algumas pessoas dizem: “Não se mexe em time que está ganhando”. Mas, contrariando esta afirmação, o processo de refatoração é justamente modificar um código que já está funcionando. Por que? Porque queremos arrumar a casa; porque queremos entender melhor; porque queremos fazer melhor! E, além de tudo, pra tornar a codificação menos cansativa, menos chata. Como se isso não bastasse, ainda contamos com uma grande ajuda para encontrar bugs.

Como saber se é preciso refatorar?

Há uma metáfora muito boa sobre mal-cheiro, que ajuda a entender quando é necessário refatorar. Quando você achar que alguma coisa não está cheirando bem é uma evidência de que precisa dar atenção especial aquele trecho do código. Aqui vai uma lista de alguns mal-cheiros sugeridos por Martin Fowler no seu livro Refactoring: Improving the Design of Existing Code:

• Métodos longos;
• Código duplicado;
• Classes muito longas;
• Uma longa lista de parâmetros, etc.
  

Refatorando

Contudo, para tornar a refatoração segura, você precisa estar munido de um bom conjunto de testes unitários e, além disso, fazer a refatoração em pequenos passos, não esquecendo de, a cada passo, executar os testes para se assegurar de que a sua alteração não quebrou o código. Se quebrou, fica mais fácil retornar e começar de novo.

Atire a primeira pedra quem nunca caiu na armadilha de começar uma alteração e, de repente, foi longe demais para voltar atrás, mesmo diante do arrependimento. Seguir a regra de refatorar em pequenos passos evita cair nessa armadilha.

Mantendo a casa limpa

Já experimentou deixar o seu quarto sem arrumação por um longo período? Quanto mais tempo passa, menos vontade você tem de arrumá-lo e mais difícil se torna a arrumação. Portanto, não deixe para refatorar só quando seu código já tiver um acúmulo de mal-cheiro, quando se tornará mais difícil o processo.

Conclusão

Essa foi apenas uma visão geral sobre refatoração, mas já dá pra ter uma idéia de que precisamos aprender mais. Se desejar, consulte um dos sites abaixo:

http://sourcemaking.com/
http://www.refactoring.com/