Con el número cada vez mayor de bibliotecas javascript utilizadas en las interfaces web, es rápidamente necesario realizar un registro de los scripts utilizados, de sus números de versión y de las dependencias entre ellos en el ecosistema de herramientas internas y de sitios externos desarrollados, ya sea en empresas o para proyectos personales.
El enfoque que sugiero para hacerlo está compuesto por un documento de síntesis y un proceso de vigilancia activa.
El documento de síntesis debe contener toda la información siguiente:
Y eso para cada proyecto/herramienta/sitio, así que por lo tanto se presenta en una tabla, con cada uno de ellos un indicador gráfico mostrando el estado de la versión utilizada (al día o no), y su número de versión.
Idealmente, el documento de síntesis también debería explicitar donde se encuentran las llamadas a la bibliotecas para cada proyecto y/o permitir un enlace directo a los correspondientes ficheros en el sistema de gestión de versiones (SVN, Git…).
El proceso de vigilancia activa consiste en comprobar regularmente cual es la última versión utilizable en la producción (no hay necesidad de seguir los Release Candidates), y es aquí que los lectores RSS y otras herramientas de automatización resultan útiles. Algunos proyectos se actualizan con más frecuencia que otros, jQuery por ejemplo entrega una release menor casi todos los meses.
Las dependencias en cascada entre los scripts son un fenómeno al que tener en cuenta, como el aumento de versión se hace también en cascada.
Si se utiliza por ejemplo la pareja jQuery/jQueryUI, la última versión del segundo puede no ser compatible con la última versión del primero por pocas semanas. No hay necesidad de estar siempre a la vanguardia de manera aislada, es toda la cadena de dependencias que debe estar globalmente al día.
El problema se complica cuando se desarrolla sus propios scripts en sobrecapa de una biblioteca. ¿Serán compatibles con la última versión de ésta?
Por lo general, las bibliotecas siguen el principio de compatibilidad con versiones anteriores, lo que significa que el código escrito para las versiones anteriores son todavía funcionales con las nuevas (el ejemplo anterior con jQuery/jQueryUI es, por lo tanto hipotético), algunas veces con cualquiera pérdida de rendimiento. Vale la pena destacar bajo cual versión de su capa inferior un script ha sido desarrollado para saber cuándo hacer una revisión del código.
Para estar seguro de esta compatibilidad, utilizar herramientas de pruebas automatizadas de interfaz queda todavía la mejor manera de validación (por ejemplo Selenium).
El enfoque que sugiero para hacerlo está compuesto por un documento de síntesis y un proceso de vigilancia activa.
El documento de síntesis debe contener toda la información siguiente:
- lista de las bibliotecas usadas
- último número de versión y fecha de publicación
- dependencias con otros scripts de terceros (con sus números de versión)
- URL del sitio donde descargar la última versión
- dónde encontrar información sobre la última versión (página de descarga, change log, blog, fuente RSS…)
Y eso para cada proyecto/herramienta/sitio, así que por lo tanto se presenta en una tabla, con cada uno de ellos un indicador gráfico mostrando el estado de la versión utilizada (al día o no), y su número de versión.
Idealmente, el documento de síntesis también debería explicitar donde se encuentran las llamadas a la bibliotecas para cada proyecto y/o permitir un enlace directo a los correspondientes ficheros en el sistema de gestión de versiones (SVN, Git…).
El proceso de vigilancia activa consiste en comprobar regularmente cual es la última versión utilizable en la producción (no hay necesidad de seguir los Release Candidates), y es aquí que los lectores RSS y otras herramientas de automatización resultan útiles. Algunos proyectos se actualizan con más frecuencia que otros, jQuery por ejemplo entrega una release menor casi todos los meses.
Las dependencias en cascada entre los scripts son un fenómeno al que tener en cuenta, como el aumento de versión se hace también en cascada.
Si se utiliza por ejemplo la pareja jQuery/jQueryUI, la última versión del segundo puede no ser compatible con la última versión del primero por pocas semanas. No hay necesidad de estar siempre a la vanguardia de manera aislada, es toda la cadena de dependencias que debe estar globalmente al día.
El problema se complica cuando se desarrolla sus propios scripts en sobrecapa de una biblioteca. ¿Serán compatibles con la última versión de ésta?
Por lo general, las bibliotecas siguen el principio de compatibilidad con versiones anteriores, lo que significa que el código escrito para las versiones anteriores son todavía funcionales con las nuevas (el ejemplo anterior con jQuery/jQueryUI es, por lo tanto hipotético), algunas veces con cualquiera pérdida de rendimiento. Vale la pena destacar bajo cual versión de su capa inferior un script ha sido desarrollado para saber cuándo hacer una revisión del código.
Para estar seguro de esta compatibilidad, utilizar herramientas de pruebas automatizadas de interfaz queda todavía la mejor manera de validación (por ejemplo Selenium).
Suivi des bibliothèques Javascript (en francés)
Follow-up of javascript libraries (en inglés)
O seguimento das bibliotecas javascript (en portugués)
No hay comentarios:
Publicar un comentario