¿Cuándo, cómo y por qué se deben actualizar los marcos (Java)?


8

Breve resumen como introducción:

Somos un pequeño equipo de desarrollo web de Java, que crea aplicaciones utilizando diversos marcos y bibliotecas como JSF, Hibernate, Seam, todos juntos implementados en JBoss AS.

Inicialmente, la aplicación se creó y se agregaron algunas características para formar un escaparate para mostrar a los clientes potenciales. Se realizó un pulido, se lanzó la aplicación, se aceptó y funcionó y, con el paso del tiempo, se agregaron características adicionales, se solucionaron errores, se produjeron nuevos errores, como siempre sucede.

Debido a los altos factores del bus y las carreras de inicio, el desarrollo se salió de control: se agregaron más y más características, sin haber entendido completamente la arquitectura central del sistema. Todavía funciona, pero siempre hay dificultades porque el sistema evolucionó de donde se originó a otra cosa y al principio, se tomaron varios atajos para acelerar el desarrollo; ahora todo esto regresa y el desarrollo se ralentiza, porque se usan soluciones alternativas y es Es bastante difícil introducir nuevos desarrolladores en el proyecto.

Ahora, estoy en el proceso de limpiar y organizar cosas: instalar un sistema de seguimiento de errores, desarrollar una cultura de prueba / calidad, pensar en cómo hacer pruebas automatizadas, revisiones de código (todas esas cosas profesionales sofisticadas que nos faltaban en el principio) y haciendo refactorización general como organizar jerarquías de clase y funciones para que sea más fácil usar cosas. Eso hace que todo sea un poco mejor, pero aún queda mucho por hacer. Como no soy la persona que inicialmente creó el sistema (el ex programador principal se fue) y no tengo tanta experiencia (desarrollo durante 2.5 años ahora, pero esa es mi única experiencia de 'mundo abierto' hasta ahora), no siempre estoy seguro de qué hacer. hacer.

Aquí está mi problema:

Refactorizar siempre es algo bueno y lo hago constantemente para facilitar las cosas, pero lo que me intriga es cuándo, cómo y por qué debo actualizar la arquitectura básica (es decir, bibliotecas en las que se basa el sistema, servidor de aplicaciones, base de datos, etc.)

Ejemplos:

  • Actualmente estamos usando JBoss 4.2.2. Ya leí en algún lugar de JBoss 7.1, ¿debería ir por eso? ¿Cómo se puede evaluar esto?

  • Usamos Seam 2.2 lo que parece ser un gran bloqueador (no funciona en versiones superiores de JBoss, no es compatible con JSF2). Además, veo fuentes que me dicen que use funciones JEE en lugar de Seam.

Básicamente, estoy interesado en cualquier enfoque genérico para estos problemas, no solo los que mencioné en los ejemplos anteriores, ya que puedo tropezar con estos problemas para otra biblioteca en otro sistema en otro momento (o alguien más puede enfrentar problemas similares) .

¿Entonces cuál es el punto? ¿Debo estar al día y usar solo bibliotecas de vanguardia o debo quedarme con lo que tengo? ¿Cómo reconozco que la tecnología que estoy usando es literalmente un caballo muerto y saltar? ¿Con qué frecuencia deberían aparecer tales actualizaciones tecnológicas?

Y, otra pregunta al lado de las cosas generales 'cómo hacer actualizaciones'. ¿Cómo reconozco que mi software podría llamarse uno 'creado por profesionales'? ¿Existe una prueba de Joel para el software bien hecho además del sentido común de los programadores?


1
La única respuesta real a esto es 'depende'. Depende exactamente de cuál sea su producto, si las versiones más nuevas de marcos o bibliotecas que está utilizando brindan importantes ventajas de rendimiento, mantenimiento o seguridad, cuán difícil (bien, consume mucho tiempo) y bien equipado está para hacer los cambios necesarios para haga que su software funcione con los marcos y bibliotecas más nuevos, etc.
Anónimo

No están en quiebra, no lo arregles.
Nikolay Fominyh

2
@NikolayFominyh Aunque el cambio por el cambio es malo, ese tipo de actitud a menudo conduce a un software mal mantenido y mal entendido que se rompe de la manera más inconveniente posible. Como señala Martijn, eventualmente el proveedor deja de ofrecer soporte o necesita una corrección de error / seguridad. Cuanto más pospongas las actualizaciones, más difícil será.
R0MANARMY

