official descargar code javascript jquery upgrade sdlc

javascript - descargar - jquery migrate min js



¿Un enfoque práctico para mantener jQuery al día? (6)

Algunos de los proyectos en los que estamos trabajando tienen fuertes raíces en jQuery 1.4.2 o anteriores, y en algún lugar entre la falta de rendimiento (o el azúcar sintáctica) de los últimos lanzamientos, la humillación de usar métodos ahora en desuso y la incomodidad de implementando una versión de más de 3 años de una biblioteca mantenida activamente, una actualización ahora es inminente.

¿Cuáles son algunas de las prácticas populares en la comunidad que podríamos adoptar / volver a visitar para asegurar una implementación sin problemas (es decir, concentrarnos en los problemas de compatibilidad oscura, recoger regresiones globales, volver a factorizar algunos de los códigos más antiguos ...)? ¿Cómo se integrarán mejor en SDLC para futuras actualizaciones? ¿Cuál es un programa de actualización razonable para una biblioteca como jQuery (no anticipo ganancias significativas ni costos justificables para hacerlo con cada publicación puntual, pero una vez cada 6-12 meses puede ser razonable)?

En esta era, no podemos ser predecibles sobre la estabilidad de las versiones de software. Pocos años antes de las versiones de software y servicios lanzadas después de un año o dos años. Pero en este momento las versiones de los servicios se están actualizando de manera rápida y frecuente.

Entonces, si está utilizando algún servicio con su servicio, tiene que usar Desarrollo Agile . Con este método de desarrollo, puede realizar fácilmente cambios en los nuevos requisitos y cambiar los métodos requeridos según usted.

Y, por favor, no utilice métodos depreciados porque no son adecuados para versiones de servicio de larga duración. Y haga que las bibliotecas de los servicios de biblioteca utilizados de su propio servicio funcionen utilizando otros servicios para que pueda cambiarlos fácilmente de acuerdo con su nueva versión.

Por ejemplo : como si tuviera un nombre de método update_var(); está llamando a otro método de otro servicio como $a = newlib::check_update(); . Luego, al crear bibliotecas, debe cambiar la biblioteca principal de la función de usted y la biblioteca central del servicio involucrado.

Los chicos de Twitter han resuelto este problema bastante bien.

NPM

Hace lo que dice: es un administrador de paquetes para la web (y eso incluye mantener actualizados los archivos JS como JQuery)

Para mantenerse actualizado en su árbol de desarrollo, recomiendo usar src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (la versión completa que no está minada y que permite depuración más fácil)

Luego, cuando vaya a publicar, simplemente reemplácelo con la versión minificada específica que se encuentra en el comentario del encabezado (actualmente http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js ) Esto tiene la ventaja de permitir un mejor almacenamiento en caché del lado del cliente y usar el ancho de banda de otra persona.

Si el almacenamiento en caché es menos preocupante que asegurarse de que obtendrá automáticamente correcciones de errores para esa versión secundaria, puede usar solo la versión principal y secundaria, como: http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (Nota: Google aún no tiene la serie 1.9; sin embargo, la serie 1.8 es de hasta 1.8.3) Dado que estos se actualizan periódicamente para las versiones de corrección de errores, no se almacenan en caché como la versión específica. lanzamientos

Para responder realmente a sus tres preguntas, aquí hay algunas cosas que he hecho o al menos recomendar:

