A um ano e meio atrás desenvolvi uma aplicação web com ejb em um projeto que estava orçado para 6 meses. Até aí tudo bem, fizemos o levantamento de requisitos, casos de uso, prototipagem, web design, modelagem e etc. Tudo muito informal e a princípio sem maiores problemas.
Por questões internas (simplesmente pra não dizer que era um projeto novo e, com isso, irritar alguém lá do alto escalão que iria se tocar que a verba para “manutenção” que ele havia liberado na verdade estaria sendo usada para algo que ele achava que já estava feito) essa aplicação iria entrar “embaixo” de uma outra aplicação web com ejb sendo que ambas tratavam de assuntos diferentes.
Logo nos primeiro meses lá, enquanto ainda estava levantando meu sistema, tive a infeliz oportunidade de “ver” essa outra aplicação ao dar uma força pro analista que estava segurando o pepino (hoje um grande amigo meu, figuraça) e olha só o quê eu vi:
- documentação 0;
- usava um “framework” proprietário que um departamento deles lá para pesquisa e desenvolvimento havia escrito e que se tornara obrigatório em todas aplicações na intranet (queria ser um struts mas não ajudava em nada, cheio de gambiarras e erros de conceito que tentava fazer de tudo um pouco nos lugares errados e sempre que alguém precisava alterar não podia pq estava em uma versão mais recente mas ninguém tinha coragem de atualizar);
- curiosamente era o 2o projeto ejb na fábrica (o primeiro havia sido escrito como prova de conceito pro “framework” acima);
- entitys 1.0 de tabelas DB2 gigantes (mais de 50 mil linhas por tabela - uma delas com mais de um milhão de linhas) que haviam sido desenvolvidos a lá receita de bolo pq a equipe não teve tempo de receber treinamento em ejb;
- uma penca de session stateless, entupido de regra de negócio, que nunca ninguém dava remove;
- DAO no meio da história (muito mal escrito, controlando transação que nem o nariz e vira e mexe ferrando com os entitys);
- Toda a equipe de desenvolvimento original debandandara pra outros projetos em clientes externos ou pra outras empresas;
Não precisa dizer que ninguém havia rolado tunning nos servers (só pra inicilizar demorava mais de 4 horas)
Certo, ele estava sozinho e logo de cara vi que o sistema que eu estava desenvolvendo, depois de entregue, ia ser empilhado nas mãos dele. Depois de uma longa sabatina (e acertar o server pra ele que não estava inicializando pq tava estourando os 4gb de memória) voltei pra minha báia.
Em uma das reuniões de requisitos nosso gerente solta um pára-quedas daqueles bem fedorentos: Vamos precisar auditar as tabelas da aplicação nova - aproveita e faz isso na velha tb pois eu sei que ainda não está fazendo (e deveria, já havia sido pago).
Na época eu não sabia (muito menos ele) que os entitys 1.0 disparam atualizações no banco por cada coluna alterada (50 colunas significam 50 comandos update no banco), coisa que vimos da pior forma: depois de passar 4 dias escrevendo triggers para aquela auditoria que deveria ter sido feita (e que, no final das contas, como não dava para “desligar” mais de 30 entitys sem parar a aplicação, ficou por auditar apenas as tabelas manipuladas pelo DAO).
Um mês e meio depois, com tudo que eu precisava em mãos começamos a fase de projeto, eu e 2 desenvolvedores.
Até então sabia que:
- Base de usuários: Américas, todas filias, mais ou menos 200 usuários;
- Disponibilidade: alta, 24x7;
- Volume de dados: médio com crescimento constante, toda semana uma nova planilha de preços com mais ou menos 2000 linhas, mantendo histórico;
04] A periodicidade semanal das planilhas poderia a qq momento se tornar diária em função da variação do dólar; - Haveria necessidade de transação distribuída;
- Ia precisar de uma rotina de backup e expurgo - senão haja banco;
- Não ia querer misturar minha base com o legado. Queria um schema separado pra facilitar e isolar o item 6;
08] 4 servers: 1 web (tomcat com conector), 2 app (WAS 5 alguma coisa) e um db2 7 rodando num Z-Series; - Sem ambiente de homologação;
- Ia ter de usar aquele “framework” maldito;
- Ia ter ejb mesmo (por causa dos itens 2 e 5);
- Não ia poder usar entitys (e nem estava afins - entity 1.0 ? quem ia querer ?) pois a minha aplicação teria de ser auditada e tb porque eu não estava afins de jogar fora meus 4 dias de trigger;
- Pela natureza da aplicação e questões de segurança teria de disponibilizá-la também como serviço;
- Ia ter muita tela de consulta (identificamos mais de 50 no levantamento inicial);
- Só restava um mês e meio para o término da primeira iteração;
- Tinha de ser simples, simples e simples pois não ia ter córum pra dar manuteção sem ficar me pentelhando o juízo de madrugada antes do término do meu contrato.
Apesar da empresa ser a empresa que era não havia ninguém conntrolando riscos e por conseguinte ficou tudo por minha conta mesmo.
O quê eu decidi:
- Ia ter ejb mesmo;
- Ia usar POI pra carregar as planilhas com as listas de preços;
- Ia usar session façades, business interface, pojo e dao;
- CachedRowSet nas 50 consultas pra reduzir o número de value objects e facilitar mundanças nas mesmas;
O quê eu enguli:
- O “Framework”;
- WAS 4;
- Muita pizza, café e cigarro pra fazer o CachedRowSet funcionar no WAS 4 com j9 1.3;
O quê eu “acho” que aprendi:
- Que eu preciso discutir com alguém qdo usar o CachedRowSet;
- Que eu preciso me assegurar que o ambiente de produção vai ter realmente as versões (ipse litrem) dos produtos que me foram indicados;
- que entity 1.0 é pior do que eu imaginava;
Discussão:
- O quê vc faria além? Pq?
- O quê vc faria diferente? Pq?
- O quê vc não faria? Pq?
Conforme o assunto esquentar (se esquentar) vou agregar mais info aqui.
(Pode me ignorar se tiver sem paciência para me explicar essas coisas complicadas…)
