Atualmente é muito comum, deparar com desenvolvedores que não gostam do código legado e na grande maioria das situações, até detestam o código escrito em um passado não tão distante assim. Porém, não podemos esquecer que este código legado, é o principal responsável em manter o seu software em funcionamento.
Constantemente nas empresas de software, os desenvolvedores deparam com o processo de refatoração em código legado. Considerando a complexidade dos fragmentos de código existente e o alto custo envolvido no desenvolvimento de software, pode-se dizer que é bastante significativo, conhecer algumas técnicas de refatoração. Porém, este artigo, mostrará alguns fundamentos básicos do processo de refatoração, acompanhado de um exemplo prático, de como isto poderá ser realizado.
Conforme definido por Martin Fowler, refatoração é “uma alteração feita na estrutura interna do software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado sem alterar seu comportamento observável”.
O código legado pode ser refatorado por inúmeras razões, entre elas podemos destacar as seguintes motivações:
+ Código duplicado
+ Método longo
+ Complexidade condicional
+ Classe grande
+ etc
Atualmente os sistemas corporativos possuem diversas características semelhantes e distribuídos em várias linhas de código. Desta forma, muitos problemas se repetem em contextos distintos de um ou vários projetos. Portanto, houve a brilhante idéia de se criar soluções bem elaboradas e consolidadas, de problemas recorrentes, como forma de aprimorar o processo de refatoração de códigos. Estas soluções, foram batizadas de padrões de projeto. Para mais informações a cerca dos Padrões de Projeto existentes, veja a referência [3] citada no final deste artigo.
Será mostrado a seguir, a utilização do padrão de projeto Strategy, como forma de refatorar o problema da complexidade condicional.
O padrão de projeto Strategy, possui basicamente a ideia de possibilitar facilmente a variação do algoritmo a ser utilizado na resolução de um determinado problema problema. Veja a seguir o diagrama de classes que descreve o mesmo.
O cenário mostrado a seguir, se refere ao processo de cálculo de salário de um desenvolvedor de software, que dependendo do seu enquadramento profissional (Jr, Pleno e Senior), o mesmo terá o seu salário reajustado. Veja a seguir, o exemplo de uma forma de realizar esta codificação.
É possível detectar que existe uma variação de formas de calcular o salário, de acordo com o tipo de enquadramento profissional do desenvolvedor, porém, a cada novo tipo de enquadramento profissional, será necessário inserir um novo IF e consequentemente, alterar o método calculaSalario(), que irá impactar em ter que testar todo o método novamente. Sem falar que o código atual, fica bastante verboso e de difícil interpretação. A cada novo IF acrescentado, será aumentado consideravelmente a complexidade condicional. Porém, existe uma forma mais elegante e menos verboso de realizar este procedimento, conforme destacado no diagrama de classes da imagem a seguir.
A partir desta nova forma de codificação, fica claro que a cada nova regra será incluído uma nova classe obedecendo o padrão definido na interface DevSenior, gerando assim uma independência total entre as regras de cada enquadramento funcional, diminuindo consideravelmente o acoplamento destas classes, facilitando assim a variação das regras de cada forma de calcular o salário.
Fontes:
[1] https://www.infoq.com/br/articles/reescrever-ou-refatorar (Acessado em 19/01/2017)
[2] Refatoração para Padrões – Editora Bookman – Kerievsky, Joshua
[3] Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos – Editora Bookman – Gamma, Helm, Johson, Vlissides.