Discussão:GeneXus

O conteúdo da página não é suportado noutras línguas.
Adicionar tópico
Origem: Wikipédia, a enciclopédia livre.

Isso é um artigo ou uma pagina de propaganda do negocio?


Gostaria de explicar aos editores anteriores do artigo qual foi minha motivação ao modificá-lo de forma tão profunda.

Sob meu ponto de vista, entendo que um artigo da Wikipédia existe para informar algo. E para tanto, deve se basear em fatos.

Se observarmos o mesmo artigo em outras línguas, veremos que eles visam apenas informar o que é o produto e quais as suas características. Em nenhum deles uma guerra como encontramos no artigo que existia.

Em função disto, removi do artigo as sessões de Prós e Contras pois me pareceram que existiam apenas para servir de painel de debates.

Entrementes, para que este conteúdo não se perca, gostaria de inserir aqui minhas considerações pessoais sobre ele.

Corpo Principal[editar código-fonte]

O parágrafo onde se diz que a nova versão implementa suporte a C#, JAVA e Ruby está incorreto. Os geradores C# e Java já são suportados. Apenas o gerador Ruby é novo.

No tópico Prós temos uma colocação questionável:

Onde se diz: "desde que as aplicações sejam apenas simples manipuladoras de base de dados", temos uma visão bastante simplória do que se pode realizar com a ferramenta. Na verdade, se pode construir aplicações com diversos graus de complexidade e mesmo integrá-las a outras se necessário.

É importante notar que a ferramenta se propõe a criar aplicações corporativas com ênfase na utilização de banco de dados. Ou seja, não é uma ferramenta generalista. Assim, construir um GED em GeneXus (como citado no texto) é impossível se utilizarmos apenas os recursos nativos. Contudo, isto é um despropósito, já que este não é o foco da ferramenta.

Já o tópico Contras merece uma discussão bastante detalhada:

Contra 1[editar código-fonte]

A legibilidade do código gerado é nula.

Réplica: A manutenção das aplicações GeneXus é realizada diretamente na base de conhecimento. O código fonte gerado é o resultado final do trabalho da ferramenta. Em momento algum o desenvolvedor deve utilizar o código fonte gerado para alguma outra atividade que não seja compilá-lo. Assim, posto que o código fonte gerado é apenas um subproduto do processo, a legibilidade é totalmente irrelevante. Utilizar este argumento como um "contra" não é válido.


Contra 2[editar código-fonte]

Genexus não dispõe de uma forma inteligente de integração com tecnologias de terceiros, algumas vezes é necessário ler o código gerado para que possa inserir código nativo dentro do Genexus em concordância com o código gerado.

Réplica: GeneXus possui várias formas de se realizar a integração com tecnologias de terceiros. Isto pode ser feito através de componentes ActiveX, DLLs .NET, classes JAVA, etc. Existe inclusive a possibilidade (apesar de não ser recomendada) de se inserir código nativo diretamente nos objetos da base de conhecimento. Efetivamente, em nenhuma hipótese é necessário ler o código gerado. Assim, a afirmativa é falsa.


Contra 3[editar código-fonte]

Não há uma ferramenta para fazer DEBUG do código Genexus, o que causa dificuldade/demora no diagnóstico de erros.

