Mejore el rendimiento del código con el analizador de código de Salesforce ☁️

En octubre de 2022, compartimos noticias emocionantes sobre el lanzamiento de la versión 3.x de Salesforce Code Analyzer , nuestro escáner de código gratuito que reúne varios motores de análisis de código de fuente abierta bajo una experiencia unificada de Salesforce CLI. En particular, profundizamos en Salesforce Graph Engine , que utiliza análisis de flujo de datos para detectar vulnerabilidades de seguridad avanzadas en el código. Hoy, compartiremos cómo, con nuestro lanzamiento de la versión 3.9, estamos evolucionando Graph Engine con nuevas reglas para ayudarlo a mejorar el rendimiento de su código. Entonces, ¡siéntese, relájese y prepárese para acelerar su código!

Nuevas reglas de rendimiento en la versión 3.9

Con Code Analyzer versión 3.9, presentamos una nueva regla de rendimiento, UnimplementedTypeRule , que detecta si tiene código Apex sin usar en su solución. Específicamente, detecta interfaces no utilizadas y clases abstractas. Complementa otra regla que presentamos en la versión 3.8, UnusedMethodRule que detecta métodos no utilizados. Puede usar estas dos reglas para eliminar el código no utilizado y hacer que su código sea más pequeño, más eficiente y, por lo tanto, más eficaz (pero hablaremos de eso más adelante).

Agregamos estas nuevas reglas a Salesforce Graph Engine. Como repaso rápido, Graph Engine generalmente escanea el código utilizando un enfoque basado en rutas usando algo que llamamos "análisis de flujo de datos" (DFA). Con este enfoque, Graph Engine consume todo el código fuente simultáneamente y asimila esta información para producir una mejor comprensión de lo que sucede en el código. Este enfoque basado en rutas es bastante diferente del árbol de sintaxis abstracta (AST), un enfoque de análisis estático utilizado por todos los demás motores en Code Analyzer, como PMD y ESLint.

Sin embargo, estas reglas son especiales. En lugar de seguir un enfoque basado en rutas, utilizamos la comprensión holística de Graph Engine de cómo se estructura el código y la información de dependencia adicional. Este enfoque basado en gráficos aún usa análisis estático, pero es más efectivo que un enfoque basado en AST puro para detectar si esas interfaces, clases abstractas y métodos se están usando o no, mientras se mantiene un gran rendimiento.

Dado que este enfoque basado en gráficos es mucho más rápido que un enfoque basado en rutas, agregamos estas reglas al comando scanner:run en lugar de scanner:run:dfa utilizado por otras reglas de Graph Engine.

Cómo afecta el código no utilizado al rendimiento de su solución

Cuando su código Apex se implementa en una organización de Salesforce, se compila y está disponible para ser invocado para su ejecución directa o indirectamente a través de múltiples puntos de entrada. Llamamos a estos puntos de entrada "fuentes" en Graph Engine. Hay muchos tipos diferentes de puntos de entrada, pero los ejemplos incluyen código Apex invocado desde llamadas API o código Apex invocado desde interacciones de usuarios con componentes Lightning.

Es importante destacar que todo el código de Apex se compila, independientemente de si hay alguna fuente que lo invoque. Si con el tiempo está agregando funcionalidad adicional continuamente, es probable que parte de su código se encuentre en su organización (o en las organizaciones de sus clientes si es un socio de AppExchange) sin siquiera ejecutarse. Esto es especialmente relevante si tiene una solución anterior que diferentes desarrolladores han creado gradualmente a lo largo de los años y no ha tenido la oportunidad de realizar una refactorización significativa.

Ahora, recuerde que Salesforce es multiinquilino y, por lo tanto, varios clientes se ejecutan en la misma instancia de Salesforce y, lo que es más importante, comparten la potencia informática, el uso de la memoria y los subprocesos para ejecutar Apex dentro de esa instancia en particular. Si bien contamos con medidas de seguridad para optimizar la forma en que asignamos y distribuimos los recursos entre los clientes, se recomienda tener un código más pequeño y eficiente.

