Programação no mundo Low-Code. Sim, Low-code é programação

Vamos combinar: programar é coisa do passado, a moda agora é namorar com Low. Eu faço parte dessa moda — embora, às vezes, tenha me dado mal com ela. #ironia

Não me considero programador por vários motivos, mas principalmente porque há muito tempo não programo em uma “linguagem de verdade”. Comecei a aprender programação por volta de 2005. Anos depois descobri que, tecnicamente, não tinha começado a programar ainda — porque eu tinha aprendido HTML 😅. Mas logo depois já estava vendo Java, PHP, JavaScript... um pouco de tudo. Enquanto a galera comprava revistas Playboy, eu comprava INFO, Byte, Mundo PC. Nerd sendo nerd.

Só que não me aprofundei tanto na área. Entrei no mundo corporativo e foquei muito na área financeira e contábil. E adivinha qual foi a ferramenta mais low-code que conheci nesse universo? Acertou quem pensou em Excel.

Para mim, o Excel foi — ou é — uma das primeiras ferramentas low-code do mundo. Só percebi isso de fato há uns cinco anos, quando um amigo ficou surpreso ao descobrir que as fórmulas do Excel existem em vários idiomas, e não só em inglês, como nas linguagens de programação. Isso porque o foco do Excel é facilitar ao máximo o uso global. Mas mesmo assim, na época, eu nem considerava o Excel como “programação”.

Com o aumento das demandas e fórmulas cada vez maiores, acabei conhecendo o VBA. Estudei VBA com força entre 2010 e 2014, e nessa época me sentia invencível. Finalmente me sentia um programador, porque aplicava VBA e até estudava VB para rodar em um mainframe que havia na empresa onde eu trabalhava.

Até aí tudo certo. Sabia usar VBA e fórmulas avançadas. Entregava relatórios e dashboards automatizados “do futuro”. Mas aí veio o grande choque: descobri que Excel não é banco de dados. Pois é, pode rir — eu também ri. Mas na época doeu ouvir: “o relatório é bonito, mas está lento e não vale a pena usar assim”.

Temos que admitir: programador é bicho vaidoso. Então fui estudar mais. Só que eu não vinha da área de tecnologia. Tinha feito Administração. Nunca tinha feito um curso formal de programação, nem sabia o que era engenharia de software. Meu tesão sempre foi entregar soluções que fizessem as pessoas dizerem: “Caramba, olha o que esse cara fez!”

Comecei a estudar mais, mas parei no Access. Já que eu estava dentro do mundinho Microsoft, por que não ficar só entre Excel e Access?

Hoje, com uma cabeça diferente, entendo que ferramentas como Excel e Access são extremamente comuns nas grandes empresas porque são fáceis de implantar e não exigem tanto conhecimento técnico no começo. Pelo menos até as dores de cabeça começarem e os custos subirem.

Usei bastante o VBA até 2014. Mas naquele ano, conheci dois suplementos do Excel: o Power Pivot e o Power Query. Foi aí que entrei de cabeça nas linguagens M e DAX — sem nem entender ainda o que era BI. Só fui realmente aprender o conceito de BI lá por 2018.

Em 2018, precisei contratar alguém para me ajudar com VBA. Dei uma atividade para os candidatos e, claro, resolvi ela antes, deixando meu código todo lindo. Queria me gabar quando fosse mostrar a resposta “certa”. Eis que um dos candidatos me envia o código dele e eu fico espantado com a “bagunça”. Mas que bagunça é essa que me fez contratá-lo?

Eu simplesmente escrevia tudo em um único módulo, centenas de linhas de código, sem funções, sem Sub, sem nada. Clean Code? Nunca tinha ouvido falar. Patterns? Só se fosse nome de banda. O que o candidato me mandou era estruturado com POO. Ele tinha classes, funções, organização. Comecei a ler o código às 10 da noite e só larguei o computador às 3 ou 4 da manhã, pesquisando tudo para entender aquilo. Foi a primeira vez que vi ouro.

Depois disso, fui estudar POO, Clean Code, os livros do Kimball, arquitetura, refatoração... e entendi que sim, fazia sentido estudar tudo isso mesmo trabalhando com Excel e Power BI.

Chegamos em 2019/2020. Com o investimento da Microsoft em BI, vieram também suas ferramentas de low-code: Power Automate (antigo Flow) e Power Apps. Tudo na nuvem. Claro que me empolguei! Programador adora programar, escrever código e falar “Que se faça luz!”. Mas meu foco era — e ainda é — entregar soluções. E essas ferramentas me ajudavam a testar ideias de forma rápida, sem precisar investir pesado logo de cara.

Tudo isso que contei serve de pano de fundo para o ponto principal: low-code é sim programação — desde que você respeite o mínimo necessário para evitar que tudo quebre.

Low-code não é só fazer um If dentro de outro. É saber fazer laços, empacotar soluções, entender banco de dados, microserviços, segurança... E principalmente: arquitetura.

Defendo muito o Power Apps e Power Automate por serem ferramentas poderosas, acessíveis e rápidas de implantar. Dá para criar sistemas grandes e complexos com elas. Mas tem que fazer do jeito certo.

O problema é quando a empresa entrega o sistema nas mãos de alguém que não tem base em arquitetura de software — alguém que é bom em resolver problemas práticos, ou seja, pessoas da área de negócio. Quando chega a hora de evoluir o sistema, vem a bomba: o tal “botãozinho” que o gestor quer e faz tudo exigir uma super refatoração, para não dizer criar do zero, porque o jeito como foi construído não escala. E isso se repete várias vezes.

Minha conclusão: um bom software não depende da linguagem, mas da arquitetura. Não importa se foi feito com low-code, Excel, C#, Java. O que importa é se ele foi construído com base em boas práticas.

Não mexo tanto com Excel, mas quando uso, sem querer, por força do hábito, amém, escrevo fórmulas do Excel que aplicam conceitos que só aprendi com Clean Code e POO. E nem estou falando de VBA. Estou falando de lógica, estrutura e clareza.

Por isso, hoje, ao avaliar alguém, pergunto se ela sabe estrutura de dados — não qual linguagem domina. Porque linguagem se aprende. Já lógica e estrutura, se a pessoa não vê valor, aí sim temos um problema.