http://www.scriptcase.com.br/
Um amigo me falou de uma ferramenta chamada ScriptCase. Resolvi testar. Aí vai minha impressão.
A primeira vez que tomei ciência da existência de uma ferramenta case foi quando um pessoal lá do Banco (eu era do BB, na época) resolveu criar um programa chamado Gerador Automático de Sistemas (GAS). Esses caras hoje ganham dinheiro detonando sua máquina quando você acessa o BB, Caixa, BRB, Itaú ou outro de uma série de bancos - eles fazem isso com u...m espião chamado GBuster, você deve conhecer. O "G" aí advinha de onde vem.
Agora, a verdade é que o desenvolvimento de sistemas hoje não era pra ser como é. Não era pra ter essa quantidade de linhas de código ocupando boa parte do nosso tempo. O que acontece, não sei se você concorda comigo, é que, por trás das plataformas de código aberto como Java, NodeJS e .NET Core, estão empresas como Oracle, Google e Microsoft. Se não fosse isso, talvez hoje contássemos com plataformas (quase) 100% gráficas para desenvolvimento de sistemas. Aí não precisaríamos de ferramentas "Case".
Porém, não é isso que acontece. Então precisamos de "templates" e frameworks - templates MVC, JSF, jQuery e por aí vai. De outra feita teríamos que ficar copiando e colando código o tempo todo.
As ferramentas Case poderiam, sim suprir uma parte da falta desse ambiente 100% gráfico para desenvolvimento, mas não é isso o que acontece. Veja o caso do ScriptCase:
1. Para gerar totais nas listas, por exemplo, seguindo o próprio tutorial do site do ScriptCase, tive que inserir scripts PHP nos formulários;
2. Para atualizar valores nos campos ao editar o formulários, tive que usar eventos javascript combinados com AJAX e PHP, à mão, ou seja, digitando (ou copiando) os scripts;
3. Os formulários gerados tinham um aspecto Frankstein, ou seja, para dar uma melhoradinha eu tinha que , no mínimo, codificar o CSS deles - o ScriptCase oferece formulários para isso, mas esses formulários não são muito melhores que o notepad;
4. O código PHP gerado possui arquivos de até 4000 linhas sem nenhum comentário. Junte isso ao que disse antes sobre inserir scripts PHP nos eventos javascript e você tem a fórmula para uma manutenção caótica.
5. O código PHP é publicado formulário a formulário, repetindo as libraries a cada geração;
6. Cada publicação inclui todas as libraries, ou seja, cerca de 7000 arquivos.
E por aí vai. A única situação em que entendo se justificar a utilização de uma ferramenta dessas é quando você gera novos bancos de dados todos os dias e precisa alimentar os dados desses bancos de dados a partir de formulários - e não através de ETL ou algo similar. Mesmo assim não sei se a mão-de-obra final é realmente menor.
Se você tem outra percepção, esteja à vontade pra comentar.
Porém, não é isso que acontece. Então precisamos de "templates" e frameworks - templates MVC, JSF, jQuery e por aí vai. De outra feita teríamos que ficar copiando e colando código o tempo todo.
As ferramentas Case poderiam, sim suprir uma parte da falta desse ambiente 100% gráfico para desenvolvimento, mas não é isso o que acontece. Veja o caso do ScriptCase:
1. Para gerar totais nas listas, por exemplo, seguindo o próprio tutorial do site do ScriptCase, tive que inserir scripts PHP nos formulários;
2. Para atualizar valores nos campos ao editar o formulários, tive que usar eventos javascript combinados com AJAX e PHP, à mão, ou seja, digitando (ou copiando) os scripts;
3. Os formulários gerados tinham um aspecto Frankstein, ou seja, para dar uma melhoradinha eu tinha que , no mínimo, codificar o CSS deles - o ScriptCase oferece formulários para isso, mas esses formulários não são muito melhores que o notepad;
4. O código PHP gerado possui arquivos de até 4000 linhas sem nenhum comentário. Junte isso ao que disse antes sobre inserir scripts PHP nos eventos javascript e você tem a fórmula para uma manutenção caótica.
5. O código PHP é publicado formulário a formulário, repetindo as libraries a cada geração;
6. Cada publicação inclui todas as libraries, ou seja, cerca de 7000 arquivos.
E por aí vai. A única situação em que entendo se justificar a utilização de uma ferramenta dessas é quando você gera novos bancos de dados todos os dias e precisa alimentar os dados desses bancos de dados a partir de formulários - e não através de ETL ou algo similar. Mesmo assim não sei se a mão-de-obra final é realmente menor.
Se você tem outra percepção, esteja à vontade pra comentar.
Nenhum comentário:
Postar um comentário