quinta-feira, 25 de agosto de 2011

Kb´s Grandes


Um tema fundamental levantado pelo Enrique Almeida para o próximo Encontro Genexus é a gestão de Kbs grandes no Genexus, e creio esse ser sem dúvida um dos assuntos mais importantes relacionados ao desenvolvimento com Genexus, pelo menos pra mim.

Falo isso porque nosso projeto alcançou uma dimensão exageradamente grande, gerando situações difíceis de serem resolvidas, algumas das quais já adianto no Genexando, para que possamos gerar reflexões no encontro:

  1. Tempo de compilação, backup da Kb
    1. Apesar dos avanços alcançados na questão da otimização do processo de compilação e geração de código, temos ainda grandes dificuldades no que se refere ao tempo gasto em um Build All.
    1. O tempo para a exportação completa de nossa KB é de 15 minutos.
    1. Geração de objetos desnecessários também vem nos causando grandes transtornos, atualmente temos 70 objetos que insistem em serem gerados mesmo que não se tenha nenhuma nova implementação sobre eles.
    2.  Infelizmente o Genexus também se torna lento e ineficaz, e olha que usamos um belo Intel Centrino QuadCore.
  1. Processos fundamentais centralizados e protegidos
    1. Infelizmente Genexus não possui ainda uma linguagem Orientada a Objetos, desta forma conceitos fundamental como classes, objetos, métodos private  e public, interfaces, sobrecarga, e outros, fazem muita falta.
    1. Uma vez que não possui os conceitos de objetos e classes, as regras de negócio ficam implementadas de forma esparsa dentro nos objetos Genexus: Transações, Procedimentos, Web Panels, cada um tratando de parte da regra, e claro, gerando grandes dificuldades para mantê-las integras de acordo com a evolução do projeto.
    1. Por exemplo, ao se realizar a manutenção em determinada regra de negócio em um Procedimento isolado, por exemplo, pode ocorrer que esta mesma manutenção não venha a ser aplicada em outros objetos similares, tornando esses geradores de bugs na aplicação. Se tivéssemos a possibilidade de criar uma Classe (de negócio) poderíamos concentrar todas as operações em um lugar único, disponibilizando os métodos públicos disponíveis para serem consumidos pelos objetos Genexus, tais como Transações, WebPanels, Procedures, e outros.  Uma manutenção em uma única classe traria muitos benefícios para projetos grandes e complexos.
    1. Atualmente diversos objetos apontam nessa direção, o External Object, por exemplo, permite encapsular métodos de classes externas ao Gx. Quem sabe não teríamos uma espécie de Internal Object, similar ao External Object, que disponibilizaria um tipo para se acessar métodos de negócio públicos encapsulados e protegidos na Kb.  Claro que nem todos os desenvolvedores teriam privilégios para manipular tais objetos.

  1. Todos tem acesso a tudo
    1. Independentemente da atuação da pessoa no projeto, quer seja um aprendiz, um desenvolvedor, um analista senior, qualquer um, possui acesso full a todos os objetos da KB. Esse acesso indiscriminado gera situações complicadoras, desde a modificação e remoção indevida de objetos, até mesmo questões de segurança do projeto, visto que a pessoa pode, por exemplo, obter uma cópia integral do código fonte, para quem sabe fazer o que.  Melhor seria se fosse possível estabelecer privilégios sobre os objetos para os diversos perfis de desenvolvedor, bloqueando inclusive operações de modificação, exportação, abertura, entre outras.
    1. Todos podem modificar a estrutura das transações, podendo gerar inconsistências na base de dados, duplicação de atributos e conceitos, e por ai vai.  Melhor seria se tivéssemos perfis para liberar modelagens da estrutura do sistema

Tem muitas outras coisinhas interessantes a serem discutidas, mas vou parar por aqui para não assustar as criancinhas!

3 comentários:

  1. Buen post.
    Creo que hacer una lista de las coas que traen problemas en las KB grandes, ayuda a que GeneXus sea mejor para grandes aplicaciones.

    Algunos de los problemas que planteas, iban a ser resueltos con el objeto Module, que si bien se empezo a implementar en Genexus, quedo suspendido cuando aparecieron los Smart Devices y sus diversos generadores.

    El poder modularizar las KB nos va a posiblitar dividir el problema en problemas mas chicos, marcando cuales objetos pueden ser privados y cuales publicos (API del modulo).

    Hay varias cosas a mejorar para hacer mas agradable el desarrollo de aplicaciones enormes, pues deberiamos lograr que las operaciones de Genexus dependieran de la cantidad de objetos modificados y no de la cantidad de objetos de la KB.

    Por ejemplo, un F5 en una KB en la que no modifique absolutamente nada despues de un build all, demora mas de 5 minutos si se tienen muchos objetos main (aunque esten todos compilados).

    En fin, creo que se puede mejorar mucho en este aspecto, pero vamos por buen camino.

    ResponderExcluir
  2. Isso mesmo Enrique, seria muito bom Genexus permitir um pouco mais de conforto e segurança no desenvolvimento de aplicações grandes... já que as pequenas já estão evoluindo... :)

    ResponderExcluir
  3. Trabalho proficionalmente com genexus a cinco anos, já vi site dizendo que uma KB grande tem 800 objetos, para mim isso ainda seria um software pequeno.
    Olhando para que o genexus é feito, acho que entre 800 e 1600 objetos seria um KB grande, se você passar desse tamanho e tem perspectiva de continuar crescendo, o melhor é abandonar o genexus. Genexus é feito para desenvolver aplicativos atrás de aplicativos em alta velocidade sem preoculpar-se com documentação e qualidade, visto que para pequenos softwares e desenvolvendo sozinho ou em um pequeno grupo isso não compromete o aplicativo.
    Quando o software é realmente grande, e você irá fazer alterações e ampliações, o genexus não é uma boa ferramente, isto está descrito na segunda sessão, falta de objetos...
    No metodologia, forma, de desenvolvimento, o genexus hoje é como uma linguagem muito ultrapassada, mesmo criando aplicativos para dispositivos moveis (o que para mim é desenvolver software como qualquer outro, só muda a linguagem e os recursos) a maneira de produzir é de 20 anos atrás.
    O que você quer já existe e funciona muito bem.
    Em Java você encontra o JPA que torna o acesso ao banco de dados tão rápido quando o genexus, e você pode usufruir de toda liberdade da OO.
    Existem várias APIs e frameworks para java que deixa o desenvolvimento mais facil e rapido do que genexus para grandes softwares, que precisam ser mantidos por longo periodos.
    Ainda é possivel você desenvolver seu proprio framework, deixando o desenvolvimento mais rapido do que genexus, mesmo em aplicações pequenas.
    Eu mesmo desenvolvo API's e plugins para o Netbeans que tornam o desenvolvimento mais rápido do que em genexus.

    ResponderExcluir