Qualidade na Prática - Enums no lugar de Constantes - Parte II

Dando continuidade à pequena série sobre enums como alternativa às constantes, neste post vamos falar um pouco mais da técnica e de como ela pode deixar o código mais limpo e, consequentemente, mais claro. Um código mais claro facilita a manutenção, que corresponde a maior parte do ciclo de vida de um software.

Qualidade na Prática - Enums no lugar de Constantes - Parte I

No projeto atual, tive a oportunidade de pensar numa situação em que fica claro o poder do Enums no Java. O código que será mostrado é uma síntese do que seria o problema se eu não lançasse mão deste recurso da linguagem Java. Nesta primeira parte, verificaremos o problema e a opção com constantes.

Qualidade na Prática - Verdadeiro Encapsulamento

É interessante verificar como podemos realizar um bom encapsulamento. Um objeto recebe seus atributos através de um construtor e mudanças são apenas permitidas através de envio de mensagens.

Qualidade na Prática - Como Trabalhamos com Exceptions

Neste post vou mostrar como trabalhamos com Exceptions em nossos projetos. Pode parecer um assunto simples, e por este motivo, pode acontecer do desenvolvedor dar pouca ou nenhuma atenção às boas práticas relacionadas. Seguindo algumas regras, que vou expor aqui, podemos evitar muitos contratempos na manutenção.

Qualidade na prática - I

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.