Skip to content

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:

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%
  • 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

Últimas novedades 
de EGA Futura

EGA Futura incorpora toneladas de vídeo-tutoriales

La gestión visual de la información se hace cada vez más fácil en EGA Futura

La Plataforma EGA Futura crece en transparencia con su servicio de monitoreo de productos

EGA Futura le permite trabajar a sus Clientes de manera Remota en la Era Post-Digital

1954
Desde hace más de 25 años potenciamos a las Empresas de Iberoamérica

🎬 Video de Juan Manuel Garrido » Claves para tu Productividad diaria 🙌✅

🎬 Video de EGA Futura » Facturación Electrónica en Uruguay » Conceptos básicos con EGA Futura Windows

🎬 Video de EGA Futura » Facturación Electrónica en Uruguay » Configuración de EGA Futura Windows

🎬 Video de EGA Futura » Facturación Electrónica en Uruguay » Funcionamiento con EGA Futura Windows

🎬 Video de EGA Futura » Configuración de la Plataforma EGA Futura

🎬 Video de EGA Futura » Configuración de usuario en EGA Futura

🎬 Video de EGA Futura » Como automatizar la publicación en Redes Sociales?

🎬 Video de Juan Manuel Garrido » Cómo restaurar la configuración de fábrica de EGA Futura Windows sin perder la información

🎬 Video de Juan Manuel Garrido » Factura electrónica: Prueba de Factura Electronica previa a la activacion

🎬 Video de EGA Futura » Como se registran los Beneficios de cada Empleado en la base de datos de EGA Futura

🎬 Video de EGA Futura » EGA Futura Time Clock » Reloj de Control horario y asistencia

🎬 Video de EGA Futura » Como registrar Observaciones en un Empleado dentro de EGA Futura People?

🎬 Video de EGA Futura » Cómo registrar la Educación de cada Empleado en EGA Futura People?

🎬 Video de EGA Futura » Como hacer la Desvinculación de un Empleado? (Offboarding)

🎬 Video de EGA Futura » Como registrar Habilidades o Skills de empleados dentro de EGA Futura

🎬 Video de EGA Futura » Como hacer el Onboarding o Proceso de Incorporación de un Empleado?

🎬 Video de EGA Futura » Cómo administrar Turno de trabajo dentro de EGA Futura

🎬 Video de EGA Futura » Que es un Ticket interno dentro de la Plataforma EGA Futura

🎬 Video de EGA Futura » Que son los Entrenamientos de Empleado en EGA Futura people?

🎬 Video de EGA Futura » Qué son los Epics dentro de EGA Futura

🎬 Video de EGA Futura » Qué es EGA Futura People?

🎬 Video de EGA Futura » EGA Futura People » Asistencias

🎬 Video de EGA Futura » Soporte EGA Futura » Software de Gestión Windows vs Software de Gestión Nube 🤩

🎬 Video de EGA Futura » ツ Comparando un Objeto con un Fichero

🎬 Video de EGA Futura » ✍( ͡* ͜ʖ ͡*) ¿Qué es una Aplicación?

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