Porque aprender outras linguagens como desenvolvedor Salesforce?

Esse definitivamente é meu post menos pesquisado e mais opinativo até o momento, mas vem de uma reflexão iniciada há quase dois meses, quando me peguei precisando de funcionalidades que a plataforma não me oferece (até onde eu saiba), mas para basear tudo isso, me deixe te contar um pouco sobre mim.

Quem sou eu?

Bem, eu pensei em titular essa parte do post como “whoami”, um comando bem conhecido pelo pessoal de sistemas nix like, o que deve dar uma ideia de qual o meu histórico.

Para quem não me conhece, prazer, meu nome é Jônatas, sou desenvolvedor Salesforce há algo em torno de 4 anos na data que escrevo esse post, hoje em nível de tech lead, atuando em um projeto que infelizmente não posso dar informações. Sou bacharel em Sistemas de Informação e especialista em arquitetura de sistemas, então podemos colocar aqui algo em torno de 5 anos em nível superior de educação formal, mas comecei a estudar programação lá atrás em 2014, na época da escola técnica e nunca parei. Não vou fingir que foi amor a primeira vista, mas foi algo que eu aprendi a amar muito rápido. Na ETEC a linguagem usada nas aulas era C++, depois na faculdade C e Java, foi quando comecei a estudar Ruby por ver várias vagas utilizando Rails, mas molhei os pés em coisas como Python e JavaScript, tive a sorte de ter bons amigos que também são da área e sempre comentávamos o que estávamos estudando ou entrando em infindáveis discussões sobre qual a melhor linguagem de programação.

Ao entrar na pós graduação acabei aprofundando meu contato com Python, muito pelas aulas de ciência de dados, mas também por ser a linguagem escolhida pelo curso para abordar outros tópicos diversos. Tínhamos a possibilidade de escolher qualquer linguagem que quiséssemos usar, mas curioso como sempre fui, pensei em aprender mais sobre essa, o que se provou muito útil há uns 2 meses atrás e me fez começar esse post.

Limitações da Salesforce

Correndo o risco de ser considerado algum tipo de herege e/ou ser execrado, eu não vejo a Salesforce como sendo uma panaceia, na realidade acredito que seja o contrário, acredito que seja um CRM extremamente completo e excelente no que se propõe a fazer, mas não acredito que seja uma plataforma de RH ou ERP como vi em projetos que já participei. Por conta dessas participações sei que é possível customizar a plataforma até que ela supra essas necessidades, mas realmente não acho ser o ideal (mas caso discorde, por favor, fique a vontade para interagir com o post ou comigo no privado, será um prazer ouvir suas ideias).

Fato é que em um projeto que participei havia um problema nos jobs de integração, mas por diversas razões, a equipe que eu integrava na época não tinha visibilidade da fila e muito menos tempo/pessoas para tentar resolver essa integração, mas precisávamos saber quando ela falhava para poder rodar a integração de forma manual buscando afetar o negócio de forma mínima. Precisávamos de observabilidade.

A solução iniciou com nossa funcional criando dois relatórios e colocando em um dashboard. Funcionou um pouco, nós sabíamos quais registros não haviam sido integrados com o ERP e quantos registros estavam na fila. Mas ainda não sabíamos quantos registros entravam a cada X de tempo, quando a integração deveria rodar, não sabíamos o atraso para integração deles, não havia nenhum agrupamento temporal que nos apontasse “nessa janela de tempo as coisas funcionam”. Foi aí que veio a solução, iniciar um projeto simples de observabilidade. A ideia surgiu em um almoço, conversando com um amigo SRE. A ideia era simples, Grafana e Prometheus consumindo os dados da org e exibindo em um dashboard mais completo, quem sabe até mesmo com um botão para rodar a integração manualmente. Iniciei o desenvolvimento de uma prova de conceito. Inicialmente procurei por algo que funcionasse dentro da nossa org, mas rapidamente encontrei que Python seria uma solução mais simples e rápida. Agradeci por ter estudado isso no passado e segui com esse desenvolvimento. No fim das contas, a equipe do cliente achou legal mas decidiu não implementar, mas isso é história para outro dia.

Outras linguagens

Finalmente falando sobre o titulo desse post, o combo de Apex eJavaScript é uma necessidade para qualquer pessoa que se envolva com desenvolvimento Salesforce. São as linguagens que utilizamos para construir o nosso sistema e sugiro sinceramente que no inicio da carreira na plataforma seja o foco de estudos, porém ao avançar nela acredito que tenhamos opções interessantes de linguagens novas, que vou falar pouco mais a frente.

Como dito acima, a razão para aprender outras linguagens é poder lidar com limitações da plataforma ou até poder construir soluções mais robustas ao redor dela. Acho também importante salientar que outra vantagem de aprender outras linguagens é entender como elas fazem algo e em algumas situações trazer isso para o ambiente que estamos desenvolvendo.

Java/C#

Iniciando nossa lista de sugestões, temos dois gigantes de mercado e que também são muitas vezes como bases do Apex.

