Evaluar las personalizaciones de su organización
Objetivos de aprendizaje
Después de completar esta unidad, podrá:
- Identificar el negocio y el valor tecnológico de las evaluaciones de estado actual
- Identificar qué buscar en una base de código
- Identificar cómo examinar procesos y personalización declarativa
En su obra titulada La razón en el sentido común, el poeta y filósofo George Santayana escribió: “Aquellos que no pueden recordar el pasado están condenados a repetirlo”. Lo mismo se puede decir de los equipos que desarrollan aplicaciones. Tomarse el tiempo para identificar qué se creó en su organización (y por qué se creó) y qué estándares se utilizaron para ello lo predispone para tener éxito en el futuro.
Iniciar acciones de implementación después de observar el estado actual de su organización le permite identificar con claridad los problemas antes de empezar a hacer cambios. Un ejemplo es la identificación de deuda técnica (esas decisiones de implementación que al principio tenían sentido y ahora son un impedimento para la innovación). También puede encontrar oportunidades para interactuar mejor con las partes interesadas correctas y realizar ajustes al equipo antes de que los procesos avancen demasiado.
Observar la forma en que ha trabajado antes de cambiarla tiene muchos beneficios iguales para los equipos de entrega de aplicaciones y de tecnología. También puede tener la oportunidad de identificar qué problemas o frustraciones en los sistemas actuales provienen de herramientas o tecnología obsoletas, y cuáles provienen de errores humanos. Estos errores de origen humano son los que debe resolver antes de adoptar cualquier tecnología o funcionalidad nueva.
Entonces, ¿cómo empieza a examinar el estado actual de su organización?
Examinar el código
Examinar la base de código puede parecer difícil. En especial, si es nuevo en la organización o si la organización tiene una gran cantidad de códigos. Pero entender cómo las diferentes partes de la organización se relacionan entre si es una parte esencial y necesaria para identificar cómo empezar a gestionar la organización en unidades más precisas y significativas.
Entonces, ¿qué hay que buscar en el código?
Tipo de código | Qué hay que buscar | Preguntas que se deben formular |
|---|---|---|
Desencadenadores | 1. Patrones de desencadenadores 2. Lógica de desencadenadores | ¿Tiene su organización un desencadenador por cada objeto? ¿Hay una lógica comercial o de aplicación escrita directamente en un desencadenador? ¿Los desencadenadores transfieren lógica o funcionalidad a otras clases (controladores de desencadenadores)? |
Clases de Apex | 1. Convenciones de nomenclatura 2. Comentarios 3. Versión de API | ¿Las clases de Apex utilizan prefijos comunes o espacios de nombres para agrupar unidades de grupo de código? ¿Las clases tienen nombres similares basados en la funcionalidad? ¿Están documentados en los comentarios el objetivo y la autoría de códigos? ¿Las clases tienen comentarios que ayudan a aclarar la función? ¿Qué versión de API utilizan las clases? |
Pruebas de Apex | 1. Patrones/unidades de prueba 2. Cobertura de código 3. Gestión de datos de prueba | ¿Cómo se relacionan las pruebas con otro código? ¿Tiene cada clase sus propias pruebas? ¿Las pruebas son organizadas en grupos funcionales? ¿Hay partes de la base de código que no estén cubiertas por pruebas? ¿Las pruebas dependen de factores de datos comunes o de recursos estáticos? ¿Hay pruebas que utilizan la anotación ‘seeAllData=True’ o ejecutan una versión de API anterior a 24? |
Eventos y componentes de Lightning | 1. Convenciones de nomenclatura 2. Comentarios 3. controladores Apex 4. Versión de API | ¿Los componentes utilizan prefijos comunes o espacios de nombres para crear grupos? ¿Los componentes tienen nombres claros y relacionados con la funcionalidad? ¿Los eventos Lightning están especificados para ser eventos de aplicación o eventos de componentes? ¿El objetivo y la autoría de los componentes están documentados de manera clara en los comentarios o en los archivos de documentación Aura? ¿Los componentes utilizan controladores Apex? ¿Qué versiones de API utilizan los componentes y los eventos? |
Visualforce | 1. Convenciones de nomenclatura 2. Comentarios 3. controladores Apex 4. Versión de API | ¿Las páginas y los componentes de Visualforce utilizan prefijos comunes o espacios de nombres para crear grupos? ¿Las páginas tienen nombres claros y relacionados con la funcionalidad? ¿Las páginas utilizan controladores Apex? ¿Qué versiones de API usan las páginas? ¿Las páginas se utilizan con alguna plantilla de email? |
Estos ejemplos lo ayudan a identificar patrones dentro del código de su organización. Sin embargo, estas técnicas quizá no lo ayuden a comprender cada fragmento de la base de código. O, si la base de código no parece estar organizada de forma coherente, tal vez necesite intentar otra forma de descubrir cómo está conectado el código de su organización.
Aquí es donde Dependency API puede ayudarlo. Ejecutando nuevos tipos de consultas, podrá identificar cómo están organizados los metadatos y el código. Por ejemplo, puede echarle un vistazo a un componente Lightning en una página en particular o a un controlador Apex de una página de Visualforce específica, y rastrear todas las otras partes de los metadatos que de alguna manera se conecten con ese controlador Apex o componente Lightning. También puede utilizar las consultas para identificar las partes de metadatos que ya no están en uso y decidir si es seguro eliminarlas.
Examinar los procesos y la personalización declarativa
Entonces, ¿qué sucede con las personalizaciones declarativas que llevó a cabo en su organización? ¿Cómo puede empezar a mirar los elementos que desarrolló con clics y no con código?
Una forma de empezar es usar Salesforce Optimizer. Esta herramienta recomienda formas de mejorar algunas funciones en su implementación de Salesforce. Después de analizar el informe de Optimizer, puede mirar más en profundidad los procesos y las personalizaciones declarativas de su organización.
¿Qué debería tener en cuenta?
Tipo de personalización | Qué hay que buscar | Preguntas que se deben formular |
|---|---|---|
Flujo / flujo visual | 1. Convenciones de nomenclatura 2. Patrones relacionados con objetos 3. Versiones activas/inactivas 4. Lógica del flujo 5. Pantallas de flujo | ¿Los flujos utilizan prefijos comunes o nombres similares para crear grupos? ¿Los flujos tienen nombres relacionados claramente con la funcionalidad? ¿Los flujos tienen descripciones claras y actualizadas? ¿Con qué objetos interactúa el flujo? ¿Cuál es la relación entre los flujos inactivos o versiones de flujo, y los flujos activos? ¿Los flujos colocan la funcionalidad común en subflujos, acciones invocables o acciones rápidas? Si los flujos tienen pantallas, ¿están basadas en componentes de Lightning? ¿Las pantallas dependen de ciertos objetos y campos? ¿Existen automatizaciones desactualizadas que deban convertirse en flujos? |
Objetos y campos | 1. Convenciones de nomenclatura 2. Tipos de registro 3. Formatos de página 4. Permisos 5. Anulaciones de acción | ¿Fueron los objetos personalizados creados los que duplicaron el comportamiento de objetos estándar? ¿Varias unidades de negocio usan los mismos objetos o campos? ¿Están diferenciadas la lógica de negocio y las validaciones por los tipos de registro? ¿Los objetos y campos tienen descripciones claras y actualizadas? |
Desea crear un sentido claro de qué tan bien se organizaron los procesos y las personalizaciones declarativas hasta la fecha. Si encuentra que su organización no está organizada como le gustaría, no hay problema. Ahora es el momento de identificar en qué sectores puede trabajar el equipo para mejorar la calidad y desarrollar algunos estándares que puedan ayudar a construir una organización más positiva de ahora en adelante. También puede identificar los proyectos que desee tratar primero para reformar partes de su organización.
No se pierda las novedades
Los próximos meses sumaremos más recursos y oportunidades para llevar estos conceptos a la práctica. Tendrá la posibilidad de explorar formas de desenredar metadatos y crear paquetes, y aprender sobre la gestión de paquetes desbloqueados.
Recursos
- Artículo de BA Times: ¿Qué sucede con el estado actual?
- Artículo de Atlassian: Escapar del agujero negro que es la deuda técnica
- Publicación de blog: Pagar la deuda técnica
- Ayuda de Salesforce: ¿Qué funciones evalúa Optimizer?