Mejores prácticas para una actualización sin problemas

  • Tener pruebas Estas pueden ser pruebas unitarias para sus pruebas de JS y / o navegador. Estos deben cubrir al menos la funcionalidad más típica y más compleja utilizada en sus proyectos. Si no tienes exámenes, escríbelos. Si no quieres escribir pruebas, reconsidera. Si realmente no desea escribir pruebas, al menos tenga una lista de casos de uso que alguien pueda ejecutar manualmente.
  • Asegúrese de que todas sus pruebas pasen antes de la actualización.
  • Lea las notas de la versión de cada versión (principal) entre la versión que usa ahora y la versión más reciente. Vea también las categorías Removed y En Deprecated en los documentos de la API. Si alguno de sus códigos utiliza la interfaz de usuario jQuery, consulte también las notas de la versión y las guías de actualización para las versiones intersticiales. Al hacer esto, tome nota de las cosas que probablemente tendría que cambiar en su base de código (posiblemente haciendo un uso intensivo de grep ).
  • Si la versión actual de jQuery de su proyecto es> = 1.6.4, también considere usar el complemento jQuery Migrate para evaluar el trabajo requerido.
  • Decida qué versión desea que sea su objetivo de actualización, según el trabajo requerido para llegar allí, si su proyecto está utilizando bibliotecas de terceros que requieren una versión determinada de jQuery, otros factores que solo puede considerar, etc.
  • Reúnase con su equipo para revisar la lista de cambios que se realizarán en su base de código y divida / asigne el trabajo en consecuencia. Tal vez escriba algunos scripts u otras herramientas para ayudar. Si tiene uno, es posible que también deba actualizar la guía de estilo de codificación de su equipo / documento de mejores prácticas. Decidir sobre versiones de actualización instantáneas (recomendadas) o continuas, si eso es posible + deseable. Proponga una estrategia de lanzamiento adecuada. (Recomiendo que no se lance la actualización como parte de otro cambio grande no relacionado a su base de código, por lo que es fácil revertirlo si lo necesita).
  • A lo largo del proceso de actualización, ejecute continuamente sus pruebas. Al realizar pruebas manualmente, siempre supervise la consola del navegador para detectar nuevos errores. Escribe nuevas pruebas que cubran errores inesperados.
  • Cuando se superen todas las pruebas, decida cómo desea implementar: si se trata de un sitio, todos los usuarios a la vez o un porcentaje a la vez, etc. Para una biblioteca u otro proyecto, tal vez liberaría una versión beta / de vanguardia. Versión que puede dejar que sus usuarios más ambiciosos prueben para usted en la naturaleza.
  • Documente todo lo que acaba de hacer para que sea más fácil para la próxima vez.
  • [Lucro.]

Cómo integrar actualizaciones en el flujo de trabajo normal

  • Una vez más, las pruebas. Asegúrate de tenerlos. Asegúrese de que estén bien, mantenidos y que cubran una gran parte de su código base y casos de uso. Se recomienda una configuración de integración continua para automatizar la ejecución de estas pruebas.
  • Considere hacer que su equipo cree y acepte seguir una guía o estándar de estilo de codificación. Esto hará que en el futuro sea más fácil buscar llamadas o construcciones de funciones en desuso, ya que todos seguirían patrones de codificación similares. Las herramientas como scripts, enlaces de confirmación, utils de análisis estático, etc., para imponer un buen estilo de codificación pueden ser útiles (dependiendo del equipo).
  • Investigue y tal vez decida usar un administrador de paquetes como NPM o NPM para administrar las versiones de jQuery y otras bibliotecas de terceros que pueda usar que dependan de él. (Aún deberá mantener su propio código JS y pasar por el mismo proceso que el anterior).
  • Una vez más, una vez que haya pasado la versión 1.6.4, asegúrese de que el complemento de Migrate sea parte de su flujo de trabajo de actualización.
  • Evalúe qué funcionó desde el proceso de actualización grande inicial, qué no funcionó y extraiga un proceso general de este que funcione mejor con su flujo de trabajo actual. Independientemente de si planea actualizar cada vez que hay una nueva versión, habrá tareas y hábitos de mantenimiento continuos que probablemente querrá mantener como mejores prácticas de desarrollo general.

Programa de actualización razonable

