As plataformas de baixo código (plataformas de aplicativos de baixo código, LCAP) surgiram como uma reação à complexidade e variedade de ferramentas modernas de desenvolvimento de software.
Segundo o Gartner, um dos jogadores mais famosos nessa área é o Mendix . A venda da Siemens pelo espaço de US $ 700 milhões confirma isso. Portanto, usarei esta plataforma como exemplo, embora conclusões semelhantes sejam verdadeiras para Outsystems, Appian, Kony, Betty Blocks e outros.
Assim, direcionando as vendas aos principais gerentes, os fornecedores de plataformas com baixo código prometem que mesmo usuários comuns poderão criar aplicativos de negócios por conta própria.
Ou seja, os desenvolvedores não são mais necessários ?!
Bem ... depois de alguns anos, Mendix é forçado a admitir:
"Agora os desenvolvedores precisam mais do que nunca."
Esta é uma torção!
Parece que Mendix reconheceu que, para algo mais difícil do que o trabalho básico com dados, um desenvolvedor profissional ainda é necessário, assim como um mecânico profissional é necessário para atender um carro.
Infelizmente, as plataformas modernas de código baixo simplesmente não são projetadas para desenvolvedores, e confiar nelas a longo prazo é arriscado para os negócios. Se sua empresa está considerando seriamente o uso de plataformas de baixo código em operação industrial, vale a pena pesar esta solução novamente. Abaixo vou tentar argumentar isso.
Ótima ferramenta de prototipagem
O Mendix é uma ótima opção para automatizar processos simples ou prototipagem, disponíveis para analistas ou usuários avançados.
O editor visual permite descrever o modelo de dados, criar telas rapidamente usando um conjunto de widgets e modelos e até descrever a lógica usando os chamados microfluxos :
Após a conclusão, você pode implantar seu aplicativo na nuvem Mendix com um clique e começar a trabalhar com ele. Tão simples que parece mágica! E parece que vende bem.
No entanto, após passar pelo estágio de protótipo, a interação do sistema com o usuário e a lógica de negócios é quase inevitavelmente complicada. Para desenvolver ainda mais o projeto, é necessário um profissional. Então, vamos olhar para o Mendix através dos olhos de um desenvolvedor.
Desenvolvimento lento
Qualquer lógica - seja computação ou interação do usuário - deve ser descrita em um fluxograma de microfluxo, como mostrado acima.
Existem vários problemas aqui.
Em primeiro lugar, faz muito tempo . Obviamente, é mais rápido escrever 10 linhas de código em um bom IDE do que arrastar e soltar, personalizar e juntar dezenas de blocos.
Em segundo lugar, legibilidade . Os blocos ficam lindos, mas o que isso significa Sub_RegistrationValidation ? É impossível entender isso sem cair no bloco. Assim que o número de blocos aumentar para várias dezenas, será extremamente difícil entender a lógica.
Como alternativa para casos complexos, o Mendix suporta chamadas de código Java de microfluxos. Você pode escrever código no Eclipse, o que geralmente é bom, embora muitos prefiram um IDE mais popular. A desvantagem é a falta de transparência: todos os pontos de entrada estão em microfluxos, de modo que a lógica é dispersa entre dois ambientes pouco acoplados. Como resultado, é difícil depurar e rastrear dependências.
A última coisa que eu queria mencionar era o controle de versão.
A boa notícia é que ele é. O ruim é que é uma versão simplificada do Subversion. Esqueça o fluxo git.
Falta de controle
Qualquer pessoa familiarizada com o ecossistema Java não pode subestimar o poder do código aberto. Quando um erro aparece em algum lugar da pilha, você vê em qual parte do código isso aconteceu. O código pode ser depurado para entender exatamente o que está acontecendo. Você pode pesquisar no google a solução. Você pode enviar uma solicitação de recebimento. Em casos extremos, você pode bifurcar a biblioteca. Você está no controle total do projeto.
Com o Mendix, você pode esquecê-lo. Esta é uma estrutura comercial fechada, e o que está acontecendo dentro dela é uma verdadeira caixa preta. Tudo o que resta para você é comprar suporte pago ou esperar alguém ajudar em um fórum com ~ 200 perguntas por mês (compare com a tag #spring no stackoverflow !).
Dependência de fornecedor
Mendix provavelmente muitas vezes censura isso. Eles até publicaram um artigo dizendo que realmente não há vício. Se você ler entre o termo, ele lerá:
Você pode obter seus dados, DDL, recursos e código da interface do usuário (microfluxo magicamente convertido em código Java).
Será executado ou compilado sem tempo de execução e API Mendix? Isso pode ser mantido e desenvolvido? As perguntas são retóricas. De fato, você precisará reescrever tudo. Você depende de uma plataforma proprietária. Você não possui o sistema que criou.
Escalabilidade limitada
O marketing da Mendix está focado nas maiores empresas, portanto o termo “escalabilidade” pisca constantemente nos materiais de marketing.
Em 2017, o Mendix introduziu o tempo de execução sem estado - ou seja, todas as informações da sessão são armazenadas no lado do cliente ou em um armazenamento persistente.
Teoricamente, isso significa escalabilidade horizontal ilimitada. Parece ótimo, mas, como de costume, há uma nuance - o banco de dados.
Um banco de dados quase sempre acaba sendo um gargalo em um aplicativo corporativo. Então, o que os dados armazenam atrás de muitos servidores sem estado Mendix? Sem surpresas - esse é um bom e antigo banco de dados relacional. Na nuvem Mendix - PostgreSQL. Além disso, o Mendix DDL gerado, para dizer o mínimo, não é totalmente ideal. Por exemplo, vi uma tabela intermediária que é comumente usada para modelar relacionamentos N: M, criada para um relacionamento 1: N.
O problema de escalabilidade poderia ser resolvido por métodos padrão: otimizando a estrutura do banco de dados, armazenando em cache ou mesmo usando soluções como o Citus. Mas é claro que não existe essa possibilidade.
A única maneira de escalar o banco de dados é escalar usando réplicas de leitura (por exemplo, Amazon RDS). Mas, para constar, isso não vai funcionar.
Resumindo o exposto, o Mendix tem uma limitação fundamental à escalabilidade e não tem como otimizar o desempenho.
Questão de RH
A busca por pessoal qualificado é sempre uma tarefa difícil. Parece que neste Mendix é o sonho de qualquer gerente, porque os requisitos de qualificação são bastante reduzidos.
De fato, já descobrimos que a maioria dos projetos requer uma equipe profissional, independentemente da ferramenta. Mas é improvável que qualquer desenvolvedor que se preze aceite trabalhar com o Mendix, já que esse é um beco sem saída óbvio em sua carreira.
Preços
Por último mas não menos importante. O custo de uma licença para um aplicativo começa em US $ 1875 por mês, sujeito a uma assinatura por três anos, a licença é limitada a 50 usuários internos.
O preço de uma licença corporativa com a possibilidade de implantação local começa em US $ 7.825, que é quase US $ 100.000 por ano.
Uma empresa de médio porte com várias centenas de usuários pagará anualmente contas de dezenas de milhões de rublos.
Não esqueça que estamos falando de aplicativos relativamente simples, como você pode entender acima. Para mim, isso é loucura. Esse modelo de preços também praticamente impossibilita a replicação dos aplicativos que você criou.
Então, por que os LCAPs ainda são populares?
Na minha opinião, o motivo está na decepção dos processos existentes. Gerenciar uma equipe de desenvolvimento em uma grande organização - seja uma equipe interna ou uma terceirização - é muito complicado.
Planejamento orçamentário, aprovações sem fim, falta de pessoas dispostas a assumir responsabilidades - acho que isso é familiar para muitos.
O engraçado é que a primeira coisa que vem à mente quando os projetos de TI estão se movendo muito devagar é contratar ainda mais desenvolvedores e, é claro, gerentes. Escusado será dizer que isso só piora a situação. Conheço alguns bancos com mais de 10.000 desenvolvedores (!!!) e pelo menos metade deles está fazendo um trabalho inútil.
Desesperados, os líderes empresariais estão procurando uma solução em "varinhas mágicas" como a LCAP, supostamente capazes de resolver todos os problemas.
Como sair desse círculo vicioso é um tópico para um artigo separado. Mas isso é uma questão de gerenciamento, não de tecnologia.
Sem entrar em detalhes, se você conseguir criar uma pequena equipe qualificada de 3 a 10 pessoas totalmente envolvida no projeto, com contato direto com o tomador de decisão, obterá excelentes resultados mais rápido e mais barato do que o esperado.
Quais são as alternativas?
Agora há uma enorme seleção de ferramentas e estruturas para desenvolvedores.
Por exemplo, o Spring Framework é a tecnologia de código aberto mais popular para a criação de software corporativo que funciona bem com estruturas da Web como React ou Angular. E ferramentas como o Spring Initializr e o JHipster simplificaram bastante a criação de projetos nos últimos anos.
Se você deseja obter o resultado mais rapidamente, considere ferramentas RAD, como a Plataforma CUBA .
Baseia-se no mesmo Spring Framework, complementa-o com ferramentas de desenvolvimento visual e um grande número de componentes prontos para uso. Talvez esta seja a alternativa mais próxima ao LCAP, oferecendo flexibilidade e um processo de desenvolvimento confortável.
A escolha final deve depender da tarefa, bem como das habilidades da equipe e de suas preferências.
Conclusão
Plataformas de código baixo são ótimas para prototipagem. Eles diminuem a diferença entre usuários de negócios e TI, o que permite que você obtenha rapidamente um protótipo funcional e forme uma visão do futuro sistema.
Como existem muito poucos usuários de protótipos, os custos nesse estágio também são pequenos. E neste momento vale a pena parar!
Ao usar o LCAP para desenvolver um sistema completo, a velocidade do trabalho inevitavelmente cairá e você dependerá da plataforma proprietária cara que o limita.