¿Cuál es la mejor manera de migrar una aplicación web desordenada existente a MVC elegante?

Question

Me uní a una nueva compañía hace aproximadamente un mes. La compañía es bastante pequeña y tiene una sensación de "arranque" bastante fuerte. Estoy trabajando como desarrollador de Java en un equipo de 3 personas más. La compañía vende principalmente un servicio para que las personas de negocios o negocios lo usen para comunicarse entre ellos.

Una de las cosas principales que he estado trabajando en, es el sitio web principal de la empresa: desde que se vende el servicio, los usuarios existentes inician sesión para verificar su servicio y pagar sus facturas, los nuevos usuarios pueden firmar para una prueba, etc. Actualmente se trata de una aplicación JSP implementada en Tomcat, con acceso a una base de datos a través de una capa de persistencia escrita por la propia empresa.

Una frustración repetida y cada vez mayor que estoy teniendo aquí (y estoy bastante contento con el trabajo en general, por lo que este no es un "oh no, no me gusta mi trabajo" tipo de publicación) es la falta de cualquier diseño o arquitectura más grande para esta aplicación web. La aplicación se compone de varias docenas de páginas JSP, con casi ninguna lógica existente en Servlets o Beans o cualquier otro tipo de marco. Muchas de las páginas JSP son miles de líneas de código, jsp:include otras páginas JSP, la lógica empresarial está mezclada con HTML, los fragmentos de código utilizados con frecuencia (como la obtención de una conexión de servicio web) se cortan y pegan en lugar de reutilizarse, etc. En otras palabras, la aplicación es un desastre.

Hubo algunos rumores dentro de la compañía de tratar de rediseñar este sitio para que se ajuste mejor a MVC; Creo que los desarrolladores y los superiores están empezando a darse cuenta de que este patrón actual de código de spaghetti no es sostenible o muy fácilmente escalable para agregar más características para los usuarios. Los superiores y los desarrolladores son reacios a reescribir por completo el tema (con buenas razones, ya que esto implicaría varias semanas o meses de trabajo para volver a escribir la funcionalidad existente), pero hemos tenido algunas discusiones sobre (lentamente) escribir ciertas áreas del sitio en un nuevo marco.

¿Cuáles son algunas de las mejores estrategias para permitir mover la aplicación y la base de código en esta dirección? ¿Cómo puedo realmente, como desarrollador, ayudar a avanzar en esto, y rápidamente, sin parecer el tipo nuevo que entra en un trabajo y les dice a todos que lo que han escrito es basura? ¿Hay alguna estrategia o experiencia probada que hayas utilizado en tu propia experiencia laboral cuando te encuentras con este tipo de cosas?

Answer 1

Su mejor opción es probablemente refactorizarla lentamente a medida que avanza. Pocos de nosotros tenemos los recursos que se necesitarían para comenzar completamente desde cero con algo que tiene tantas reglas comerciales enterradas en él. La administración realmente lo odia cuando pasas meses desarrollando una aplicación que tiene más errores que la que reemplazaste.

Si tiene la oportunidad de crear cualquier aplicación separada desde cero, use todas las mejores prácticas allí y úselas para demostrar su eficacia. Cuando pueda, incorpore esas ideas gradualmente en la aplicación anterior.

Answer 2

En mi experiencia, la "elegancia" de una aplicación generalmente tiene más que ver con el diseño de la base de datos que cualquier otra cosa. Si tiene un gran diseño de base de datos , que incluye una interfaz de procedimiento almacenado bien definida, el buen código de la aplicación tiende a seguir independientemente de la plataforma que utilice. Si tiene diseño de base de datos pobre, no importa qué plataforma utilice, le resultará muy difícil crear un código de aplicación elegante, ya que estará compensando constantemente la base de datos.

Por supuesto, hay mucho espacio entre gran y pobres, pero mi punto es que si quieres un buen código de la aplicación, se inicia asegurándose de que su base de datos es hasta el tabaco.

Answer 3

Esto es más difícil de hacer en aplicaciones que están solo en modo de mantenimiento porque es difícil convencer a la administración de que es útil reescribir algo que ya está 'funcionando'. Comenzaría por aplicar los principios de MVC a cualquier código nuevo en el que pueda trabajar (es decir, mover la lógica comercial a algo parecido a un modelo, poner todo su código de diseño/vista en un solo lugar)

