Impulse la coherencia y aumente las habilidades de los desarrolladores con una lista de verificación de mejores prácticas para desarrolladores ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Como desarrollador, líder de desarrollo, líder de tecnología o arquitecto técnico, ¿alguna vez ha tenido dudas sobre el código, por ejemplo, "¿Esa clase tuvo algún manejo de errores?" o "¿Ese método de prueba tenía alguna afirmación del sistema?" – ¿días después de que ya lo hayas aprobado? Todos hemos experimentado esos momentos en los que revisamos el código maduro en una fecha mucho posterior y nos preguntamos por qué tomamos decisiones particulares o deseamos tener una referencia de historia de usuario. Afortunadamente, estos contratiempos e inconsistencias en la calidad del código se pueden prevenir con un simple proceso. Ingrese: listas de verificación de desarrolladores y revisiones de código.

Si desea que sus revisiones de código sean más confiables (junto con su herramienta de análisis de código), pero aún no ha implementado un proceso para lograr una mayor coherencia, esta lista de verificación es para usted.

Nota: es posible que recuerde nuestra Lista de verificación de prácticas recomendadas para desarrolladores de 2015 . La siguiente es una lista de verificación actualizada, que incluye herramientas y temas adicionales de versiones más recientes de Salesforce Platform.

Público objetivo: esta es una lista de verificación de revisión de código que deben completar los desarrolladores, los líderes técnicos o de desarrollo y los arquitectos técnicos mientras revisan el código por pares.

Beneficios: las revisiones de código ayudan a los equipos a adherirse a los estándares del código para mejorar la calidad del código y reducir los errores. Además, las revisiones de código mejoran las habilidades de los desarrolladores, crean una cultura de equipo y fomentan la tutoría.

Uso y medición sugeridos

Revise la siguiente lista de verificación para desarrolladores en equipo. Decida qué secciones se aplican al código base de su organización y cuáles no.
Si su equipo usa una herramienta de análisis de código , use esta lista de verificación después de la herramienta de análisis de código.
Desarrolladores: use esta lista de verificación para revisar y mejorar su propio código una vez que haya completado el desarrollo.
Revisores de código: use esta lista de verificación mientras realiza una revisión por pares.
La lista de verificación también se puede usar para un flujo de trabajo de aprobación o firma de pares en el control de versiones antes de que se comprometa en la rama de lanzamiento.
Para medir el ROI de la lista de verificación del desarrollador, realice un seguimiento de lo siguiente antes y después de que la lista de verificación se convierta en parte de sus procesos de desarrollo:
- La cantidad de horas dedicadas a revisar el código.
- El número y la gravedad de los problemas registrados o los defectos abiertos.
- El rendimiento de la organización de Salesforce

Lista de verificación para desarrolladores

Información y comentarios

Los comentarios siempre deben agregar valor. Los elementos marcados como "sugerir" a continuación indican que se desvían de las mejores prácticas; aunque pueden agregar demasiado ruido en el código, también pueden agregar valor cuando se trabaja con desarrolladores junior.

La descripción del bloque de comentarios superior explica qué hace el código / propósito comercial
Si solo se modificó el código, el bloque de comentarios superior también explica por qué se modificó el código
El bloque de comentarios superior incluye números de referencia de característica / historia (característica / historia original Y cualquier característica / historia para modificaciones)
El bloque de comentarios principales incluye la fecha en que un desarrollador modificó la clase por última vez (formato: 30 de diciembre de 2011)
El bloque de comentarios superior incluye cualquier otra clase, flujo o constructor de procesos que esté relacionado
El bloque de comentarios superior incluye el nombre del desarrollador que modificó el código por última vez
Sugerir que los comentarios en línea se incluyan en la línea de arriba de las variables que explican las variables
Sugiera que se incluyan comentarios en la línea sobre todas las consultas SOQL que expliquen por qué se requiere la consulta
Sugiera que se incluyan comentarios en línea en la línea sobre cualquier bucle que explique qué hace el bucle y por qué es necesario
Sugerir que los comentarios en línea se incluyan en la línea sobre cualquier DML explicando qué se está cometiendo y por qué
Sugiera que los comentarios en línea se incluyan en la línea de arriba de lo que se captura en try / catch y explique qué se maneja
Los comentarios sugeridos en línea se incluyen en la línea anterior a los límites que se están verificando (si están marcados) e incluye los límites

Desarrollo de Apex

Se utilizó desarrollo declarativo cuando fue aplicable
- La solución no se pudo lograr declarativamente
- La clase usa el método invocable si corresponde
- Se revisó el orden de ejecución si se utilizan reglas de asignación, invocables, futuras o en cola (el mecanismo de activación está bajo en la lista)
El código está en la última versión de API

