REFACTORING – Caso Real e Boas Maneiras: Parte II (Bad Smells)

Para começar, não vou citar uma receita de bolo, mas esses três passos já são um começo para que você refatore sem medo.

I)              Entenda sua regra de negócio: Pelo o que tenho notado, essa etapa não é dita na maioria dos tutoriais e livros, mas pra mim é de suma importância. Como você vai implementar algo em que não conhece ou o conceito não esteja “no sangue”? Bem, o Diniz fala que não tem problema, apenas ele vai levar um tempo maior para resolver o problema. Enfim, eu acho uma etapa importante, pois o raciocínio fluirá mais facilmente e não será preciso muitas voltas para resolver o problema.

II)            Crie testes automatizados para o seu código legado.

III)          Se for necessário criar algo novo,  use TDD.

IV)          REFATORE!

Então, temos os passos, vamos entender nosso problema.

I) Regra de Negócio. O código foi retirado de um sistema que já está em produção, portando é um código verídico(sim, eu consegui fazer!). Eu devia popular um objeto para ele ser repassado para um relatório que calcularia a produtividade de um funcionário. Basicamente é isso. E um dos campos seria preenchido com o valor  de horas da carga horária desse funcionário no intervalo escolhido pelo usuário.

 

Explicando de novo: Eu tenho uma referência de tempo fixa, escolhida pelo usuário que emitiria o relatório. A partir daí eu tenho um intervalo que será considerado, intervalo esse que será calculado a partir do período que é a carga horaria do funcionário. Ufa! Acho que deu pra entender.

Listagem 1.

Kent Back, fala sobre bad smells no seu código referindo a qualquer perda de legibilidade e design no seu código. De cara podemos citar vários. Listaremos alguns mais relevantes. E no próximo tópico, citarei práticas para corrigir esses “fedores”.

Eu lembro que quando revisaram esse código, eu ouvi “nossa mãe do céu!”. Pensei então: “a casa caiu”. E realmente esse não foi uma das minhas melhores performances.

Tá, mas o que diabos é essa cascata de ifs? Somente esse erro, ja desencadeia várias más praticas(e essa ganha de goleada.).  Com isso, vemos a lógica replicada 7 vezes , uma para cada caso que a carga horaria se encaixa no período referencia. Vemos a padronização dos parâmetros em que cada método recebe. São exatamente os mesmos, mudando apenas o comportamento interno entre eles.

Com isso temos um método com um tamanho grande, e na listagem 2, vemos a implementação dos 7 métodos, responsáveis pelos cálculos. E na listagem 3, vemos os métodos verificadores na classe CargaHoraria.java. Da mesma forma, também replicados. Juntando métodos replicados, com um método central que invoca os demais, temos como um resultado uma classe quilométrica. E quem gosta de manter uma classe desse tipo? Imagine que o cálculo precisa de uma pequena modificação. Pois é, temos que corrigir os 7 métodos.

Listagem 2

Dando continuidade, o Guilherme Silveira diz na sua palestra sobre Design de Código, que qualquer código que não caiba na resolução normal do monitor não merece respeito. E exatamente isso acontece, vemos nomes de métodos talvez explicativos até demais, tornando excessivamente extenso. Esses erros ocorrem na listagem 1 e 2.  Como por exemplo o método  DataUtil.getQuantidadeVezesOsDiasDaSemanaApareceramNoPeriodo(produtividadeDTO.getDtInicial(), produtividadeDTO.getDtFinal(), parseList(cargaHoraria, diasList)).doubleValue();

Listagem 3

Aqui merece um sono WTF! Que o Martin cita no inicio do livro clean code. E além de tudo, o método doubleValue() ainda é chamado pra tornar ainda mais feio. Mas calma, posteriormente mostrarei soluções.

II) Testes Automatizados: Já escrevi uma série de posts sobre testes(links), e pela web está repleta de material sobre o assunto. Então, qual garantia que eu tenho de alterar meu código, e ao final da refatoração ele está ainda fazendo o que eu acho que ele deve fazer? Testes baby! Abuse dos testes e verifique se o código que irá ser refatorado possui testes cobrindo as funcionalidades.

III) E então eu preciso adicionar uma funcionalidade nova. Ai que está o problema. Como eu vou fazer isso? Para garantir faça TDD. A Web também está repleta de material sobre o assunto. Pelo menos para você ganhar embasamento teórico. Pois, da teoria para a prática a distância é muito grande. E para você ter um aproveitamento maior, faça Pair Programming, prática do XP.  Foi a partir de um PP que a idéia desse post saiu. E minha maior sorte o me pair era bem mais experiente que eu, então o aprendizado foi muito grande. Recomendo essa técnica.

IV) Fica para o próximo post, onde apontarei soluções.

Link para a parte 1.

About these ads

2 Responses to REFACTORING – Caso Real e Boas Maneiras: Parte II (Bad Smells)

  1. Rafael Ponte disse:

    Oi Yuri,

    Muito bom o post, os dois, acredito que você poderia diminuir ainda mais a quantidade de código ao ponto de deixa-lo mais legível utilizando classes utils, como a DateUtils da commons-lang da Apache.

    Ainda melhor, como você está trabalhando com intervalos (date range) você poderia utilizar a API da Joda Time (http://joda-time.sourceforge.net/key_interval.html) ou mesmo implementar uma abstração como o Fowler indica neste post http://martinfowler.com/eaaDev/Range.html .

    Aconselho a corrigir os links e referências no teu post e claro, mais importante ainda, instale um plugin para wordpress (existe um que se integra com o Gist) para organizar seu código fonte em vez de utilizar imagens.

    Parabéns pelo post.

    • Yuri Adams disse:

      Valeu chefinho..
      “Muito bom o post, os dois, acredito que você poderia diminuir ainda mais a quantidade de código ao ponto de deixa-lo mais legível utilizando classes utils, como a DateUtils da commons-lang da Apache.”
      Pode deixar vou dar uma olhada nessa classe e melhorar mais.

      “Ainda melhor, como você está trabalhando com intervalos (date range) você poderia utilizar a API da Joda Time (http://joda-time.sourceforge.net/key_interval.html) ou mesmo implementar uma abstração como o Fowler indica neste post http://martinfowler.com/eaaDev/Range.html .”

      Não conhecia, valeu pela indicação :).

      “Aconselho a corrigir os links e referências no teu post e claro, mais importante ainda, instale um plugin para wordpress (existe um que se integra com o Gist) para organizar seu código fonte em vez de utilizar imagens.”
      Quanto aos links, vou corrigí-los e adicionar as referências ao final de cada post.
      E em relação ao plugin, infelizmente essa versão free do blog do wordpress não me dá direito de instalar plugins infelizmente. E eu utilizei imagens, pois o editor de texto desse negócio é um LIXO! O tempo que eu ia perder identando o código, eu achei melhor colar as imagens pra até deixar mais legível.

      Obrigado de novo Rafael, abração

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

%d blogueiros gostam disto: