Seja um Desenvolvedor, não um liquidificador | uaiHebert (: | Page 9
January 22, 2015 by uaihebert	Boas práticas que ajudam
Muitas pessoas acham que apenas padrões de projeto salvarão seu código de diversos problemas.
Boas práticas ajudam também a manter seu código limpo e saudável. Além dos posts já escritos aqui falando sobre código limpo (01, 02, 03, 04, 05), existem duas boas práticas que eu gostaria de destacar: KISS e DRY.
Pode parecer bobeira, mas é algo bem prático: Keep It Simple, Stupid (mantenha isso simples, mané). Existem outras traduções para essa sigla, mas essa transmite bem a mensagem.
Por que procuramos soluções complicadas ao invés de ir para a mais simples? Por que não usar soluções prontas ao invés de criar a nossa?
Por diversas vezes já encontrei um código como o abaixo espalhado pelo projeto:
if (value == null || value.trim().equals("")) {
Sendo que poderíamos simplesmente utilizar a biblioteca StringUtil da Apache. Com ela bastaria fazer:
A vantagem de usarmos essas bibliotecas é que com elas podemos reduzir a quantidade de código e aumentar a coesão do nosso código. A Apache tem seu código aberto, testado e utilizado por diversos desenvolvedores por todo mundo. É um código de confiança.
Sempre procure a solução mais simples para seu problema. Se você tem uma tarefa que é:
Realizar pagamento consumindo webservice
Ao invés de simplesmente começar a codificar, por que não fatiar essa tarefa? Qual a necessidade de executar uma tarefa gigante se podemos diminuí-la em pequenas tarefas, reduzindo assim o impacto no código do projeto e também de um merge? Poderíamos ter algo como:
Criar o Pagamento no DB
Realizar o pagamento consumindo webservice
Atualizar Pagamento no DB
Um último exemplo foi um código que encontrei:
customerTO.setBirthDay((customer.getBirthDay() != null) ? customer.getBirthDay() : null);
Qual o motivo desse if? Não bastaria fazer customerTO.setBirthDay(customer.getBirthDay());?
"Don't Repeat Yourself" ou "Não se Repita" em português é uma abordagem simples e prática no mundo OO. Se você já teve a ligeira impressão de que você está rescrevendo algo, vale a pena parar e procurar onde está o código já escrito.
O problema de repetir código é justamente a duplicação de alguma regra, e caso haja a necessidade de correção de bug nem todos os códigos duplicados serão corrigidos.
Separar o código repetido em classes com nome "Util", "Helper", "Factory", "Builder" já dará um forte indício de que seu código está sendo reutilizado para quem for dar manutenção no sistema.