Se sigue el marco de activación

Solo un disparador no administrado por objeto
No hay lógica en el gatillo
No hay trabajo en el manejador de gatillo
El trabajo está en clases de ayuda.
El controlador es específico del contexto
El controlador de gatillo / gatillo evita la recursividad
Las configuraciones personalizadas se utilizan en el marco de derivación. Marco de registro útil adicional aquí.
Las actualizaciones / cambios al registro actual en contexto deben realizarse antes de insertar / actualizar el contexto

El código está masificado

No hay consultas SOQL en bucles
Todas las consultas SOQL son selectivas
El código incluye comprobaciones nulas
No hay declaraciones DML en bucles
Los métodos auxiliares se agrupan
Las recopilaciones y las consultas se simplifican
Los bucles son eficientes para grandes volúmenes
Los Apex futuros / en cola / por lotes / programados se utilizan de forma adecuada y escasamente
- ¿Pero por qué, preguntas? Con demasiada frecuencia, vemos que las soluciones asincrónicas se implementan por razones "incorrectas". NO use async Apex cuando no esté seguro del requisito completo, ni cuando Apex transaccional funcionará con un poco de refactorización. A veces caemos en esta trampa porque los métodos asíncronos nuevos son más fáciles de implementar que revisar un requisito o refactorizar el código existente. Esto da como resultado una deuda técnica, no lo haga.
- En lugar de:
  1. Respeta las limitaciones
  2. Alcance todos los requisitos y casos de uso
  3. Implementar las mejores soluciones para los requisitos

Se utilizan configuraciones / etiquetas / metadatos personalizados
- No se codifican ID, nombres, valores de listas de selección, descripciones, cadenas, números, etc.
- Se utilizan etiquetas personalizadas y configuraciones personalizadas jerárquicas en lugar de codificación rígida
- El diseño utiliza metadatos personalizados en lugar de configuraciones personalizadas cuando corresponde
El código cumple con la seguridad y verifica los permisos antes de ejecutar DML
- Con compartir y sin compartir, las palabras clave se evitan en el dominio Apex para garantizar que el contexto de la llamada impulse este aspecto
- Las mejores prácticas de seguridad se siguen en la configuración
- El análisis de código estático a través de una herramienta de terceros / PMD se ejecutó contra el desarrollo de Apex
  - El código se refactoriza en función de una herramienta de terceros / comentarios de PMD
  - Si una herramienta de terceros / PMD identifica un problema y el código no se puede refactorizar, el arquitecto aprueba la excepción
Se utilizan convenciones de nomenclatura de mejores prácticas
- El nombre del objeto está incluido en la clase (disparador, controlador, la clase de prueba lleva el nombre de la clase que está probando)
- El nombre de la clase explica cuando se usa (ayudante)
Se utiliza un marco de registro de errores para detectar y gestionar las excepciones integradas , así como las excepciones personalizadas y los errores de registro.
Las integraciones son revisadas por el arquitecto de integración y siguen las mejores prácticas de integración.
- Las llamadas NO se realizan en la carga de la página a menos que lo apruebe el arquitecto
- Los componentes integrados están dentro de la subpestaña o en acordeón en las páginas a menos que sean aprobados por el arquitecto.

Componentes web Lightning

Las llamadas al servidor son limitadas (pase información entre componentes cuando sea posible)
Las consultas solo contienen columnas en SELECT que se usan / necesitan
Las consultas tienen un LÍMITE establecido y usan la paginación cuando es necesario
Los datos se cargan de forma diferida cuando es posible y no se precargan
- Se evaluaron las ubicaciones de carga diferida:
  - Acciones rápidas o globales
  - Barra de utilidades
  - Pestañas del Creador de aplicaciones
  - Use aura:if , lightning:tabset y lightning:tab cuando corresponda
El almacenamiento en caché de datos se usa cuando es posible y se evaluó
El código usa un esquema estático en lugar de un esquema dinámico cuando es posible
El código NO usa pub / sub para la comunicación entre padres e hijos o entre padres e hijos
- Un componente principal se comunica con un componente secundario mediante:
  - Configuración de las propiedades @api del niño (receta apiProperty)
  - Llamar a un @apiMethod (anteriormente llamado @apiFunction) definido en el componente secundario
- A se comunica componente secundario con su componente de matriz mediante el envío de un evento de DOM con o sin una carga útil de datos ( eventWithData receta y eventSimple receta respectivamente).
  - Utilice siempre CustomEvent (no Event ), incluso cuando el evento no tenga una carga útil de datos
  - Prefiere pasar datos utilizando tipos de datos primitivos en la carga útil del evento
  - Si debe pasar datos utilizando un tipo de datos no primitivo en la carga útil del evento, pase una copia del objeto o matriz para evitar la filtración de objetos privados y mutaciones impredecibles por parte del oyente del evento.
  - Si necesita pasar un registro, pase el ID del registro
