¿Cuál es el mejor enfoque para auditar una aplicación web grande java/j2ee?

java-ee

Question

Tengo que auditar una gran aplicación web Java / J2ee que ha evolucionado a lo largo de varios años. Ha sido escrito por otra empresa, no para la que estoy trabajando. En su estado actual se ha vuelto difícil evolucionar y mantener, las nuevas funcionalidades son difíciles de agregar y a menudo conducen a errores que en algún momento aparecen en la producción. Parece que hay algún código de copia / pegado que dio como resultado la duplicación del código. La aplicación actual es algún tipo de compra en línea con contenido cms aquí y allá. Es sobre todo Struts y algo de Spring en las partes más nuevas del código, quizás algunos ejbs arrojados por si acaso. Hay algunas pruebas unitarias disponibles, pero no muchas. Estas son cosas que me han dicho, aún no he visto el código real.

Mi empresa hará una propuesta para reescribir partes de esta aplicación a fin de reducir la complejidad, mejorar la calidad y la modularidad, y posibilitar la incorporación de nuevas funcionalidades más sencillas sin regresiones. Antes de comprometerse, les gustaría tener algún tipo de apreciación de la calidad del código existente y evaluar cuánto de él puede reutilizarse, para tener más que una conjetura sobre lo que tendrá que hacerse: completo reescribir o reescribir parcialmente.

El problema es que tendré que hacer esto en un período muy corto (un par de días), así que estoy tratando de elaborar un plan para lo que se puede hacer en tan poco tiempo. Lo que estoy pensando es:

• echa un vistazo a las cosas "básicas": tratamiento de excepciones, registro
• compruebe el nivel de estratificación (vistas, controladores, capa de dao)
• medir la cobertura real de las pruebas unitarias
• tal vez ejecutar algunos Checkstyle, Findbugs y PMD sobre los proyectos
• ...

Entonces, la pregunta real es ¿qué otras cosas debo tener en cuenta / verificar / medir / etc.?

No estoy seguro de qué tipo de números podría sacar de esto y si realmente significaría algo, tengo la sensación de que lo que la gerencia está haciendo es un enfoque equivocado, por lo que la segunda pregunta sería: ¿alguien lo ha hecho? una mejor idea?

Apreciaré cualquier idea, sugerencia, comentario sobre esto.

Editar: Agregaré dos detectores de código muerto a la mezcla: UCD y DCD

Answer 1

De hecho, no pagarán por una reescritura completa, porque:

• Es recesión, el costo de volver a escribir desde cero será alto

• Ellos podrían estar tratando de vender la compañía lo antes posible

• La gerencia no entiende nada sobre el desarrollo de software

Primero iría con algunos hechos simples:

• Use una herramienta para mostrar el SLOC del proyecto
• Ejecute como planeaba FindBugs y eventualmente PMD, solo para estimar los defectos
• Haz una sesión rápida de creación de perfiles
• Comprueba las diferentes capas
• Vea si los recursos generalmente están cerrados (conexiones Streams, Hibernate o JDBC, etc.)
• Vea si las tecnologías se utilizan donde no se aplican (EJB, servicios web, etc.)
• Vea cómo manejan las excepciones y el registro
• Vea si hay demasiada o no suficiente abstracción
• Vea si puede agregar algunas clases base para reducir la duplicación de código

Intente dibujar un diagrama rápido de la arquitectura de la aplicación, si no le dan un documento al respecto.

Reúna algunas estadísticas y algunos datos, escriba un informe y envíelos a la compañía. Querrán minimizar los costos y le pedirán que evite corregir el código que no está roto. Empiezas con las estadísticas, luego con los hechos y una proposición con tiempo / porcentaje aproximado del código afectado / fijación de precios.

Por lo general, las aplicaciones heredadas de Struts son una pita para mantener, ya se ha hecho eso. Si no fuera parte de tu trabajo, yo diría que lo dejes ir. Si se encuentra con páginas "independientes" que no involucran muchas plantillas y están sujetas a muchos cambios, proponga reescribirlas con alguna otra tecnología.