"Nunca tocar un sistema en ejecución" suena simple, pero en mi opinión, dependiendo del ciclo de vida del sistema, no siempre es una razón. Si ya está en modo de mantenimiento, no pasaría demasiado tiempo actualizando. Pero el sistema todavía está evolucionando y se agregan nuevas características, por lo que mantenerse actualizado será definitivamente necesario.
Volker

Respuestas:


5

La respuesta corta es que cambia cuando el esfuerzo por no cambiar excede el esfuerzo de cambio, o cuando puede prever que pronto se hará así. Esa es una evaluación muy subjetiva que requiere experiencia, pero es relativamente fácil ver los casos extremos.

Por ejemplo, supongamos que estima un mes para cambiar, pero no cambiar significa que no puede usar un módulo que solo está disponible en la versión actualizada, por lo que tendrá que tomar dos meses para implementar uno desde cero. La elección es fácil.

Para otro ejemplo, si pasa todo su tiempo reparando vulnerabilidades de seguridad en un software que ya no es compatible con el proveedor, es un buen momento para cambiar.

Si nunca tiene reuniones donde alguien diga: "Esto sería mucho mejor / más fácil con la nueva versión", entonces probablemente no necesite cambiar.

Los casos intermedios son más difíciles de reconocer, pero generalmente se siente como aumentar la presión, donde seguir con la versión anterior se siente cada vez más limitante.

En cuanto a su prueba de software bien hecha, su rastreador de errores proporciona una buena regla general al respecto. Cuando tiene cero defectos críticos y su lista de defectos no críticos se encuentra en un nivel razonable y se está reduciendo constantemente, puede llamarlo 'hecho'. Puede tener una idea de la calidad de su arquitectura de software por el tiempo de respuesta para agregar nuevas funciones o corregir errores. No hay un punto de corte que diga "esto es profesional", pero cuanto más bajo, mejor.


Gracias por su consejo. La medición de los costos de la actualización frente a la estadía es un buen soporte de decisión y, al observar lo que tenemos hasta ahora, la actualización parece ser realmente necesaria. Aceptaré su respuesta, porque proporcionó varias otras ideas sobre el proceso general de desarrollo / actualización.
Volker

En un momento me pidieron que mantuviera una vieja aplicación de Visual Basic. Lo primero que sucedió cuando inserté el CD de Visual Basic en la computadora fue que Windows apareció una pantalla de advertencia de que se trataba de SOFTWARE NO SOPORTADO (o algo similar). Tomé eso como una pista de que era hora de cambiar.
Thorbjørn Ravn Andersen

9

Hay una serie de razones por las que es posible que desee actualizar su infraestructura subyacente, y debe evaluar cada una de ellas tan empíricamente como sea posible. Por ejemplo, puede actualizar porque:

  1. El proveedor ya no es compatible con la versión que está utilizando.
  2. Hay un error crítico o corrección de seguridad
  3. Hay una nueva característica que desea aprovechar
  4. Aumentará tu velocidad
  5. Hay una reducción directa del costo de gasto de capital en la actualización (licencia de soporte más barata o similar)

Estas razones deben sopesarse contra el costo de la actualización, la mayor parte del cual se gasta en pruebas. Aquí es donde TDD / BDD realmente se destaca , especialmente cuando se combina con una buena configuración de CI.

Significa que puedes "Refactorizar rápidamente sin miedo"

Si no tiene un conjunto de pruebas exhaustivo decente, significa que está realizando pruebas manualmente, lo que lleva mucho tiempo y es muy propenso a errores, lo que aumenta el costo de la actualización.


Gracias por su consejo. Establecer un entorno de prueba sólido y de cobertura parece ser el camino a seguir: BDD suena bastante interesante y definitivamente lo echaré un vistazo.
Volker

3

Las tecnologías que ha enumerado son ampliamente utilizadas, es fácil encontrar documentación para ellas y las personas que las dominan, por lo que creo que no hay una razón real para cambiarlas. Por otro lado, recomendaría actualizar sus marcos a las últimas versiones lanzadas. Creo que tendrá que hacerlo de todos modos, tarde o temprano (si no es por las nuevas características y la compatibilidad con las bibliotecas más nuevas, luego por los errores corregidos en las nuevas versiones), y cuanto antes lo haga, menos tediosa será esta tarea.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.