São linguagens muito fortes no cenário empresarial, ainda mais aquele mais consolidado. Entre outros projetos que participei, as maiores empresas, entre elas duas FAANG e bancos, utilizam uma dessas duas, quando não as duas.

Tenho visto mais sistemas com C# nos últimos tempos, mas pode ser algo da minha bolha. Isso posto, eu fui mais para o lado do Java, por conta de ter usado bastante na faculdade.

Uma linguagem de propósito geral é sempre essencial, seja para estudos, seja para entrevistas com LeetCode e similares.

Adicionalmente, caso um dia algo aconteça com a Salesforce ou você queira trocar o seu campo de atuação, são duas linguagens fortes no mercado que ajudam a não ficar desempregado.

Python

Com a enorme crescente de inteligência artificial e dados na Salesforce, porque não ir para a linguagem mais utilizada nesse meio? Python é uma linguagem bastante completa e com uma infinidade de bibliotecas que permite fazer virtualmente qualquer coisa apenas importando uma.

Admito que por mais que já tenha utilizado diversas vezes, não é a linguagem que tenho mais familiaridade ou apreço. Prefiro, quando possível, utilizar linguagens com tipagem forte e estática, mas devo admitir que em qualquer situação que preciso criar gráficos, dashboards e em alguns casos, provas de conceito, é a primeira linguagem que vem a cabeça.

Embora seja uma linguagem “lenta” (recomendo esse vídeo do Augusto Galego sobre esse assunto para entender a razão das aspas) o desenvolvimento é extremamente rápido. Seja pela simplicidade que a linguagem propõe ou pelo ecossistema de bibliotecas. Até aproveito para deixar a recomendação da Simple Salesforce, que uso com alguma frequência.

C/C++

Não tem muito como ir para outro lado na recomendação de uma dessas duas. A ideia aqui é aprender a programar melhor. Por essa razão, sugiro C com mais ênfase que sugiro C++. São linguagens que entregam muita liberdade ao programador, mas oferecem poucas ou simplicidades. Você precisa de alguma coleção para seus dados, como uma Lista ou Mapa? É simples, só criar uma implementação da coleção. Pode até ser que alguma biblioteca padrão implemente essas coleções, mas se o intuito aqui é aprender e melhorar, acho que implementar uma na mão é melhor. Entender o algoritmo, a utilização de memória a eficiência da sua implementação são coisas que vão te fazer entender melhor como e quando usar uma implementação padrão de alguma dessas ferramentas.

Go/Rust

As queridinhas modernas. Go vem sendo adotada cada vez mais em grandes empresas e Rust sendo a linguagem mais amada pelos programadores há alguns anos. Ambas tem o intuito de focar em programação de sistemas, com segurança em relação ao gerenciamento de memória e erros, boa velocidade de execução (de novo, vejam o vídeo do Galego sobre).

Go é uma linguagem mais simples de aprender, na minha opinião, e com mais aplicações no mercado de trabalho pelo que tenho visto, entre empresas grandes no Brasil que vejo sua adoção cito Itaú e Mercado Livre. Rust está presente no kernel Linux, mas infelizmente envolta em diversas polêmicas, não apenas nesse espaço.

São linguagens que eu sempre recomendo para os meus alunos (sempre dando ênfase em Go) pela aparente simplicidade de integrar o mercado de trabalho quando comparada com linguagens mais consolidadas, ou Rust quando o foco não é tanto o mercado de trabalho ou quando se tem interesse em aprender a fazer código mais robusto.

Haskell/Elixir

Elixir é mais simples de aprender e utilizar, além de ter um mercado de trabalho mais expressivo. Haskell por outro lado cumpre melhor o papel de te forçar a aprender programação funcional, que é meu intuito ao fazer essa sugestão.

Assim como muitos pensam que OOP é só criar classes e métodos, muitos pensam que programação funcional é só criar funções. Ambos estão errados, tem muito mais nesses dois universos que só isso. Entre alguns pontos de programação funcional que acho interessante ressaltar:

• Pattern Matching e tipos algebráicos

• Monads

• Recursão

• Imutabilidade

• Funções puras

• Funções de primeira classe

• Funções de ordem superior

Não vou falar sobre esses pontos como um incentivo para você pesquisar sobre, mas adianto que são coisas que mudam a forma como você escreve programas. Um conceito comum de programação funcional que eu tento aplicar em todos os meus projetos é “faça com que estados ilegais sejam irrepresentáveis”. Assumo que hoje eu demoro um pouco mais para escrever algum código e que sinto que me dou mais trabalho, ainda mais quando isso não é um requisito, mas pensando que o usuário final terá uma experiência melhor e a quantidade de tempo economizada em lidar com bugs causados pela possibilidade de representar estados ilegais é uma troca que eu considero muito boa.

Essas são minhas sugestões de hoje. Concorda ou discorda? Acha que só Apex e JavaScript são mais que o suficiente? Acha que faltou alguma linguagem na minha lista? Me conta aqui embaixo ou no LinkedIn, vai ser um prazer seguir essa conversa.