¿Cómo manejas el cambio en los marcos de código abierto que usas para tus proyectos?

Puede ser una peculiaridad personal mía, pero me gusta mantener actualizado el código de los proyectos vivos, incluidas las bibliotecas / marcos que utilizan. Parte de esto es que creo que una aplicación web es más segura si está completamente parcheada y actualizada. Parte de esto es solo un toque de compulsividad obsesiva de mi parte.

En los últimos siete meses, hemos realizado una reescritura importante de nuestro software. Dejamos caer el framework Xaraya, que era lento y esencialmente muerto como producto, y lo convertimos a Cake PHP. (Elegimos Cake porque nos dio la oportunidad de hacer una reescritura muy rápida de nuestro software y un aumento de rendimiento suficiente sobre Xaraya para que valga la pena).

Implementamos pruebas unitarias con SimpleTest, y seguimos todas las convenciones de nombres de archivos y bases de datos, etc.

Cake ahora se está actualizando a 2.0. Y, no parece haber una ruta de migración viable para una actualización. Las convenciones de nomenclatura para archivos han cambiado radicalmente, y dejaron SimpleTest a favor de PHPUnit.

Esto nos obligará a permanecer en la rama 1.3 porque, a menos que haya algún tipo de herramienta de conversión, no será posible actualizar Cake y luego mejorar gradualmente nuestro código heredado para obtener los beneficios del nuevo marco de Cake . Entonces, como de costumbre, terminaremos con un marco antiguo en nuestro repositorio de Subversion y simplemente lo repararemos a nosotros mismos según sea necesario.

Y esto es lo que me atrapa cada vez. Muchos productos de código abierto no facilitan la tarea de mantener actualizados los proyectos basados ​​en ellos. Cuando los desarrolladores comiencen a jugar con un nuevo juguete brillante, se realizarán algunos parches críticos en las ramas más antiguas, pero la mayor parte de su atención se centrará en la nueva base de código.

¿Cómo manejas los cambios radicales en los proyectos de código abierto que usas? Y, si está desarrollando un producto de código abierto, ¿tiene en cuenta las rutas de actualización cuando desarrolla nuevas versiones?

El problema no es exclusivo del código abierto. Los mismos problemas ocurren con los proyectos comerciales. Tal vez aún más porque no tiene una fuente que pueda mantener si la compañía deja de brindar soporte.

Los proyectos de código abierto de tipo de usuario final tienen ciclos de actualización rápidos y las versiones antiguas pierden soporte muy rápidamente. Por otro lado, los proyectos que están diseñados para que los usuarios pongan un esfuerzo significativo en la codificación además de tener largos ciclos de soporte de la rama anterior después de una actualización importante. El tiempo suficiente para que se tome su tiempo primero esperando que se estabilice y madure, luego migre y pruebe a fondo su propio código.

Puede ser difícil resistir la tentación de tener lo último y lo mejor, pero tenga en cuenta que existe una compensación fundamental en el software entre la estabilidad y las nuevas características. No puedes tener uno sin sacrificar el otro. Es por eso que existen ramas de corrección de errores, para que pueda elegir qué lado del espectro se adapta mejor a sus necesidades.

Hemos solucionado este problema modularizando nuestro código.

Nuestro sitio web principal se construyó hace unos ocho años, y tuvimos la suerte de que uno de los primeros contribuyentes al Spring Framework lo construyera, por lo que fue una base bastante bien construida. Pero desafortunadamente también tuvimos la mala suerte de que este desarrollador decidió bifurcar a Spring después de una discusión sobre la dirección en la que se dirigía, por lo que esta base de código ahora está atrapada en una bifurcación no mantenida de Spring 1.1.4 (o algo de esa época).

Intentamos reescribir el código para pasar a nuevas versiones de Spring, pero eso resultó extremadamente difícil. Entonces, nuestra solución fue comenzar a construir nuevas características del sitio como módulos en una aplicación completamente separada, utilizando los marcos más recientes como Spring 3.x, Hibernate 3.6, etc.

Ahora tenemos dos aplicaciones web que se ejecutan en la misma URL base, y utilizamos el módulo mod_proxy de Apache para asignar cada ruta a la aplicación adecuada. Por ejemplo, "/ members" va a la aplicación anterior y "/ directorios" va a la nueva aplicación. Sin embargo, un visitante del sitio no tendría idea de que está utilizando diferentes aplicaciones; se ven exactamente iguales para el usuario.

Las dos aplicaciones deben comunicarse, por ejemplo, cuando un miembro inicia sesión en el sitio (usando nuestra nueva aplicación), debemos notificar a la aplicación anterior que ahora están conectadas. Lo hacemos utilizando un servicio web simple, expuesto solo a localhost La cantidad de integración necesaria entre las dos aplicaciones resultó ser mínima.

Una parte importante de este trabajo fue identificar y agrupar los activos compartidos. Por lo tanto, todo el texto estático, los gráficos, las hojas de estilo, el Javascript y las plantillas se trasladaron de la aplicación original a un tercer proyecto separado que utilizan las aplicaciones nuevas y antiguas. Esto garantiza que ambas aplicaciones web se vean y actúen de la misma manera, aunque estén completamente separadas.

Me imagino que con el tiempo reemplazaremos más y más de la aplicación original hasta que finalmente sea completamente innecesaria. Lo bueno de esta técnica es que podemos hacerlo lentamente a través de una serie de pequeños cambios de bajo riesgo: no hay necesidad de un cambio repentino masivo y arriesgado a un nuevo sistema.

No siempre lo hago Muchos proyectos de código abierto tienen sucursales de mantenimiento activo mantenidas para lanzamientos importantes anteriores. A veces, aquellos son mantenidos por personas que necesitan que se mantenga esa versión. Muchos proyectos permanecen en una versión principal hasta que están listos para una versión principal.

Y esto es lo que me atrapa cada vez.

Cada vez? Debes estar haciendo elecciones notablemente malas. Debe haber un ejemplo donde no sucedió.

Cuando los desarrolladores comienzan a jugar con un nuevo juguete brillante

Eso es una pista. Evite los juguetes nuevos y brillantes al usar proyectos de código abierto. Evite la versión 1.0.

¿Cómo manejas los cambios radicales en los proyectos de código abierto que usas?

Paso 1. Elija proyectos de código abierto con mucho, mucho cuidado. Siempre compare dos o más proyectos competidores.

Paso 2. Al comparar dos proyectos en competencia, intente comprender la característica "esencial" que se ofrece y cómo ambos la abordan. Evite "casarse" con una API específica demasiado pronto.

Paso 3. Adopte los principios de diseño de "Unión tardía" y "Acoplamiento flojo". Intente aislar de los cambios de proyecto de código abierto.

Paso 4. Haga explícitamente comparaciones de costo / beneficio entre proyectos de código abierto y "rodando el suyo". De vez en cuando, crear su propia solución puede ser mejor que hacer frente a una solución de código abierto.

Cambiar los nombres de los archivos no debería ser demasiado difícil. Sí, es un guión grande y feo. Sí, debe ejecutarse durante varias semanas mientras se realiza la conversión. Pero es un costo finito.

Si sucede cada vez, desarrolle mejores estrategias de afrontamiento. Dado que su observación del mundo real es que siempre va a suceder, esperar que el mundo real cambie realmente no va a ayudar mucho. Tienes alguna experiencia duramente ganada en el cambio. Aprovecha eso. Considéralo como una infección y desarrolla tu propia respuesta inmune.