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.
Obrigado! Vou dar uma olhada nesse livro. Como quase tudo, os cursos de computação também tem seus pontos fracos e acredito que seja exatamente nessa área de engenharia de software. O que contribui para a quantidade de projetos que vão para o lixo, como você citou e eu também já vi acontecer.
Abraços.
Muito bom o post, Águas!
Já vi projetos serem jogados no lixo por conta de código mal escrito. Um excelente livro sobre boas práticas de desenvolvimento é o "Clean Code" do Robert C. Martin.
Acho que todo desenvolvedor deveria obrigatoriamente ler esse livro e inclusive deveria ser dado nos cursos de graduação.
Vale cada centavo a leitura 🙂
Abraços!