La inclusión de scripts en JSP dificulta la depuración de problemas en el código. Además, al incluir scripts en JSP, es difícil separar la lógica empresarial de la capa de vista, lo que infringe el principio de responsabilidad única y el patrón de diseño de MVC.
El código se escribe una vez, pero se lee muchas veces. Pasar algún tiempo por adelantado para limpiar el código que escribimos generará dividendos en el camino mientras nosotros y otros desarrolladores necesitemos leerlo más tarde.
Idealmente, otro programador no debería tener que abrir un módulo para entender lo que hace. Del mismo modo, deberían poder decir lo que hace un método sin leerlo. Cuanto mejor podamos suscribirnos a estas ideas, más fácil será leer nuestro código y más rápido podremos escribir y cambiar nuestro código.
En la base de código de AEM se utilizan las siguientes convenciones:
<Interface>Impl
, por ejemplo: ReaderImpl
.<Variant><Interface>
, es decir: JcrReader
y FileSystemReader
.Abstract<Interface>
o Abstract<Variant><Interface>
.com.adobe.product.module
. Cada artefacto Maven o paquete OSGi debe tener su propio paquete.Tenga en cuenta que estas convenciones no necesariamente tienen que aplicarse a las implementaciones de los clientes, pero es importante que las convenciones se definan y se respeten para que el código pueda mantenerse.
Idealmente, los nombres deberían revelar su intención. Una prueba de código común para los casos en los que los nombres no son tan claros como deberían ser es la presencia de comentarios que explican para qué sirve la variable o el método:
Unclear |
Borrar |
int d; //tiempo transcurrido en días |
int elapsedTimeInDays; |
//obtener imágenes etiquetadas |
public Lista getTaggedImages() {} |
DRY establece que el mismo conjunto de códigos nunca debe duplicarse. Esto también se aplica a cosas como literales de cadena. La duplicación de códigos abre la puerta a defectos cada vez que algo tiene que cambiar y debe buscarse y eliminarse.
Las reglas CSS deben ser específicas del elemento de destinatario en el contexto de la aplicación. Por ejemplo, una regla CSS aplicada a .content.center sería excesivamente amplia y podría afectar a muchos contenidos en todo el sistema, lo que requeriría que otros usuarios anularan este estilo en el futuro. .myapp- centertext sería una regla más específica ya que especifica ** texto centrado en el contexto de la aplicación.
Cuando una API está en desuso, siempre es mejor encontrar el nuevo método recomendado en lugar de depender de la API en desuso. Esto garantizará que las actualizaciones sean más fluidas en el futuro.
Cualquier cadena que no proporcione un autor debe envolverse en una llamada al diccionario i18n de AEM mediante I18n.get() en JSP/Java y CQ.I18n.get() en JavaScript. Esta implementación devolverá la cadena que se le pasó si no se encuentra ninguna implementación, de modo que esto oferta la flexibilidad de implementar la localización después de implementar las características en el idioma principal.
Mientras que las rutas en el JCR no deben contener espacios, su presencia no debe provocar que el código se rompa. Jackrabbit proporciona una clase de utilidad Text con métodos escape() y escapePath(). Para JSP, la interfaz de usuario de Granite expone una función granite:encodeURIPath() EL.
AEM proporciona una API XSS para limpiar fácilmente los parámetros y garantizar la seguridad de los ataques de secuencias de comandos entre sitios. Además, HTL tiene estas protecciones integradas directamente en el lenguaje de plantilla. Se puede descargar una hoja de trucos de API en Desarrollo: directrices y prácticas recomendadas.
Para el código Java, AEM admite slf4j como la API estándar para el registro de mensajes y debe usarse junto con las configuraciones disponibles a través de la consola OSGi para lograr coherencia en la administración. Slf4j expone cinco niveles de registro diferentes. Se recomienda utilizar las siguientes directrices al elegir el nivel en el que se registra un mensaje:
En el caso de JavaScript, console.log sólo debe usarse durante el desarrollo y todas las sentencias de registro deben eliminarse antes de la versión.
Evite copiar código sin comprender qué hace. En caso de duda, siempre es mejor preguntar a alguien que tenga más experiencia con el módulo o la API sobre la que no esté seguro.