Na internet existem inúmeros artigos sobre o bom, o mau e o feio do low code. Por que você deveria usá-los ou por que não deveria. Neste artigo estou escrevendo sobre minha experiência pessoal ao desenvolver software com low code. Eu tenho usado uma plataforma de baixo código nos últimos 12 anos. Isso foi antes mesmo do surgimento do próprio código baixo. Minha experiência se baseia principalmente na plataforma Pega, da qual sou certificado como Lead System Architect, o certificado mais antigo da Pega, desde 2014.

As plataformas de baixo código são vendidas por seu foco no desenvolvimento rápido de aplicativos e na facilidade de uso por não desenvolvedores. Permite que pessoas menos técnicas participem do processo de desenvolvimento. As plataformas também são cloud first, o que significa que a infraestrutura é cuidada pelo fornecedor da plataforma.

Vamos começar com a boa notícia. Na minha opinião, o código baixo realmente funciona. A promessa de que ele ajuda as organizações a criar aplicativos mais rapidamente com menos desenvolvedores profissionais é verdadeira. Mas há algumas notas laterais.

O processo de software

A primeira observação que quero fazer é que um aplicativo de baixo código ainda é um software que precisa passar por processos regulares de desenvolvimento de aplicativos, como controle de qualidade e verificações de segurança, para ser implantado na produção. A maior parte do marketing de low code é sobre desenvolvimento mais rápido, mas nenhum deles fala sobre colocar seu aplicativo em produção e mantê-lo usando processos aprovados por TI. O processo Dev(Sec)Ops envolve muito mais do que apenas desenvolvimento.

A imagem mostra que a parte de codificação (visual) é apenas uma etapa de todo o processo. Acelerar essa etapa é bom, mas isso não acelera automaticamente as outras etapas. Se você deseja manter a velocidade obtida com a codificação, a etapa de teste deve ser capaz de acompanhar. Mas as plataformas de baixo código têm recursos limitados para testes (de unidade). Grande parte do teste precisa ser feito fora da experiência de código baixo ou até mesmo usando a IU de tempo de execução. É do conhecimento comum que os testes de IU levam mais tempo para serem escritos e executados. Eu chamaria isso de uma grande desvantagem. Para colocar isso em perspectiva. Um desenvolvedor cidadão pode arrastar e soltar um processo em horas, mas um testador profissional leva dias para testar e automatizar o mesmo processo.

Na minha experiência, não há muita diferença entre o restante das etapas do processo. Uma vez automatizados, a diferença está nas ferramentas utilizadas, e não no tempo necessário para executá-las.

personalização de software

A segunda nota lateral diz respeito à personalização. Low code permite um desenvolvimento rápido devido a todos os blocos de construção pré-configurados. Eles podem ser facilmente combinados em um software funcional, mas a base é bastante rígida. O número de opções para personalizar esses blocos é limitado por um bom motivo. Reduz o número de erros, torna a experiência geral do usuário mais alinhada e aumenta a velocidade de desenvolvimento.

Mas o que acontece quando o negócio quer algo que não é suportado pela plataforma? A experiência de código baixo é interrompida e você precisará recorrer a alternativas de código alto. Escreva seu próprio bloco personalizado no código alto ou crie outro aplicativo fora da plataforma.

Com mais frequência do que eu gostaria, tive que recorrer ao código alto para coisas que não são entregues prontas para uso. E os requisitos não estavam realmente fora da escala. Uma fusão de pdf, opções de autenticação na configuração de serviços externos, elementos de interface do usuário personalizados, etc. Observe que volto muito tempo e alguns dos itens são adicionados à plataforma hoje, mas uma plataforma sempre ficará um passo atrás. O fornecedor simplesmente não tem tempo para implementar todos os novos recursos que são lançados todos os dias.

Ao fazer código alto, há algumas desvantagens que não são facilmente resolvidas. O primeiro é técnico e relacionado às atualizações da plataforma. Ao usar componentes pré-configurados em seu aplicativo, uma atualização não terá muito impacto. O correto comportamento destes componentes é garantido na próxima versão da plataforma. Mas não há garantia de que o código alto funcione na próxima versão. Cada componente escrito por você precisa de verificação adicional após cada atualização. Para a Pega, isso significa pelo menos 4 vezes por ano.