Réplica: Para o desenvolvedor que não queira utilizar o DEBUG nativo de uma das linguagens geradas, existe a possibilidade de adquirir produtos de terceiros que realizam esta função no GeneXus (por exemplo DebuGX - http://www.debugx.com.ar). Portanto, a afirmativa acima não é verdadeira.


Contra 4[editar código-fonte]

Não oferece controle de versão do código.

Réplica: De fato a ferramenta em sua atual versão (9.0) não conta com controle nativo de versão do código. Contudo, existem ferramentas de terceiros para este fim (por exemplo GXTend - http://gxtend.accendo-it.com/website/html/br_present.html). Assim, a afirmativa também é falsa. A partir da versão X Ev 1 já é possível controlar versões com Genexus. Assim, a afirmativa é falsa.

Contra 5[editar código-fonte]

A base de conhecimento (Knowledge Base) do GeneXus não é uma ferramenta de geração de conhecimento padrão, como UML ou mesmo como um DER, ou seja, até mesmo o modo de criação das estruturas é proprietário.

Réplica: De fato, a base de conhecimento do GeneXus é proprietária. Contudo, isto não é um problema. É uma característica. Por outro lado, nada impede que o desenvolvedor lance mão de ferramentas auxiliares para desenvolver os artefatos de engenharia de software necessários. A propósito, a ferramenta gera automaticamente o DER do modelo de dados.


Contra 6[editar código-fonte]

A aparência de uma tela Gerada pelo Genexus é feia, mesmo usando o editor de estilos ajuda a amenizar, mas não resolve o problema. Editor de Telas WEB é precário e muitas vezes é necessário fazer alterações no editor HTML para se conseguir o atingir resultado esperado.

Réplica: A aparência das telas padrão do GeneXus não preza pela beleza, e sim, pela funcionalidade. De fato, para telas GUI temos recursos limitados, mas isto não impede que um desenvolvedor com criatividade crie soluções atraentes. Por outro lado, o editor HTML da ferramenta se comporta de maneira adequada para o que se propõe. Efetuar alterações diretamente no HTML não é uma prática usual e apesar de possível, não é incentivada. Ainda, utilizando-se da ferramenta "Patterns" que faz parte do conjunto do GeneXus, o desenvolvedor pode criar soluções bonitas e esteticamente atraentes com um mínimo de esforço. Ou seja, o bom conhecimento da ferramenta e seus recursos permitem a criação de aplicações que não deixam nada a desejar em relação às aplicações montadas manualmente.


Contra 7[editar código-fonte]

A implementação AJAX é lastimável, parece que não tem AJAX. O AJAX é usado somente para validar campos e preencher combobox, vide [1] e comparem com [2].

Réplica: De fato, a implementação AJAX da versão 9.0 é limitada. Mas, por outro lado, esta implementação é realizada de forma automática, o que evita que o desenvolvedor tenha de aprender mais esta tecnologia. Também é sabido que a versão 10 (codinome Rocha) implementa muito mais recursos de AJAX e ainda de forma automática. Contudo, o que deve ser levado em consideração não é o quão sofisticada é a implementação de AJAX e sim, o fato de ser implementado de forma automática sem nenhum esforço adicional do desenvolvedor.

Também gostaria de destacar que o termo lastimável utilizado pelo autor, denota uma visão pessoal e emotiva. Não creio que esta seja a forma correta de descrever uma característica do produto.


Contra 8[editar código-fonte]

O vendedor Genexus diz: O Genexus trabalha com uma grande variedade de plataformas, linguagens e bancos de dados. A verdade é que a migração de uma plataforma para uma outra é praticamente inviável e o motivo é porque o Genexus é muito limitado e é muito comum que um sistema Genexus recorra ao código nativo da plataforma para fazer o trabalho que ele não faz e todo código nativo terá que ser reescrito na nova plataforma. Vejamos um exemplo bem simples: Tela de Login: Genexus não tem uma função que calcula Hash e é impossível implementar um algoritmo de Hash no genexus(Não há estruturas de dados que permita).

Réplica: A utilização de código nativo "embutido" em aplicações GeneXus não é recomendável. É óbvio que qualquer implementação manual em uma das linguagens geradas pela ferramenta terá que ser reescrita caso ocorra a migração para outra linguagem.

Ainda, o que encontramos em algumas situações é o abuso da utilização de código fonte de uma linguagem em particular diretamente na base de conhecimento. Isto realmente é um complicador caso se queira mudar a linguagem.

A afirmação de que é muito comum que se recorra ao código nativo me parece um tanto quanto exagerada. Com o conhecimento adequado da ferramenta, isto não ocorre.

Neste caso, vou me permitir fazer uso de minha experiência prática. Em dez anos utilizando a ferramenta, para os mais diversos tipos de aplicações, com raríssimas exceções, tive que lançar mão de rotinas escritas na linguagem A ou B. Ainda, em todos estes casos, a opção foi a utilização do recurso de integração de rotinas externas e não de implementação de código fonte diretamente nos objetos GeneXus.


Contra 9[editar código-fonte]

Sendo seu código ilegível, o GeneXus acaba por ser uma ferramenta repetitiva, considerando que você terá que voltar ao programa e carregar as milhares de designs e prototypes cada vez que quiser fazer uma alteração mínima no código.

Réplica: Infelizmente, não é possível compreender a intenção do autor ao inserir este contra. O texto carece de clareza.


Contra 10[editar código-fonte]

Conforme as aplicações vão ficando mais complexas, a dificuldade de manutenção vai se tornando muito maior com Genexus do que seria com um SDK.

Réplica: Um dos elementos que torna a ferramenta muito poderosa é justamente a capacidade que temos de gerenciar aplicações complexas com bastante facilidade. Os browsers que existem na ferramenta torna bastante fácil e rápida a localização e edição de elementos do sistema, com um mínimo de esforço por parte do desenvolvedor.

Mas, um sistema mal desenhado e mal escrito irá se tornar cada vez mais complexo para se manter, independentemente da ferramenta ou SDK utilizado.


Contra 11[editar código-fonte]

Genexus estimula muito o improviso do desenvolvedor para que uma determinada funcionalidade que o Genexus não tem passe a funcionar de acordo com o cliente. Tendo em vista que é uma ferramenta RAD e tem o seu Domínio de Funcionalidades muito restrito.

Réplica: A afirmação acima é no mínimo controversa. Obviamente, qualquer coisa que fuja do domínio da funcionalidade da ferramenta implicará na criação de alguma solução alternativa. Todavia, afirmar que a ferramenta estimula muito o improviso é um exagero.


Contra 12[editar código-fonte]

O Help do Genexus é precário, e pelo fato de ser uma ferramenta muito pouco usada(cerca de 5.000 clientes), há muita dificuldade em encontrar documentação ou suporte em forums para alguns problemas.

Réplica: De fato, a documentação do produto é um ponto a ser melhorado. Temos acompanhado o esforço do fabricante em suprir esta necessidade e vários resultados positivos já foram alcançados. Existe uma documentação razoável disponível aos desenvolvedores e o suporte técnico da ferramenta funciona adequadamente. Apenas para constar, segue uma lista de sites onde se pode encontrar material sobre a ferramenta:

  • Site Oficial do GeneXus: http://www.genexus.com
  • Site Técnico do GeneXus: http://www.gxtechnical.com
  • Site Contendo a Documentação do GeneXus: http://www.gxtechnical.com/gxdl
  • Site Contendo a Documentação do Genexus 9.0 e versões Beta: http://www.gxtechnical.com/wiki
  • Site Publico de Código Livre GeneXus (GxOpen): http://www.gxopen.com
  • Site Oficial do Genexus Brasil: http://www.genexus.com.br
  • Site Técnico da ARTech Brasil: http://br.gxtechnical.com

    Contra 13[editar código-fonte]

    A geração do banco de dados é simplesmente a geração de um repositório de dados, o seu SGBD será subutilizado, pois não é criada integridade referencial, nem gera procedures, nem triggers, nem nada que facilite a manutenção pelo administrador. Seu sistema Genexus vai se basear na pior base possível para desenvolvimento, não vai ser nem pelo MySQL, vai ser pelo padrão XBase.

    Réplica: Esta me parece uma afirmação tendenciosa e parcial, pautada pelo desconhecimento das características da ferramenta. Vou me ater apenas aos fatos:

  • A ferramenta cria as tabelas no banco de dados, traduzindo uma definição de alto nível da característica das colunas para a implementação ideal do tipo de dados do SGBD escolhido.
  • A integridade referencial (ao contrário do que é afirmado) é criada automaticamente no banco de dados. Existe uma propriedade onde o analista pode desligá-la ou não. De qualquer forma, no mínimo a integridade referencial é implementada no código.
  • Os índices necessários são criados automaticamente. Caso o banco não possua a definição da cláusula "Primary Key" ela será implementada como um índice com unicidade.
  • Alterações na estrutura de dados são gerenciadas automaticamente pela ferramenta, a qual se encarrega de realizar as modificações necessárias nos objetos do banco de dados.
  • A ferramenta, na medida do possível, cria os programas para realizar a conversão de dados em caso de mudanças de estrutura, tipo de dados, etc.
  • É permitido que uma aplicação, de forma praticamente transparente, utilize simultaneamente qualquer um dos bancos de dados suportados.
  • A ferramenta não implementa a geração de triggers e stored procedures.
    Resumindo: Considerar que é "nada", gerar as tabelas, os índices, implementar as regras de integridade referencial, gerenciar automaticamente as mudanças de estrutura de dados, fazer a conversão de dados, permitir a integração de bases de dados heterogêneas; denota desconhecimento das características da ferramenta.

    Contra 14[editar código-fonte]

    O processo de reorganização da base de dados não é inteligente. Vejamos: Suponha que você deseje fazer uma alteração na estrutura de uma transação, como por exemplo criar um novo atributo. Primeiramente todos os desenvolvedores que estiverem trabalhando na mesma KB serão obrigados a fechar a KB, pois Genexus não permite que haja mais de um usuário usando a KB quando a KB entrar em modo de Desing. Feita a alteração, o Genexus irá fazer a reorganização da base. A simples criação de um campo na transação causará as seguintes operações na base de dados: 1. Criar tabela temporária com a estrutura da tabela antiga mais o novo campo; 2. Migrar os dados da tabela antiga pra tabela temporária; 3. Deleta a tabela antiga; 4. Renomeia a tabela temporária para o nome da tabela antiga. Imagine esta operação em uma tabela com milhões de registros. Será um processo muito lento.

    Réplica: Várias das restrições citadas são reais, mas elas não mais existirão na versão 10 do produto. Sugiro ao autor que verifique a documentação da versão.

    Também podemos discutir outro aspecto do ponto de vista do autor. Criar uma nova tabela e migrar os dados é uma forma bastante segura de garantir que não haverá perda de dados. Contudo, esta segurança tem um preço.


    Contra 15[editar código-fonte]

    É comum ocorrer BUGs no código gerado pelo Genexus, e a solução proposta pelos suporte Genexus é na maioria das vezes é fazer um Build All. Fazendo uma analogia, é como se fosse quando no Windows começa a ocorrer alguns problemas e a solução dada pelo técnico é Formatar tudo. O processo de Build All é nada mais é que especificar todos os objetos, gerar todos os códigos e compilar tudo. Mesmo em sistemas de pequeno porte(poucos objetos) esta operação é muito lenta, podendo durar cerca de 1h ou mais.

    Réplica: A operação de BUILD ALL não deve ser utilizada de forma indiscriminada. Existe um mito na comunidade de que esta é a solução para todos os males. Pura lenda.

    Também é válido destacar que a velocidade da geração do código fonte é condicionada por vários fatores - capacidade de processamento do equipamento, memória disponível, disponibilidade e carga de rede, tamanho da base de conhecimento, etc. Afirmar que a geração "é muito lenta" denota uma visão particular do autor.


    Contra 16[editar código-fonte]

    Não é possível construir um consulta a base de dados em tempo de execução. As consultas Genexus só podem ser criadas em tempo de compilação.

    Réplica: Realmente não é possível construir uma consulta totalmente nova em tempo de execução. É possível sim, condicionar a ordenação e critérios de filtro de uma consulta. Vale destacar que para endereçar esta necessidade existe a ferramenta GxQuery.


    Contra 17[editar código-fonte]

    As configurações de acesso a base de dados só podem ser definidas em tempo de compilação. Se o seu banco mudar de servidor, por exemplo, será necessário compilar novamente a aplicação Genexus.

    Réplica: Novamente temos uma afirmação que não tem fundamento. O data type DBConnection existe justamente para realizarmos estas modificações em tempo de execução. Efetivamente, não é necessário recompilara a aplicação.


    Contra 18[editar código-fonte]

    O código gerado é pessimamente otimizado, para não dizer que inexiste qualquer tipo de otimização.

    Réplica: Realmente, o código gerado por uma ferramenta (e arrisco dizer qualquer ferramenta) geralmente não é tão bom ou tão otimizado quanto o código escrito por um programador experiente. Mas, vamos nos ater ao fatos. O código gerado realiza as funções para as quais se propõe. Na prática, temos casos de empresas com sistemas dos mais variados tamanhos, com bancos de dados contendo milhões de registros que se sentem confortáveis com a performance apresentada pelas aplicações geradas.

    Por outro lado, se um programador demorar um mês para escrever uma rotina que é o estado da arte em codificação e a ferramenta demorar um dia para gerar algo similar, teremos vários ganhos reais - resposta rápida à necessidade do negócio, diminuição do time-to-market, melhor aproveitamento da mão-de-obra, etc.

    Preocupa-me muito palavras como (sic)"pessimamente" ou "inexiste". Gostaria de saber quais foram os critérios utilizados para se chegar a esta conclusão.


    Contra 19[editar código-fonte]

    O Código gerado pelo Genexus é o produto final do processo de desenvolvimento. Isso impossibilita a reutilização do código ou de qualquer parte dele para outras finalidades.

    Réplica: Vamos nos ater ao foco da ferramenta. O código fonte, conforme citado, é o produto final do desenvolvimento. Ele não é criado visando a sua edição ou reutilização. Caso se queira reutilizar alguma parte da base de conhecimento, deve-se utilizar o "Knowlege Manager" para exportar e importar os objetos GeneXus que se deseja reutilizar.

    Assim, a objeção não é procedente.


    Contra 20[editar código-fonte]

    O código Genexus é orientado a eventos, não oferece nenhum suporte à programação orientada à objetos, o que dificulta em muito a manutenção do código Genexus.

    Réplica: Para alguns fundamentalistas pode parecer uma heresia uma linguagem ou ferramenta não ser orientada à objetos. GeneXus não é. Mas, nem por isso a afirmação de que isto "dificulta em muito a manutenção" é verdadeira. De fato, um sistema mal escrito terá a sua facilidade de manutenção comprometida. Uma modelagem de dados inadequada também compromete a facilidade de manutenção e evolução de um software. Estes problemas não estão relacionados à orientação à objetos ou não. Simplesmente estão relacionados à qualidade do projeto de engenharia de software. Isto sim é um problema.