Answer 2

Me gusta mucho tu lista. Creo que tienes un excelente plan de ataque para comenzar.

Yo miraría con miras a estandarizar en Spring o EJB 3.0 pero no en ambos.

No lo he leído por mi cuenta, pero me pregunto si el libro de Michael Feathers "Trabajar eficazmente con código heredado" tiene alguna buena idea.

ACTUALIZAR:

Tal vez pueda ayudar con las cosas mediante una compilación automática y una integración continua: Cruise Control, Hudson o Team City. Si tiene que hacer alguna refactorización, lo ayudará.

Answer 3

Se está centrando en la facilidad de mantenimiento y la extensibilidad, que es perfecta.

Agregaría mirando cuánto tiempo tomará reiniciar el proyecto. ¿Usan control de fuente? ¿Tienen entornos separados para la integración y las pruebas de aceptación del usuario? ¿Hay un servidor de compilación?

Cuando tiene que pasar dos meses antes de que aparezca la primera mejora, alguien necesita administrar las expectativas del cliente por adelantado.

Answer 4

Tenía dos aplicaciones web con configuraciones similares a las tuyas. Dejé de usar FindBugs y Checkstyle ya que mostraban más de 10.000 puntos problemáticos. Las aplicaciones utilizaron acceso a datos a nivel JDBC, JSP para presentación y un marco personalizado para envío de solicitudes. Afortunadamente para mí, estos ajustes de bajo nivel me permitieron hacer las extensiones y correcciones en dificultad media. Durante el proyecto de 3 años, solo alrededor del 20% del código original permaneció como estaba. Tarde o temprano todo lo demás tenía que cambiarse, reemplazarse o eliminarse (y finalmente pude usar FindBugs y Checkstyle).

Nosotros también enfrentamos el dilema de la reescritura completa. Sin embargo, hubo varios factores en su contra:

• No estoy seguro de que el cliente pague por una reescritura completa.
• La falta de documentación funcional y técnica hace que sea arriesgado hacer la reescritura completa.
• Manhours para comprender completamente la aplicación completa era demasiado alta. El cliente quería los cambios solicitados antes.
• Los usuarios se adaptaron a la presentación y al comportamiento de la página. Parecía difícil convencer a los usuarios de usar una nueva interfaz para funciones antiguas.
• Si hacemos una reescritura completa, tenemos que proporcionar documentación completa. Para la actualización, necesitábamos documentar solo nuestra parte.
• Es difícil convencer a la gerencia (propia y del cliente) de una reescritura si el programa funciona (más o menos)
• La empresa tenía sus propias reglas de PMD y el código no se aprobó. Era más simple argumentar que es suficiente que las partes nuevas pasen la prueba.

Todo se reduce a lo que quieres hacer en realidad.

¿Quieres volver a escribir, a pesar de la complejidad?

• Pon énfasis en los errores de código. Los grandes gráficos circulares con mucho rojo son convincentes.
• Explique las propiedades del programa y cómo no encajan en la visión corporativa.
• Muestre opciones de mejora más allá de los requisitos actuales y describa cómo la versión actual no está a la altura del desafío.
• Haga entrevistas con los usuarios reales. Podrían señalar problemas importantes con la versión actual.
• Sea barato pero un buen estimador. Puede retrasar algunos costos hasta la fase de mantenimiento.

¿No quieres volver a escribir?

• Ponga énfasis en el costo, especialmente las horas de trabajo requeridas por el cliente para volver a probar todo.
• Señale el problema potencial de romper la funcionalidad.
• Pida un escritor de documentos a tiempo completo.

Si quiere probar el código, intente agregar Hello World. función / pantalla a la aplicación. Eso le dice qué tan duro y qué tan rápido puede implementar cosas nuevas.