- Utilice el canal Lightning Messaging para comunicarse a través del DOM en la página Lightning; c/pubsub solo debe usarse si existen limitaciones para LMS
El uso de bibliotecas de JavaScript de terceros está limitado o eliminado si es posible
- Prefiere Lightning SLDS (incluidas las imágenes) a las imágenes externas, bloquea el tamaño de la imagen (sin alta resolución)
- Utilice un personalizador de CSS personalizado si se necesita una apariencia / sensación única
El código es inclusivo y hace uso de los atributos de accesibilidad.
Minimizar el número de veces que se procesa el componente
El código hace uso de Canvas cuando corresponde en lugar de iFrame; Los iFrames a veces son más fáciles pero brindan menos funcionalidad
El código no hace uso de window.location ( ver documentos )
Los componentes de Aura se migran a LWC cuando es posible
- El arquitecto firma cuando el componente Aura no se puede migrar y necesita actualizarse
El inspector de componentes Lightning se utiliza para monitorear el impacto en el rendimiento de los nuevos componentes.
El componente sigue las mejores prácticas de LWC
Cada LWC tiene una prueba de Jest que prueba el comportamiento del componente de forma aislada

Clases de prueba de Apex

Las pruebas son significativas
- Las pruebas cubren un escenario positivo
- Las pruebas cubren un escenario negativo
- Prueba de escenario nulo de cobertura
Las pruebas utilizan configuraciones personalizadas en lugar de codificación rígida
- Para pruebas masivas (por ejemplo, crear registros xx, insertar registros xx, afirmar que los registros xx cumplen con el escenario)
- Para configurar / verificar valores específicos de escenarios de prueba (ID, nombres, valores de lista de selección, descripciones, números, etc.)
Las pruebas proporcionan una cobertura de código superior al 90%
- Si no puede lograr el 90%, la explicación está en el bloque de comentarios en la parte superior de la clase y se requiere una firma adicional
- Un objetivo del 90% garantiza un búfer para el requisito de implementación del 75% y implementaciones mucho menos estresantes
Las pruebas hacen uso de la clase test factories / utils en lugar de crear sus propios datos
- Los datos de prueba incluyen escenarios con entradas válidas y no válidas, por ejemplo, diferentes tipos de datos o valores
Las pruebas incluyen System.Assert para validar los resultados esperados
Las pruebas utilizan el método runAs para probar en diferentes contextos de usuario y compartir
Las pruebas no usan SeeAllData
Las pruebas comprueban escenarios masivos
Las pruebas usan Ordenar por para verificar el orden esperado
Las pruebas incluyen comentarios (consulte la sección de comentarios)
Las pruebas usan startTest () y stopTest ()
Las pruebas imponen el uso compartido
Las pruebas no están integradas en la clase principal
Las pruebas aprovechan el marco de prueba simulado para probar los servicios web
Aprovechamiento de las pruebas @testSetup anotación para crear datos que puedan reutilizarse en todos los métodos de prueba.
- Evite crear datos de prueba para cada método de prueba individualmente

Rendimiento

El código está escrito para los requisitos de desempeño.

Conclusión

Aunque esta lista de verificación es una herramienta destinada a mejorar las revisiones de código y unificar a los equipos de desarrolladores en torno a las mejores prácticas, también puede ser bueno que las personas la revisen y reflexionen a medida que contribuyen a su base de código y aumentan sus habilidades.

Como desarrollador, líder de desarrollo, líder de tecnología o arquitecto técnico, ¿conocía todas las mejores prácticas cubiertas por la lista de verificación? Con suerte, esta lista de verificación le sirvió para recordar consejos y trucos importantes que puede haber olvidado después de meses o años de concentrarse en otra parte de la plataforma. Puede haber otros procesos de gobernanza en su empresa que puedan beneficiarse de una lista de verificación similar a esta. También sugerimos evaluar esta lista de verificación con su código base para abreviarla o adaptarla a sus necesidades actuales.

¡Haga suya esta lista de verificación y logre un desarrollo mejor y más consistente!

Sobre el Autor

Shannon Tran es una directora de arquitectura técnica certificada 13x, consultoría técnica en Salesforce y actual entrenadora de RAD Apex . Antes de unirse a Salesforce, Shannon participó en la comunidad como autora de Salesforce Finessed, como presentadora de Dreamforce, y a través de varios podcasts y en eventos dirigidos por la comunidad Trailblazer. Ha trabajado con sistemas de TI empresariales durante más de 10 años.

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/01/drive-consistency-and-grow-developer-skills-with-a-developer-best-practices-checklist.html