Customização no Salesforce: caminho atraente, porém caro e complexo.

Série: Por que o Industries?

Quanto tempo você leva para implantar novos requisitos de negócio na sua organização Salesforce? Em um mercado cada vez mais competitivo e que sempre requer agilidade, este é um indicador que deve ser considerado com atenção. Lançar um novo produto, implementar uma nova regra, gerar um novo template de um contrato são alterações comuns que podem requerer um grande período de tempo caso seja escolhida a ferramenta menos apropriada.

Afinal, um carpinteiro dispõe de muitas ferramentas para o seu ofício e deve estar ciente de qual precisa utilizar nas mais diversas situações. Uma chave de fenda não é o melhor caminho para martelar um prego e, se ele tentar fazê-lo, levará muito tempo para terminar a tarefa e o trabalho não ficará tão bem feito quanto se tivesse sido realizado com um martelo.

Em uma implantação Salesforce, não há muita diferença. Temos objetos padrão e customizados, regras de validação, processos, fluxos, classes Apex e triggers, Componentes Aura e Lightning, uma infinidade de soluções com nomes não tão intuitivos que devem ser ponderados em cada desenvolvimento para que o melhor resultado a curto e a longo prazo seja obtido. Qual princípio deve então ser levado em consideração? Teríamos outras ferramentas disponíveis que nos auxiliassem no processo?

Na escolha da melhor solução, uma das melhores práticas recomendadas pela própria Salesforce é o uso da programação declarativa em comparação com a programação imperativa, uma postura em que 74% dos líderes de TI atualmente usam ou afirmaram planejar utilizar. Mas qual seria a diferença entre elas?

A programação imperativa, também chamada de customização, faz uso de conhecidas linguagens de programação – como Python ou Java – para dizer exatamente ao computador o caminho que ele deve percorrer. No Salesforce, se aplica principalmente no uso de código Apex, classese de componentes Aura e Lightning (LWC).

A programação declarativa, por sua vez, utiliza uma abordagem “cliques, sem código”, na qual através de interfaces simples de trabalhar o usuário constrói processos dizendo ao computador apenas o resultado final e deixando que ele elabore o caminho para chegar até lá, a partir de códigos previamente escritos. No Salesforce padrão, se aplica principalmente no uso de regras de validação, processos e fluxos.

Por vezes a programação imperativa pode se mostrar atraente, por permitir a implantação de praticamente qualquer regra de negócio presente no cliente. Entretanto, por trabalhar com milhares e milhares de linhas de código, há uma grande complexidade em realizar a sua manutenção e implementar novos requisitos, aumentando consideravelmente os custos do projeto e o Time-to-Market de novas implantações. Além disso, o desenvolvimento imperativo consome os limites da organização, enquanto o declarativo não.

Como então verificar se minha organização apresenta um elevado nível de customização? Um dos parâmetros fundamentais é verificar a porcentagem de código Apex e o número de caracteres de código utilizados pela organização, o que pode ser checado em Setup > Apex Classes. Cada linha simboliza uma necessidade de manutenção complexa e requer maior tempo de desenvolvimento.

Um outro dado interessante a ser avaliado é o número de processos e de fluxos construídos em comparação com o número de classes e triggers. A própria Salesforce recomenda processos e fluxos para automações mais simples; a ausência ou baixa quantidade deles pode se tornar um problema maior no futuro (imagine atingir o limite de código Apex, por exemplo).

Isso significa que o desenvolvimento em código deve deixar de ser executado? De forma alguma. Por vezes requisitos de negócio complexos irão necessitar de código em qualquer projeto. Entretanto, para requisitos mais simples e todas as vezes em que for possível utilizar soluções não customizadas, este deve ser o caminho a ser trilhado. Por que utilizar uma chave de fenda para prender um prego se temos um martelo, não é mesmo?

Certos requisitos, contudo, parecem difíceis de serem implementados sem código. Como construir uma API de forma declarativa, por exemplo? Ou elaborar um componente de tela para exibir dados de diversos objetos com uma ferramenta drag-and-drop? Ou até mesmo gerar templates de documentos realizando o mapeamento dos campos também sem Apex, de modo que até o seu consultor de backoffice consiga realizar alterações no mesmo? Esta é a proposta do Salesforce Industries, que busca potencializar o desenvolvimento declarativo. Mas este já é o assunto do nosso próximo artigo desta série. Até lá!