Atualmente se tornou mais fácil escrever várias linhas de código quando comparado com antigamente, em que a programação não era algo tão trivial. Mas, escrever um código de qualidade ainda é uma tarefa difícil, principalmente pela constante mudança de programadores que terão que dar continuidade ao projeto – ainda mais se tratando de projeto de software grande.
Escrever um código de qualidade não é o suficiente quando ele não está alinhado a uma fácil interpretação. Tal objetivo é possível quando se utiliza a técnica de refatoração, que consiste em modificar a parte visual sem alterar a sua parte funcional, assim como Fowler define: “refatoração é uma técnica disciplinada para reestruturar um corpo de código existente, alterando sua estrutura interna sem alterar seu comportamento externo.”
A técnica de refatoração vai além de deixar apenas o código mais bonito. Em alguns casos a aplicação da técnica pode deixar o código mais rápido por conta da remoção de duplicação de código e de partes que não estão sendo mais utilizadas. Vale ressaltar que, apesar de em alguns casos o código se tornar mais rápido, tal técnica não tem o foco no desempenho, pois pode acontecer também o efeito inverso e o código passar a ser mais lento.
Em grandes projetos em que o código já não está bom, difícil de ser compreendido e ser aplicado, tem-se basicamente duas opções: jogar o código fora ou aplicar a técnica da refatoração. As vantagens de se aplicar a refatoração é que o código se torna expansível mais facilmente, o entendimento do código é melhor por parte de todos os integrantes envolvidos e posteriormente fica mais fácil e menos trabalhoso dar continuidade ao projeto.
Dois dos principais autores que escreveram sobre a técnica, quando e como realizá-la, são: Martin Fowler, que publicou o livro “Refatoração: Aperfeiçoando o projeto de código existente” em 2004, e que mantém um sítio sobre o assunto, onde existem vários informativos sobre a técnica, e Joshua Kerievsky, que em 2008 lançou o livro “Refatoração para Padrões”, juntamente com o próprio Martin Fowler e Ralph Johnson.
A refatoração pode não ser algo trivial para se aplicar, mas o resultado final no código existente é visível e compensadora.
Se você faz (ou já fez) uso da técnica de refatoração (em projetos pessoais ou na empresa que trabalha), deixe suas experiências nos comentários abaixo.
Referências:
KERIEVSKY, Joshua. Refatoração para Padrões. Bookman, 2008.
CHAIM, M. L. Notas de Aula sobre Refatoração de Software. EACH – USP. São Paulo, 2010. Disponível em: http://www.ic.unicamp.br/~eliane/Cursos/Transparencias/Manutencao/Aula25-Refatoring.pdf
FOWLER, Martin. What Is Refactoring?. Disponível em: http://www.refactoring.com.
1 Comentários
Já passei por várias experiências de pegar códigos manipulados por 2 ou 3 pessoas (que as vezes nunca nem conheci), e sempre percebo que refatorar é uma tarefa com alto risco de levar mais tempo do que o planejado. As vezes jogar fora e refazer é o melhor remédio. Essa escolha é sempre difícil e baseada no conhecimento de quem vai pegar essa atividade.