Como usted Obtenga experiencia con el nuevo código en MVC. Puede comenzar a ver oportunidades para cambiar el código existente sutilmente para que también coincida. Puede ser un proceso muy lento, pero si puede mostrar los beneficios de esta forma de hacerlo, podrá convencer a los demás y hacer que todo el equipo participe.

Answer 4

Estoy de acuerdo con el enfoque de refactorización lenta; por ejemplo, tome ese código de copiar y pegar y extráigalo en el paradigma de Java apropiado (¿una clase, quizás? o mejor aún, use una biblioteca existente?). Cuando su código es realmente limpio y escueto, pero aún le falta una estrategia arquitectónica general, y luego podrá hacer que las cosas se ajusten a una arquitectura general mucho más fácilmente.

Answer 5

La mejor manera es imprimir el código, arrugarlo y tirarlo. Ni siquiera recicles el papel.

Tiene una aplicación escrita en más de 1,000 JSP de línea. Es probable que tenga un modelo de dominio horrible (si es que tiene uno) y no solo presenta MIX con lógica empresarial, lo MEZCLA y se sienta allí y sigue moviéndose durante horas. No hay forma de sacar el código que es malo y pasar a una clase MVC Controller y seguir haciendo lo correcto, terminarás con una aplicación MVC con un modelo anémico de dominio o una que tenga cosas como llamadas a bases de datos. en el código del Controlador, todavía estás fallando.

Puede probar una nueva aplicación que haga lo correcto y luego hacer que las dos aplicaciones hablen entre sí, pero esa es una nueva complejidad en sí misma. También es probable que vayas a hacer la misma cantidad de trabajo que ibas a hacer si comenzaste desde el principio, pero tal vez te resulte más fácil tratar de convencer a tus jefes de que este es un mejor enfoque.

Answer 6

Primero, tome una copia de Michael Feather's Working Effectively with Legacy Code. Luego identifique la mejor manera de probar el código existente. El peor caso es que estás atascado solo con algunas pruebas de regresión de alto nivel (o nada) y si tienes suerte habrá pruebas unitarias. Entonces, es un caso de refactorización lenta y constante, con suerte, mientras se agrega nueva funcionalidad comercial al mismo tiempo.

Answer 7

Iterativamente refactor. También busque nuevas características que se puedan hacer completamente en el nuevo marco como una forma de mostrar el valor del nuevo marco.

Answer 8

Mi sugerencia sería encontrar las páginas raras que no requieren una importación de otros JSP, o tienen muy pocas importaciones. Trate a cada JSP importada como una caja negra, y reordene estas páginas a su alrededor (iterativamente, probando cada cambio y asegurándose de que funcione antes de continuar). Una vez que se hayan limpiado, puede continuar encontrando páginas con más y más importaciones, hasta que finalmente haya refactorizado las importaciones.

Al refacturar, tenga en cuenta las partes que intentan acceder a los recursos que no se proporcionan a la página y trate de llevar esto a un controlador. Por ejemplo, cualquier cosa que acceda a la base de datos debe estar dentro de un controlador, deje que el JSP maneje la visualización de la información que el controlador le proporciona a través de un reenvío. De esta forma, desarrollará varios servlets, o cosas como servlets, para cada página. Sugeriría utilizar un marco basado en controlador frontal para esta refactorización (de la experiencia personal recomiendo Spring y su interfaz de controlador), de modo que cada controlador no sea un servlet separado, sino que se delegue desde un único servlet que esté mapeado adecuadamente.

Para el controlador, es mejor hacer hits de base de datos a la vez en vez de intentarlos por partes. Los usuarios pueden y generalmente toleran una carga de página, pero la salida de la página será mucho más rápida si todos los datos de la base de datos se entregan al código de representación en lugar del código de representación colgando y no entregando datos al cliente mientras intenta leer otro pieza de datos de la base de datos.

Siento tu dolor y te deseo suerte en este empeño. Ahora, cuando tiene que mantener una aplicación que abusa de Spring Webflow, esa es otra historia :)