As coisas estúpidas feitas quando se trabalha com programação

Este post foi traduzido e alterado deste link:
http://blog.cherouvim.com/the-stupidest-things-ive-done-in-my-programming-job/

Observação: Não fui eu quem escreveu este post. Apenas fiz a tradução e alteração pois achei muito interessante.

As coisas estúpidas feitas quando se trabalho com programação

1. ORM
   • Estupidez
     Construir um framework próprio de ORM.
   • Consequências
     O projeto vira uma bagunça depois de 2 anos de manutenção com gambiarras para passar pelo meu framework ORM desenvolvido e chamar comandos SQL’s customizados.
   • O que deveria ter sido feito?
     Usar hibernate, iBATIS, Cayenne ou outros parecidos.
2. EAV
   • Estupidez
     Usar uma modelagem de banco de dados do tipo Entity-Attribute-Value model.
   • Consequências
     Solução não escalável e impossibilidade de rodar queries úteis no banco de dados.
   • O que deveria ter sido feito?
     Usar uma modelagem de banco de dados normalizada.
3. Acesso ao Banco de dados
   • Estupidez
     Sincronizar o acesso ao banco de dados com uma conexão compartilhada.
   • Consequências
     Escalabilidade zero. Tempos de respostas muito lentos quando mais de 10 usuários estavam utilizando a aplicação.
   • O que deveria ter sido feito?
     Não fazer isto e utilizar um pool de conexões como c3p0 e usar uma “nova” (reutilizada) conexão retornada do pool para cada ciclo de request / response.
4. IDE
   • Estupidez
     Evitar aprender e utilizar uma IDE.
   • Consequências
     Falta de habilidade de compilar, testar e fazer o deploy da aplicação rapidamente e / ou geralmente fazer qualquer coisa útil.
   • O que deveria ter sido feito?
     Familiarizar-me com uma IDE. Ex.: NetBeans, eclipse, etc.
5. Transações
   • Estupidez
     Não usá-las.
   • Consequências
     Corromper os dados da aplicação.
   • O que deveria ter sido feito?
     Usar transações do banco de dados. No MySQL usar InnoDB.
6. Prepared Statements
   • Estupidez
     Usar Statements, concatenação de strings e escapar caracteres para montar queries “seguras”.
   • Consequências
     Possibilidade de SQL Injections na aplicação. É possível logar utilizando por exemplo “or 1=1;delete from users;” e alterar o estado do banco de dados de uma forma muito desagradável.
   • O que deveria ter sido feito?
     Usar Prepared Statements que montam e escapam corretamente as queries dependendo do driver JDBC utilizado.
7. Lógica de Negócios
   • Estupidez
     Fazer isto nos templates (JSP).
   • Consequências
     Aplicação de manutenção difícil.
   • O que deveria ter sido feito?
     Fazer isto utilizando o padrão MVC com servlets ou com um Front Controller. Melhor se utilizar um framework MVC open source como Struts, Spring MVC, etc.