Fazer login no IT Mídia Redefinir senha
Bem-vindo de volta,
Digite seu e-mail e clique em enviar
Ainda não tem uma conta? Cadastre-se
Salvar em Nova pasta de favoritos

+

Criar pasta
Salvar Escolher Pasta
9 segredos obscuros sobre plataformas Low-Code que vão questionar seu uso
Home > Tendências

9 segredos obscuros sobre plataformas Low-Code que vão questionar seu uso

Com facilidades também vêm complicações. Por trás dessas simples programações estão características que fazem do Low Code menos interessante

Peter Wayner, CIO.com

26/06/2019 às 18h19

Foto: Shutterstock

As plataformas Low-Code prometem facilitar a criação de aplicativos em um piscar de olhos, mas quando observadas mais de perto, as ferramentas podem não ser a melhor das opções. É verdade que o campo Low-Code pode ser sedutor, afinal de contas, para que contratar uma grande equipe de desenvolvedores caros quando apenas um programador pode dar conta do trabalho?

O movimento de adoção ao Low-Code vem crescendo graças a ferramentas que oferecem interfaces intuitivas para a criação de softwares, permitindo que os desenvolvedores juntem aplicativos com alguns cliques e, no máximo, algumas centenas de cliques. Porém, com as facilidades também vêm as complicações. Por trás dessas simples programações estão diversos segredos obscuros que acabam deixando o Low-Code menos interessante. Separamos nove deles para você ter no radar.

1. Aprisionamento tecnológico

Como acontece com muitas tecnologias, a quantidade de trabalho feito com ferramentas Low-Code é proporcional ao controle que o programador tem sobre elas. Ao distribuir grande parte do projeto para as plataformas, mais o desenvolvedor confia nelas e, assim, mais controle elas têm sobre o processo. Com o tempo, o que parecia ser uma parceria, torna-se um relacionamento de dependência com o fornecedor. Existem estratégias para minimizar o lock-in, por exemplo, portar o código para um novo serviço, o que é possível quando o trabalho é planejado com antecedência.

2. Controle de preços

Como muitas empresas, as plataformas Low-Code costumam oferecer preços baixos para atrair os desenvolvedores e acabam aumentando os preços posteriormente. Por conta do lock-in, uma vez que os programadores constroem seu sistema nas plataformas dos fornecedores, os preços podem ser controlados por eles. A menos que seja assinado um contrato de longo prazo, não há como ter certeza de quanto custará para executar o programa no próximo ano ou daqui a cinco anos.

3. Falta de transparência

A maioria das plataformas Low-Code não deixa claro o que está por trás dos bastidores. Apesar de serem atraentes inclusive por libertar os programadores dessa preocupação, muitas vezes eles vão querer saber de algumas informações. Pode ser que haja verdadeiros segredos escondidos por trás das chamadas APIs. Esse assunto é especialmente complicado quando há instituições envolvidas. Os bancos, por exemplo, precisam lidar com questões sobre as escolhas para a concessão de empréstimos. Um serviço de inteligência artificial embutido em uma plataforma Low Code pode ser ótimo, mas um desenvolvedor pode dizer aos órgãos reguladores que não tem ideia sobre o que acontece por trás do serviço?

4. Ineficiências escondidas

Como devem estar prontos para diferentes ocasiões, os códigos das plataformas Low-Code podem ser muito menos eficientes. Os fornecedores precisam blindar seus produtos para que não sejam afetados por ações mal feitas por parte dos desenvolvedores. Claro que essa proteção pode ser tecnicamente maravilhosa, mas, assim como um tanque blindado, provavelmente acaba sendo muito mais lenta.

5. Capacidade limitada

As demonstrações de uso das plataformas Low-Code são incríveis: um charmoso desenvolvedor cria um novo e bonito site de vendas em apenas uma linha de código colocando a função criar SiteDeVendas que acabou de ser incorporada ao framework. A maioria das plataformas Low-Code são generalistas, por isso os desenvolvedores acabam esgotando suas funções rapidamente.

O software pode ser flexível e adaptável às necessidades dos programadores, mas é necessário escrever o código que o adapta. Quanto mais flexibilidade se deseja, mais código é necessário usar. Mas atenção: mais código não é Low-Code.

6. Monocultura

Alguns dos bugs mais assustadores são os que encontramos nas bibliotecas mais populares. Plataformas Low-Code bem sucedidas criam uma monocultura por projeto, o que é bastante positivo até que um problema apareça e então o bug afete a todos. Não há como evitar esse problema, mas a boa notícia é que as pessoas têm maior motivação para consertar os erros, afinal, estão todos no mesmo barco.

7. Homogeneidade

Há alguns anos, um esperto amante de carros percebeu que não era tão difícil construir um carro chamando fabricantes de peças, encomendando seus itens de estoque e os juntando. Outros amantes de carros notaram. Não é a maçaneta da porta de um Volkswagen? Os assentos não são os mesmos em um Porsche 911? O volante não é da Ford?

Projetos Low-Code acabam gerando o mesmo efeito, ficando muito parecidos uns com os outros. Se o código está lá apenas para fazer executar uma função, o visual não importa. Mas se o software faz parte da marca, o programa Low-Code tenderá a ficar bastante semelhante ao dos concorrentes.

8. Paralisia

Trabalhar com uma plataforma poderosa de Low-Code é como brincar em um jardim. Tudo é simples e lindo - até alguém tentar sair. Os bosques fora do jardim estão cheios de escuridão, incertezas e dúvidas - e muito trabalho. Se há uma função embutida para o que você precisa, os frameworks são ótimos, mas assim que o desenvolvedor quiser fazer algo diferente, ficará paralisado. Fornecedores de Low-Code gostam de promover a abertura de suas ferramentas. Mas não é porque é possível acessar que a tarefa será fácil. Passar horas, semanas ou até meses tentando aprender como estender um projeto é frustrante, mas é um reflexo preciso do investimento feito em uma plataforma.

9. Cópias

Se for fácil criar um software, será fácil para alguém copiá-lo. Plataformas Low-Code tendem a evitar relacionamentos exclusivos. Se o software vai apoiar outro negócio com suas próprias vantagens competitivas, tudo bem. Mas se criar o software for o modelo de negócios do desenvolvedor, ele terá que estar pronto para a concorrência.

CIO2503

E-book por:

 

Vai um cookie?

A CIO usa cookies para personalizar conteúdo e anúncios, para melhorar sua experiência em nosso site. Ao continuar, você aceitará o uso. Para mais detalhes veja nossa Política de Privacidade.

Este anúncio desaparecerá em:

Fechar anúncio

15