Patrones de calidad de código


Obtenga más información acerca de la optimización de recursos y costos bien arquitectada → Organización de código

Esta página de patrón consolidado cubre la calidad del código y las prácticas de mantenimiento para Optimización de recursos. Incluye directrices sobre decisiones de código estándar frente a personalizado, gestión de deudas técnicas, estándares de diseño, prácticas de documentación y gobernanza. Estos patrones ayudan a mantener la velocidad de desarrollo, reducir los índices de defectos y permitir la sostenibilidad de soluciones a largo plazo.

Patrones

Dónde buscarQué aspecto tiene
Desempeño a escala✅ Las pruebas validan que las soluciones declarativas cumplen los requisitos de desempeño en volúmenes de datos proyectados. Las pruebas de carga en Sandbox de copia completa con datos realistas confirman la capacidad de ampliación antes de la implementación de producción.
Análisis de capacidad de mantenimiento✅ El análisis de TCO compara la carga de mantenimiento a largo plazo de enfoques declarativos frente a personalizados incluyendo el esfuerzo de actualización, los requisitos de prueba y los requisitos de habilidades para equipos futuros.
Arquitectura de enfoque mixto✅ Las soluciones combinan enfoques declarativos y programáticos donde sea apropiado. El flujo orquesta lógica de alto nivel mientras Apex gestiona cálculos complejos. Los campos de fórmula calculan derivaciones sencillas mientras Apex procesa operaciones masivas.
Evaluación AppExchange✅ Antes de crear código personalizado, evalúe paquetes AppExchange existentes que proporcionan funciones similares. Documente resultados de evaluación incluyendo paquetes revisados, brechas de capacidad y comparación de TCO.

Patrones

Dónde buscarQué aspecto tiene
Visibilidad de retraso✅ Seguimiento de partidas de deuda técnicas en retraso con etiquetas claras, contexto que explica por qué el código necesita mejoras, impacto de negocio de dejarlo sin solucionar y esfuerzo de corrección estimado. La deuda invisible no se puede priorizar ni gestionar.
Mejora incremental✅ Regla de Boy scout aplicada durante el desarrollo de funciones: dejar código mejor de lo encontrado. Los equipos solucionan deudas de forma incremental durante el trabajo de funciones relacionadas en vez de requerir grandes proyectos de refactorización exclusivos. Las revisiones de código verifican mejoras incrementales.
Prevención sobre la reparación✅ Las puertas de calidad en CI/CD aplican estándares antes de que el código llegue a producción. Escáner de código, ApexGuru y mediciones de complejidad integradas en la validación de solicitudes de extracción. Los problemas de bloqueo evitan la combinación hasta que se resuelvan.

Antipatrones

Dónde buscarAspecto negativo
Gestión de retrasos⚠️ Deuda técnica reconocida verbalmente pero nunca seguida en retraso. Sin visibilidad sobre la acumulación de deudas. La corrección de deudas siempre se aplazó a favor del trabajo de funciones. La velocidad disminuye gradualmente, los equipos no pueden explicar por qué.
Omisión de puerta de calidad⚠️ Las puertas de calidad de CI/CD se omiten con frecuencia bajo presión de programación con intención de solucionarse más adelante. “Más tarde” nunca sucede. Fallos del escáner de código marcados como problemas conocidos e ignorados. Umbrales de complejidad elevados para acomodar implementaciones deficientes.
Sin capacidad de recuperación⚠️ 100% de la capacidad de sprint asignada al trabajo de funciones con capacidad cero para la solución de deudas técnicas. La deuda se acumula indefinidamente. Los grandes proyectos de refactorización requeridos cada 18-24 meses consumen trimestres completos.
Deuda de configuración⚠️ Los tipos de metadatos personalizados y la configuración personalizada se acumulan sin limpieza. La configuración no utilizada persiste indefinidamente. Producción tiene 50 registros de metadatos, solo 12 se utilizan actualmente. Sin documentación que explique el propósito de los valores de configuración.

Patrones

Dónde buscarQué aspecto tiene
Arquitectura de desencadenador✅ Patrón de controlador de desencadenador aplicado de forma coherente: desencadenadores ligeros delegan en clases de controlador, las clases de controlador organizan la lógica por contexto de desencadenador (antes de insertar, después de actualizar), los nombres de método claros revelan el propósito. Sin lógica de negocio en los archivos desencadenadores en sí.
Implementación de capa de servicio✅ Lógica de negocio encapsulada en clases de servicio separadas de controladores, desencadenadores y puntos de entrada por lotes. Clases de servicio reutilizables entre múltiples puntos de entrada sin duplicación. Borrar convención de nomenclatura (AccountService, OrderProcessor).
Patrón de selector✅ Consultas SOQL centralizadas en clases de selector por objeto (AccountSelector, OpportunitySelector). Los métodos de selector devuelven conjuntos de campos coherentes. Cambios de optimización de LDV aplicados una vez, afectando a todas las consultas.
Patrón de repositorio✅ Acceso a datos abstraído detrás de interfaces que permiten realizar pruebas con fuentes de datos simuladas. Las implementaciones de repositorios encapsulan estrategias de optimización, caché y construcción de consultas. La lógica de negocio depende de interfaces de repositorio, no de implementaciones concretas.
Estándares de diseño de componentes✅ Los componentes web Lightning siguen el principio de responsabilidad única, exponen propiedades para la configuración, emiten eventos para la comunicación principal, diseñados para la composición y la reutilización. Biblioteca de componentes documentada con ejemplos de uso.
Organización de código✅ La estructura de paquetes lógica agrupa clases relacionadas. Borre la separación entre lógica de dominio, acceso a datos, extremos de API y adaptadores de integración. Las dependencias del paquete fluyen en una dirección.

Antipatrones

Dónde buscarAspecto negativo
Desencadenadores⚠️ Toda la lógica de negocio incrustada directamente en archivos de desencadenador con condicionales profundamente anidados, sin separación de preocupaciones, sin clases de controlador. Más de 300 archivos de desencadenador de partidas mezclando validación, lógica de negocio y llamadas de integración. Imposible probar de forma efectiva.
Consulta en bucle⚠️ Consultas SOQL ejecutadas en bucles de iteración. Funciona con volúmenes de datos pequeños pero infringe el límite de consultas SOQL de 100 al procesar operaciones masivas. Solo se descubre cuando desencadena disparos en cargas de datos masivas en producción.
DML en bucle⚠️ Sentencias DML (insertar, actualizar, eliminar) ejecutadas en bucles de iteración. Incumple el límite de 150 declaraciones DML con operaciones masivas. Cada registro se procesa en transacciones de base de datos separadas en vez de un procesamiento masivo eficiente.

Patrones

Dónde buscarQué aspecto tiene
Registros de decisiones de arquitectura✅ Decisiones arquitectónicas significativas documentadas en ADR almacenadas en el control de versiones. Las evaluaciones de resultados de las actividades de desarrollo capturan el contexto (impulsores de negocio, restricciones técnicas), la decisión (lo que se eligió), las alternativas consideradas (por qué se rechazaron) y las consecuencias (compensaciones, condiciones para volver a visitar).