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

Question

Me uní a una nueva empresa hace aproximadamente un mes.La empresa es de tamaño bastante pequeño y tiene un fuerte sentimiento de "start-up".Estoy trabajando como desarrollador de Java en un equipo de otras 3 personas.La empresa vende principalmente un servicio para que empresas o personas de tipo empresarial lo utilicen para comunicarse entre sí.

Una de las principales cosas en las que he estado trabajando y en lo que estaré trabajando es el sitio web principal de la empresa: desde donde se vende el servicio, los usuarios existentes inician sesión para verificar su servicio y pagar sus facturas, los nuevos usuarios pueden registrarse para una prueba. , etc.Actualmente se trata de una aplicación JSP desplegada sobre 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 creciente que estoy teniendo aquí (y estoy bastante contento con el trabajo en general, así que esta no es una publicación del tipo "oh, no, no me gusta mi trabajo") es la falta de un diseño o Arquitectura para esta aplicación web.La aplicación se compone de varias docenas de páginas JSP, casi sin lógica en Servlets o Beans o cualquier otro tipo de marco.Muchas de las páginas JSP tienen miles de líneas de código, jsp:include En otras páginas JSP, la lógica empresarial se mezcla con el HTML, los fragmentos de código utilizados con frecuencia (como la obtención de una conexión a un servicio web) se cortan y pegan en lugar de reutilizarse, etc.En otras palabras, la aplicación es un desastre.

Ha habido algunos rumores dentro de la empresa sobre el intento 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 espagueti no es sostenible ni fácilmente escalable para agregar más funciones para los usuarios.Los superiores y los desarrolladores desconfían de reescribir completamente el sistema (con razón, ya que esto significaría varias semanas o meses de trabajo reescribiendo la funcionalidad existente), pero hemos tenido algunas discusiones sobre (lentamente) reescribirlo. escribir ciertas áreas del sitio en un nuevo marco.

¿Cuáles son algunas de las mejores estrategias para permitir mover la aplicación y el código base en esta dirección?¿Cómo puedo yo, como desarrollador, realmente ayudar a que esto avance, y rápidamente, sin parecer el tipo nuevo idiota que llega a un trabajo y les dice a todos que lo que han escrito es una mierda?¿Existe alguna estrategia o experiencia comprobada que haya utilizado en su propia experiencia laboral cuando se haya encontrado con este tipo de cosas?

Answer 1

Probablemente lo mejor que puede hacer es refactorizarlo lentamente a medida que avanza.Pocos de nosotros tenemos los recursos necesarios para empezar completamente desde cero con algo que tiene tantas reglas de negocio enterradas.La gerencia realmente odia cuando pasas meses desarrollando una aplicación que tiene más errores que la que reemplazaste.

Si tiene la oportunidad de crear aplicaciones independientes desde cero, utilice todas las mejores prácticas allí y utilícelas para demostrar cuán efectivas son.Cuando puedas, incorpora esas ideas gradualmente a la aplicación anterior.

Answer 2

Primero, consiga una copia de Working de Michael Feather. Efectivamente con código heredado.Luego identifique la mejor manera de probar el código existente.El peor de los casos es que te quedes atrapado con solo algunas pruebas de regresión de alto nivel (o nada en absoluto) y, si tienes suerte, habrá pruebas unitarias.Entonces se trata de una refactorización lenta y constante, con suerte, y al mismo tiempo se agregan nuevas funciones comerciales.

Answer 3

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

Por supuesto, hay mucho espacio entre excelente y pobre, pero mi punto es que si desea un buen código de aplicación, comience por asegurarse de que su base de datos esté al día.

Answer 4

Esto es más difícil de hacer en aplicaciones que sólo están en modo de mantenimiento porque es difícil convencer a la gerencia de que vale la pena reescribir algo que ya está "funcionando".Comenzaría aplicando los principios de MVC a cualquier código nuevo en el que puedas trabajar (es decir,mueva la lógica de negocios a algo parecido a un modelo, coloque todo su código de diseño/vista en un solo lugar)

A medida que adquiera experiencia con código nuevo en MVC, podrá comenzar a ver oportunidades para cambiar sutilmente el código existente para que también se ajuste.Puede ser un proceso muy lento, pero si puedes mostrar los beneficios de esta forma de hacerlo, podrás convencer a otros y lograr que todo el equipo se una.

Answer 5

Estoy de acuerdo con el enfoque de refactorización lenta;por ejemplo, tome ese código copiado y pegado y extráigalo en cualquier paradigma de Java apropiado (¿una clase, tal vez?o mejor aún, ¿utilizar una biblioteca existente?).Cuando su código es realmente limpio y conciso, pero aún carece de una estrategia arquitectónica general, entonces Podrás hacer que las cosas encajen en una arquitectura general mucho más fácilmente.

Answer 6

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

Tiene una aplicación escrita en JSP de más de 1000 líneas de longitud.Probablemente tenga un modelo de dominio terrible (si es que tiene uno) y no sólo MEZCLA la presentación con la lógica empresarial, sino que la MEZCLA y se queda allí y sigue revolviendo durante horas.No hay forma de eliminar el código que es malo y pasar a una clase de controlador MVC y seguir haciendo lo correcto; simplemente terminarás con una aplicación MVC con un modelo de dominio anémico o una que tiene cosas como llamadas a bases de datos. en el código del controlador, todavía estás fallando.

Podrías probar una nueva aplicación que haga lo correcto y luego hacer que las dos aplicaciones se comuniquen entre sí, pero eso es una nueva complejidad en sí misma.Además, es probable que hagas la misma cantidad de trabajo que harías si empezaras desde cero, pero puede que te resulte más fácil intentar convencer a tus jefes de que este es un mejor enfoque.

Answer 7

Refactorizar iterativamente.Busque también nuevas funciones que se puedan realizar completamente en el nuevo marco como una forma de mostrar el valor del nuevo marco.

Answer 8

Mi sugerencia sería encontrar páginas raras que no requieran una importación de otros JSP o que tengan muy pocas importaciones.Trate cada JSP importado como una caja negra y refactorice estas páginas a su alrededor (de forma iterativa, probando cada cambio y asegurándose de que funcione antes de continuar).Una vez que se hayan limpiado, podrá seguir buscando páginas con más y más importaciones, hasta que finalmente haya refactorizado las importaciones.

Al refactorizar, tenga en cuenta las partes que intentan acceder a recursos que no se proporcionan a la página e intente llevar esto a un controlador.Por ejemplo, cualquier cosa que acceda a la base de datos debe estar dentro de un controlador, dejar que JSP maneje la visualización de la información que el controlador le proporciona a través de un reenvío.De esta manera desarrollarás varios servlets, o cosas así, para cada página.Sugeriría usar un marco basado en un controlador frontal para esta refactorización (por experiencia personal recomiendo Spring y su interfaz de controlador), de modo que cada controlador no sea un servlet separado sino que se delega desde un único servlet que esté asignado apropiadamente.

Para el controlador, es mejor realizar accesos a la base de datos todos a la vez en lugar de intentar hacerlo poco a poco.Los usuarios pueden y generalmente toleran la carga de una 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 de que el código de representación se cuelgue y no proporcione datos al cliente mientras intenta leer otro. pieza de datos de la base de datos.

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