Vou iniciar a série prática com um exemplo que está presente na vida de 10 entre 10 desenvolvedores: as estruturas condicionais. Esse exemplo é sobre a estrutura IF. Os códigos estão na linguagem Java.
Vemos if's o tempo todo na nossa vida. Atravessaremos a rua, se o sinal estiver fechado ou não vier carro. O mais interessante é que, normalmente, este teste, está vinculado à uma ação. Sendo assim, definiremos estratégias para as tomadas de decisão. Entretanto, não falarei em termos de OO ainda. Vou mostrar como, proceduralmente, é fácil programar uma estrutura IF mais clara, facilitando a sua vida e de quem vai manter o código.
Os IFs do nosso dia-a-dia estão encapsulados. Quando chegamos na beira de uma rua, não pensamos ou falamos em voz alta: Só vou atravessar quando o sinal fechar ou não vier carros.
Segue um exemplo clássico, ao qual todos os membros da equipe devem ter atenção, e não é nenhuma obra de gênio.
O código inicial, com o desenvolvedor pensando apenas na correção e na robustez:
Abaixo, modularizei as lógicas de teste, melhorando a clareza, facilitando a manutenção. Notem que os comentários desapareceram, pois o código é auto explicativo:
Na próxima fase, eliminei os números mágicos:
A melhora na legibilidade é clara. Possibilitamos, também, o reúso, pois, se algum outro algorítmo precisar testar status, não precisaremos reescrever a lógica. Dessa forma, evitamos a duplicação de código, que muito mal faz para a saúde do desenvolvedor.
Mesmo sem nos preocuparmos com a OO, percebemos, claramente, os benefícios de um código bem escrito. Para desenvolver dessa forma não precisamos ser nenhum doutor de Havard ou consumir muitas horas do projeto.
Esta refatoração mostra a questão do ganho de habilidade com a prática. Será muito difícil codificarmos como na fase 1 novamente, já que este tipo de boa prática é muito fácil implementar de primeira. O que está relacionado ao uso insistente do primeiro código pelos desenvolvedores é a falta da inquietação com os maus cheiros que afloram de sua obra.
Concluindo, esta refatoração não exige horas a mais de projeto, somente vontade do desenvolvedor em sempre codificar melhor.
O livro Refactoring: Improving the Design of Existing Code do Martin Fowler, contribui sobremaneira para este tipo de pensamento no momento de codificar.