A segunda está relacionada aos desenvolvedores que utilizam a plataforma. Dentro da comunidade da Pega, não há muitos desenvolvedores (principais) que também possam escrever códigos avançados. Isso significa que você precisará de uma pessoa totalmente diferente para codificar sua solução. Mas isso não será fácil, pois o programador também precisa conhecer a plataforma antes de poder codificar nela. Os programadores com quem falei não gostam muito de low code em geral. Eles querem suas próprias ferramentas e falam sua própria língua. Simplificando, os programadores não estão interessados ​​em plataformas de baixo código. E mesmo que você encontre alguém que possa fazer isso, você provavelmente não vai querer. Encontrar o próximo é quase impossível. Isso impõe um risco sério para a organização e significa que você deve permanecer dentro dos limites da plataforma.

Para demonstrar como é a lacuna, coletei um exemplo de código alto necessário para um caso de uso simples. Ao inserir um número de telefone, ele deve ser formatado em formato internacional (ou seja, +31612345678).

Um pedaço de código personalizado é necessário para isso.

String tempValue = theValue;

if (tempValue.length() > 0)
{
   tempValue = tempValue.replaceAll("[^\\d\\+]","");
 
   if((tempValue.length() > 10) && (tempValue.charAt(0) == '+'))
   {
       //Assume number is already in right format
   } 
   else if((tempValue.length() == 10) && (tempValue.charAt(0) == '0'&& tempValue.charAt(1) != '0'))
   {
       //Assume Dutch number without countrycode
       tempValue = "+31" + tempValue.substring(1);
   }
   else if // etc
  
   theValue = tempValue;
}

A equipe de desenvolvimento

A última observação é sobre desenvolvedores menos profissionais. Sim, os desenvolvedores cidadãos podem criar processos sozinhos, mas dificilmente têm o conhecimento técnico para implementar serviços, configurar a segurança e evitar que um aplicativo fique inchado. Eles trazem insights e conhecimentos valiosos sobre o domínio do negócio, e conversar diretamente com eles em um idioma que eles entendam é muito bom.

Mas pelo que vi é que você ainda precisará de muitos desenvolvedores experientes e profissionais. Olhando para a primeira nota lateral, também é necessário um investimento pesado para a capacidade de teste. E com relação à segunda nota do site, você provavelmente precisará de um programador para dar suporte ao código personalizado. Isso faz com que as funções exigidas para low code sejam as mesmas exigidas para high code, com a adição de desenvolvedores de plataforma (líderes) como eu. E tudo isso é necessário para permitir que um desenvolvedor cidadão ajude na codificação de um aplicativo.

Passo a maior parte do meu tempo treinando e orientando desenvolvedores cidadãos a usar o conceito e a ferramenta corretamente. Posso ajudar cerca de dois a três desenvolvedores cidadãos em minha equipe. Isso me deixa com pouco tempo para construir componentes para eles usarem e isso significa que preciso de outro desenvolvedor para fazer isso por mim.

Conclusão

Como mencionei no início, o código baixo funciona dentro dos limites da plataforma. Contanto que você permaneça dentro desses limites, é difícil vencer um sistema de baixo código na produção de seu novo aplicativo. Você terá

• uma forma de permitir que o negócio colabore estreitamente com a equipe de desenvolvimento;
• grande velocidade de desenvolvimento;
• uma experiência de usuário consistente;
• e um cliente muito feliz.

No entanto, sou um desenvolvedor low code profissional que adora o conceito de low code. A plataforma que vem com ele permite que eu me concentre melhor no que precisa ser resolvido, e não em como resolvê-lo. Mas também estou procurando as mesmas vantagens fora dos limites da plataforma. Recorrer ao high code é uma opção que eu não gosto, porque acho que a diferença entre high code e low code é muito grande. Requer um conjunto diferente de desenvolvedores, ferramentas diferentes e geralmente não se alinha muito bem com o negócio.

No meu mundo ideal, há algo intermediário. Algo que não é nem high nem low code, pois o exemplo de high code mostra que esses mundos estão muito distantes. Eu quero um conceito que construa a ponte entre os dois. Uma linguagem que pode ser compreendida tanto pelos negócios quanto pela TI. Com blocos que são pequenos o suficiente para criar tudo e podem ser facilmente combinados em blocos maiores, vamos chamá-los de blocos pré-configurados. E com uma representação do negócio em mente, o aplicativo reflete a forma como o negócio funciona. Eu chamaria esse conceito de código médio . E eu gostaria de explorar mais sobre isso em um próximo artigo.

Obrigado por ficar comigo. Escrevi minha experiência com low code, que pode não ser igual para todos. A plataforma Pega é uma ótima ferramenta para construir aplicativos e espero que isso também esteja claro no texto.

Quais são suas experiências com low code? E você estaria interessado em código médio? Por favor, deixe-me saber nos comentários.