O que é refatoração de software, quando e onde aplicar?
Esse é um tema de extrema importância no desenvolvimento de software, mas que poucas pessoas têm conhecimento e praticam. Deveria ser incorporado à grade dos cursos de graduação por ser de vital importância na carreira de quem desenvolve software e principalmente de quem quer escrever bons códigos.
No livro Refatoração – Aperfeiçoando o Projeto de Código Existente de Martin Fowler contém uma frase que resume muito bem a boa programação:
“Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender.”
E para escrever bons códigos existem algumas ferramentas e técnicas que nos auxiliam a atingir esse objetivo.
Os testes unitários são uma delas. Ferramenta essencial para se escrever bons códigos. Mas que será tratado em cenas dos próximos capítulos.
A refatoração é outra ferramenta poderosíssima, que nos auxilia muito a escrever bons códigos.
Mas o que é refatoração?
Consiste em alterar um software, para melhorar sua estrutura interna, legibilidade e entendimento, sem alterar seu comportamento externo, ou seja, sem alterar o comportamento observável. Refatoração é a arte de transformar código ruim, longo e confuso, em código limpo, bem projetado e legível.
Na refatoração pequenos trechos de código são alterados pouco a pouco, se houver alguma falha no resultado do software durante o processo, fica fácil de encontrar em qual momento ou qual alteração gerou esta falha possibilitando a correção imediatamente.
Em que momento aplicar a refatoração?
Quando criamos um software só temos uma certeza. De que ele vai mudar. Seja para corrigir uma falha ou para incluir uma funcionalidade nova. Esse é o momento onde devemos aplicar a refatoração. A refatoração pode ser feita durante uma revisão de código. Antes de incluir um novo trecho de código. Antes de alterar um trecho já existente. Portanto se algum código estiver complicado para entender, então ele necessita ser refatorado.
Por que refatorar?
Melhora a qualidade. Ao aplicar a refatoração o código torna-se mais legível, menos complicado de entender;
Refatorar ajuda a encontrar falhas ainda que em tempo de desenvolvimento. Ao refatorar um pequeno trecho existente de código, fica mais fácil de identificar e encontrar uma possível falha;
Refatorar ajuda a programar mais rapidamente. Quando um código já está refatorado, fica mais fácil de incluir uma nova funcionalidade ou de alterá-lo. Também é mais fácil testar um pequeno trecho de código que realiza uma tarefa bem específica do que um trecho que possui diversas funcionalidades.
Quando refatorar?
A Regra de três. A primeira vez que você cria um código, apenas faz. Na segunda, lembra-se de ter feito isso alguma vez, mas o mantém duplicado. Ao realizar pela terceira vez, significa que é hora de refatorar;
Quando acrescentar novas funções, aproveite para olhar o código já existente e se necessário refatorá-lo, antes de acrescentar algo novo;
Quando precisar consertar uma falha. Se existe uma falha é sinal de que algo não está correto no código, muitas vezes além de estar errado o código está complicado de entender. Portando refatore;
Enquanto revisa o código certamente encontrará trechos complicados de se entender, ilegíveis ou que podem ser melhorados. Aproveite para refatorar.
Quando você não deve refatorar?
Quando o código está muito confuso e que a melhor opção seria criá-lo do zero.
Quando o código está cheio de falhas. Ao tentar consertar as falhas pode-se gerar ainda mais problemas. A melhor solução neste caso é fazer novamente. Bem feito.
Enquanto cria os testes. Antes de refatorar, crie testes sólidos para o trecho a ser alterado, garantindo o resultado esperado. Aí então refatore e verifique nos testes se o resultado não foi alterado
Um dos pontos chaves da boa programação e dos princípios da refatoração é utilizar bons nomes que demonstrem a intenção do método ou da classe, assim fica fácil identificar qual seria a função e objetivo do mesmo. Com bons nomes não é necessário decifrar o código para ver o que a classe ou método faz, o seu nome já diz, evitando assim escrever qualquer comentário explicativo.
Martin Fowler criou uma lista de situações que cabem refatoração, denominou isso de “Maus cheiros”, ao identificar um mau cheiro é possível realizar alguns passos e aplicar a refatoração desses trechos códigos.
O tratamento desses maus cheiros serão os temas dos próximos artigos, mas segue a lista com alguns deles:
- Código duplicado;
- Método longo;
- Classes grandes;
- Lista de parâmetros longas;
- Inveja dos dados;
- Campo temporário;
- Comentários;
Esses são apenas alguns dos maus cheiros identificados por Fowler. Para tratá-los são aplicados pequenos passos mas que não alteram o resultado final do trecho de código.
Isso é refatoração. Até breve.
SaaS Senior Software Engineer and Co-Founder at Weesu
5 aMarcelo, parabéns pelo artigo. A refatoração deve sim ser realizada a todo momento, seguida de testes aplicados. Sempre há o que melhorar no código, lógica, etc. Grande abraço.
Consultor na ALTER SOLUTIONS PORTUGAL
7 aolá Marcelo, obrigado por ler o artigo. Realmente a refatoração está diretamente ligada aos testes. Com bons testes é possível aplicar a refatoração e verificar se o resultado externo do código não foi alterado.
Arquiteto de Software e de Soluções
7 aEu tenho hábito de dizer que a verdadeira origem da palavra "refactor" vem de "fatorar de novo". Provavelmente essa explicação está errada (porque nunca pesquisei de verdade), mas na prática é o que acontece. Quando você refatora, você normalmente tem melhores resultados quando divide uma operação grande e confusa em outras menores e especializadas. E sobre quando refatorar, além de tudo o que foi discutido, eu tenho uma regra de ouro: quando você tem um teste unitário confiável que testa a operação refatorada. Não tem um? Bem, ótima ocasião para criar um!