Hay ventajas adicionales. Tener menos código significa:

• Es menos probable que alcance los límites del regulador en el tamaño de los caracteres del código Apex
• Implementar metadatos, instalar y actualizar paquetes es más rápido
• Es mucho más fácil para usted mantener el código, incluso no necesita tantas pruebas unitarias.
• El tiempo de compilación de Apex es más corto, lo que acelera el desarrollo y la implementación

Además de las reglas de rendimiento, si aprovecha las diversas reglas de calidad de código disponibles en Code Analyzer a través de PMD, también puede hacer que su código sea más legible e identificar oportunidades para la refactorización de código.

Instale la última versión de Code Analyzer

Comience a usar estas nuevas reglas de rendimiento en Code Analyzer de inmediato.

Asegúrese de actualizar a la última versión de la CLI de Salesforce:

Y, si aún no lo ha hecho, instale el complemento Salesforce Code Analyzer:

Si ya había instalado Code Analyzer anteriormente, simplemente ejecute sfdx update para asegurarse de que tiene la última versión. ¡Eso es todo!

Limpiemos el código no utilizado

Para comenzar, instale nuestra aplicación de muestra.

Clone la rama dev del repositorio de Code Analyzer.

A continuación, abra el directorio de muestra, donde encontrará un proyecto para una aplicación que funcione.

Tenga en cuenta que FlsHelperClass.cls contiene un método denominado verifyCreateablePositiveStyle .

Ahora, observe UnusedInterface.cls , que contiene la interfaz pública UnusedInterface .

No usamos verifyCreateablePositiveStyle en ningún lugar dentro de nuestra aplicación de muestra, y tampoco hay implementaciones de UnusedInterface .

Ahora ejecute Code Analyzer en el directorio del proyecto.

Tenga en cuenta que necesitamos usar --engine sfge y proporcionar --projectdir para ejecutar estas reglas con Graph Engine.

Esto generará una salida en formato CSV donde verá dos infracciones informadas por Code Analyzer.

"UnusedMethodRule","Method verifyCreateablePositiveStyle in class FlsHelperClass is never invoked"

y

"UnimplementedTypeRule","Extend, implement, or delete interface UnusedInterface"

Si elimina verifyCreateablePositiveStyle y UnusedInterface, y vuelve a ejecutar Code Analyzer:

Usted obtiene:

Executed engines: sfge. No rule violations found.

¡Eso es todo! Limpiaste el código en nuestra aplicación de muestra. Esto significa que si tuviera que implementar este código en una organización de Salesforce, solo compilaríamos el código que realmente se necesita y, por lo tanto, mejoraría el rendimiento de su solución. ¡Felicidades!

Pruébelo en su propio código y lea más sobre Code Analyzer y Graph Engine en nuestra documentación .

Conclusión

El equipo de Salesforce Code Analyzer mejora constantemente Code Analyzer. Nos encantaría escuchar sus comentarios y solicitudes de funciones .

Recursos

Sobre los autores

Josh Feingold es ingeniero sénior con casi siete años de experiencia en Salesforce. Comenzó contribuyendo al éxito de CPQ Salesforce como una solución de configuración, precio y cotización escalable y de alto rendimiento. Ahora, como parte del equipo de análisis de código de Salesforce, ha dirigido su mirada hacia la comunidad de clientes y socios de Salesforce, trabajando para brindarles las herramientas para escribir código seguro, eficaz y mantenible.

John Belo es director de gestión de productos para la plataforma ISV y se centra en Salesforce Code Analyzer, AppExchange App Analytics, así como en otras áreas dentro de Packaging. Ha estado en Salesforce durante más de siete años y siempre ha sido parte del equipo de AppExchange. Comenzó liderando un equipo de evangelistas técnicos de ISV en EMEA y ahora es parte del equipo de administración de productos de AppExchange, con la intención de ayudar a los ISV a tener el mayor éxito posible.