segunda-feira, abril 11, 2005

Meu código, meu precioso código... ou nem tanto.

É quase regra um programador não gostar do código de outros a menos que esse se pareça com o seu e, também, achar seus códigos antigos ruins, o que é completamente natural se vc considerar que evoluiu um bocado desde os tempos em que escreveu aquelas linhas de qualidade duvidosa. Foi justamente essa a sensação que tive quando, muito por acaso, encontrei alguns códigos de um projeto do qual participei em 2000. Os códigos não eram todos meus, mas vou assumir a culpa já que eu poderia ter ajudado a tornar as coisas melhores. Havia tantas más praticas que ativar o PMD, Metrics e FindBugs fez o Eclipse travar.

Os problemas mais comuns eram programação baseada em classes e não em interfaces, blocos condicionais complicados, métodos gritando por refactoring, quebra total do MVC, hierarquias de herança completamente desnecessárias, muito código sem qualquer conhecimento de YAGNI, singletons adoidados, checked exceptions aos montes e outras esquisitices que não vou citar sob o risco de ser apedrejado nas ruas. Mas não dá para negar, minha atenção se voltou principalmente para a total falta de uso de componentes, frameworks ou bibliotecas de classes prontas. Pool de conexões manual, MVC manual, persistência via plain JDBC (não me lembro de ter visto outras aplicações que permitiam tanto SQL Injection), sequer uma ferramenta de automação, como o Ant, por exemplo, era usada.

Então, lá fui eu fazer algumas estatísticas superficiais: entre as minhas 401 classes (401 classe?! Meu Deus!), dividas em 60 pacotes, 131 eram... Exceptions, o que indica graves problemas. Não vou explicar o projeto, mas acreditem, 401 classes são demais e, quando mais de 30% das suas classes são Exceptions, pode acreditar, existe algo de muito errado. Pior ainda, NENHUMA era unchecked e, daí, o errado passa a podre. Outro erro crasso era a total falta de abstração. Mesmo onde existiam interfaces, e elas eram apenas 42, era fácil encontrar algo do tipo:
MinhaInterface bla = new MinhaClasse();
Ou seja, sem uma abstração para criar os objetos, não adianta muito ter interfaces. Mas isso é fichinha perto do método abaixo:

public void setValue() {
if (value == null) {
throw new IllegalArgumentException();
} else {
this.value = value;
}
}

Muito útil, não?! Bom, baseado no lixo que eram meus códigos, ficam algumas dicas: 1) Tente pensar de maneira simples; 2) Tenha em mente YAGNI (401 classes?! Humpf!); 3) Usar frameworks e libraries de terceiros não vai fazer mal algum, então pesquise antes de tentar implementar uma solução caseira; 4) pense um pouco antes de criar uma Exception filha que não acrescenta informação a Exception pai; 5) unchecked exceptions são geralmente uma alternativa interessante; 6) Cuidado com aquelas classes MinhasOperacoesMalucas ou similares, em especial quando elas contem comentários do tipo "LIXÃO DO CODIGO ANTERIOR". E ficam também algumas constatações: 1) Eu aprendi muito em fóruns, mas pesquisar me ensinou mais ainda; 2) mudar do JBuilder para o Eclipse e usar ferramentas para inspeção de codigo me fez bem; 3) ainda bem que inventaram container de IoC e AOP; 4) testes podem até parecer chatos, mas são legais; 5) não tive preguiça de ler documentações e livros como o Effective Java, então, considere se tornar um bom leitor de bons livros.

valeuz...

2 Comentarios:

Anonymous Anônimo disse...

Parabens pelo blog/artigos, nota 10.
So discordo de uma coisa, nem sempre
MinhaInterface bla = new MinhaClasse();
e' uma coisa TAO ruim assim. Se uma parte do codigo precisa criar um objeto mas somente vai passar uma referencia a interface, nao vejo nenhuma grande problema.
Bem, tem gente que diz que o correto seria criar uma Factory, mas ai ta matando o KISS no meu ponto de vista.

6:21 PM  
Blogger Marcos Silva Pereira disse...

Cloves, dentro do corpo de métodos criar os objetos dessa maneira não chega a ser um problema mesmo. Alias, problema seria criar uma factory para isso, como vc disse. Mas, quando são atributos de uma classe, que podem ser expostos, acho que vale a pena sim, prover uma abstração para criar os objetos. <pensa-em-voz-alta>Se bem que as vezes Java tem abstrações até demais.</pensa-em-voz-alta>

valeuz...

6:35 PM  

Postar um comentário

<< Home