Recomendaciones para migrar una aplicación web heredada a un marco moderno

Question

Actualmente estoy trabajando para una empresa que ejecuta una aplicación web heredada basada en Java Servlets (el sistema es anterior a las JSP, aunque ahora las usa al compilar páginas nuevas)) La base del código es un gran revoltijo, ya que tiene alrededor de 10 años de construcción sobre un marco desactualizado. Tienen muy poca consistencia en la base de código (la aplicación ha sido desarrollada por varias personas a lo largo de los años, la mayoría de las cuales ya no funcionan aquí), ningún concepto de DRY (básicamente, cada página se crea desde cero) una gran cantidad de ilegible/críptico código y, en general, una infraestructura muy inconsistente.

Como he estado trabajando aquí, he estado agregando funciones modernas/tratando de limpiar un poco la base de códigos. Agregué un poco de jQuery a donde estaba expuesto, introduje un poco de seguridad con las validaciones de entrada, limpié algunos de los módulos para emplear principios de JavaScript discretos, etc. Mi trabajo aquí es en módulos nuevos, así que no estoy expuesto a muchos de los viejos lógica. He tratado de introducir las mejores prácticas para todo mi trabajo en su infraestructura actual, pero me veo obligado a llamar a gran parte de su código anterior para que mis cosas sean consistentes.

Han llegado a un punto en el que ahora están considerando una actualización masiva del sistema. Quieren mejorar la capacidad de mantenimiento de la base de código e intentar pasar a algún tipo de aplicación moderna de tipo marco/MVC. Gran parte del sistema es anterior a XHTML con marcado estilístico en línea, llamadas a javascript: función(), sin pruebas de unidades, anterior a Hibernate, etc. Hay una mezcla de out.println html generation y llamada jsp's dentro del Servlet.

Algunas aplicaciones que han estado buscando incluyen Wicket, Struts, Tapestry y posiblemente Grails. El problema es que el cambio a cualquiera de estos puede requerir una gran reescritura de un sistema que ya está en uso y no pueden volver a comenzar.

Mi pregunta es: ¿Cuál sería la mejor manera de migrar una base de código heredado como este a un marco más moderno manteniendo la lógica de negocios existente (no tiene sentido reescribir cosas que han sido probadas y funcionan).

Algunas de las ideas que se están pensado incluyen:

• escribir una en casa sistema de plantillas que trabajaría con su infraestructura actual (generar páginas de manera coherente)

• código de puerto a una marco como el tapiz (reutilizando gran parte de su código anterior)

• reescribe el sistema desde cero utilizando un marco moderno pero copiando la lógica del sistema antiguo (si es posible)

• mantener el sistema antiguo como es y simplemente actualizar las páginas de front-end para darle un aspecto más moderno (podría ser mejor dado tiempo/dinero, etc.)

cuál es la mejor manera de actualizar el legado Código Java Servlet a un marco moderno (utilizando prácticas modernas para un mantenimiento sencillo, pruebas unitarias, DRY) manteniendo la lógica intacta.

cualquier idea es bienvenida.

Answer 1

Refactorízate al máximo, trabajando hacia un estilo consistente de diseño, como paso preliminar para trasladarlo al marco más cercano en espíritu al estilo que sea.

Me refiero a "refactor": introducir pruebas en ubicaciones estratégicas, unidad y funcional, y trabajar como locos para reducir la duplicación, apoyándome en estas pruebas.

Answer 2

La mejor manera: utilice la aplicación existente como una especificación funcional y cree la nueva aplicación desde cero (con una posible reutilización de cortar y pegar o reutilización de clase real donde tenga sentido).

Desde mi experiencia, tratar de calzar una aplicación heredada mal escrita en un nuevo marco o tratar de "ajustar" el código basura con un buen código solo resulta en algo aún más difícil y costoso de mantener a largo plazo.

Answer 3

No hay una respuesta clara para este tipo de pregunta, pero mi sugerencia principal sería la primera leer sobre el tema. Lea libros de personas que saben de lo que están hablando.

Por ejemplo, código completo (Steve McConnell), cap. 24 Refactorización.

• Guardar el código que comienza con

• Mantenga refactorizaciones pequeñas

• Realice una refactorización en un momento

• Refactor cuando se agrega una rutina, clase, arreglar un defecto

• Definir una interfaz entre código limpio y feo

• ...

Hay muchos otros recursos, impresos y en línea, que se puede utilizar. Después, si tiene una pregunta más específica, puede usar sitios como SO para obtener una respuesta más útil que esta.

Answer 4

me hizo una pregunta muy similar hace unos meses, algunas de las respuestas podría ser útil para usted:

What is the best way to migrate an existing messy webapp to elegant MVC?

Answer 5

esto es sólo mi opinión, porque creo que esta pregunta es lo que la gente paga caro consultores para entrenar (¡y usualmente terminan desperdiciando dinero! ver thedailywtf.com para ver ejemplos).

Creo que no vale la pena una reescritura completa, porque durante el proceso de reescritura, es posible que también deba mantener la aplicación original *, y así la reescritura tendrá un objetivo en movimiento. la mejor manera es pagar la deuda del código a medida que se refactoriza, es decir, se necesitará 2x, 3x o incluso 10x el esfuerzo de implementar una característica simple, simplemente porque hacerlo de una manera agradable implica la refacturación de montones. pero este esfuerzo es necesario, ya que la deuda que se debe en esta aplicación es alta, y eventualmente tiene que pagarse de alguna manera.

que puede doler, pero una buena medicina duele.

• si se le da una buena cantidad de tiempo para hacer la reescritura, es decir, la aplicación original se congela y no se mantiene (ni siquiera correcciones de errores), entonces podría funcionar como una reescritura completa en cualquier marco que usted considere ajuste. pero dudo mucho que este sea el caso en cualquier institución.