Eso es esencialmente una pregunta de gestión de riesgo / CBA. Tendrás que pesar algunas cosas:

  • No debe haber cambios en la API de última hora dentro de la misma versión principal, por lo que generalmente debería poder actualizar a la versión menor más reciente con un esfuerzo mínimo, sin necesidad de refactorización. Esto supone que tiene y mantiene buenas pruebas, que puede ejecutar en sus proyectos antes de decidir que todo está bien para una implementación.
  • Las actualizaciones principales de la versión requieren más investigación, más refactorización y más pruebas. Después del paso de investigación, debe hacer un análisis de costo-beneficio de la actualización.
  • Puede que esto no importe mucho, pero si alguno de sus proyectos es un sitio web que tiene muchos usuarios, ¿cuál sería el costo de hacer que todos los usuarios tengan que descargar esencialmente todos los archivos JS modificados en su sitio la próxima vez que lo visiten? (En lugar de seguir con las versiones anteriores que probablemente todavía se almacenan en caché en sus navegadores)?
  • La decisión de actualizar siempre debe ser subjetiva. Menor o mayor, aún tendrá que justificar cada vez si una actualización valdrá la pena. Siempre lea las notas de lanzamiento. ¿Corrige una vulnerabilidad de seguridad o un error relacionado con problemas que usted o sus usuarios están experimentando actualmente? ¿Mejoraría significativamente el rendimiento de su proyecto (asegúrese de tener puntos de referencia para verificarlo más adelante)? ¿Simplifica enormemente el patrón de codificación que ha estado usando, permitiendo que su código se escriba de forma más limpia y fácil? ¿Hay alguna biblioteca de terceros que desee utilizar que dependa de esta versión más reciente? ¿Hay bibliotecas de terceros que ya utiliza que dependen de la versión anterior ? (Si es así, ¿es probable que estas bibliotecas se actualicen pronto para funcionar con la versión más reciente?) ¿Confía tanto en sus pruebas y en el proceso de control de calidad de que una actualización requerirá una cantidad razonable de recursos de desarrollo y no causará grandes regresiones? ¿Estabas pensando en eventualmente cambiar a jQuery con algo más? Etc.

Por supuesto, este es sólo mi consejo. Hay algunos temas recurrentes en él, y espero que sean claros. En cualquier caso, espero que alguien encuentre esto útil!

Siempre estarás desactualizado. Una vez que haya terminado de actualizar a la última versión, una nueva versión saldrá unos meses más tarde.

A menos que esté dispuesto a dedicar horas / días / semanas de desarrollo, prueba y corrección de errores, con la posibilidad de romper la funcionalidad orientada al usuario, no debería actualizarse solo para utilizar la forma más nueva de declarar controladores de eventos. No te hará daño. Y normalmente esto es algo arriesgado. Esto se traduce en costos de equipo de desarrollo. Ya lo sabes. La refactorización, especialmente cuando no existe un riesgo evidente para el proyecto, en general es difícil de justificar para los gerentes. Y debe revisar dos veces sus pensamientos para asegurarse de que tener la nueva jQuery en el código que ya está funcionando hará alguna diferencia.

Ahora, si está trabajando en la creación de nuevas páginas en un sitio existente, podría incluir una nueva versión en esas áreas. Pero, esto tendrá una consecuencia: supongamos que usted y su equipo, además de desarrollar la nueva parte del sitio, también deben mantener la parte que está utilizando la anterior. Todos deberán conocer la versión específica de jQuery contra la que escriben su código.

Entonces, para cerrar, diría algo como esto. A menos que exista un riesgo justificable de que el proyecto se retrase o se bloquee técnicamente debido a una versión anterior de jQuery, se estará metiendo en problemas por romper algo que ya está funcionando y tendrá que poner horas adicionales para hacer todo lo posible. Trabaja tan bien como antes.

De todos modos, este enfoque no significa que pueda comenzar a separar las ''nuevas secciones'' de las antiguas, y al usar las bibliotecas más nuevas en las nuevas áreas.