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

Question

Tengo que auditar una aplicación Java/J2ee web grande que ha evolucionado durante varios años . Ha sido escrito por otra empresa, no para la que estoy trabajando. En es difícil evolucionar y mantener su estado actual, las nuevas funcionalidades de son difíciles de agregar y a menudo provocan errores que en algún momento aparecen en la producción de . 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 por aquí y por allá. Es principalmente Struts y algunos Spring en partes más nuevas del código, tal vez algunos ejbs lanzados para buena medida. 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 compañía hará una proposición para reescribir partes de esta aplicación para reducir la complejidad de , mejorar la calidad y la modularidad, y hacer posible agregar nuevas funcionalidades sin regresiones. Antes de hacer ningún comentario, les gustaría tener algún tipo de aprecio de la calidad del código existente y calcular cuánto de él puede ser reutilizado, para que tenga más que una conjetura en lo que tendrá que ser hecho - reescritura completa o parcial reescritura.

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 thiking es:

• la salida "básicos" cosas - tratamiento de excepciones, el registro
• a extraer el nivel de estratificación (vistas, controladores, capa DAO)
• medir la cobertura real de la unidad de prueba
• quizá ejecutar algunas Checkstyle, Findbugs y PMD en los proyectos
• ...

Así que la pregunta real es qué otras cosas sh ¿debería tomar en cuenta/verificar/medir/etc.?

no estoy seguro de qué tipo de números que pudiera salir de esto y si realmente significaría algo, tengo la sensación de que lo que la gestión está pidiendo es una especie de enfoque equivocado, por lo que la segunda pregunta sería: ¿alguien tiene una mejor idea?

Agradeceré cualquier idea, sugerencia, comentario al respecto.

Editar: Voy a ser la adición de dos detectores de código muerto a la mezcla: UCD y DCD

Answer 1

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 realizar la reescritura completa.
• Horas de trabajo para comprender completamente que la aplicación completa era demasiado alta. El cliente quería los cambios solicitados antes.
• Los usuarios estaban personalizados para la presentación y el 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 la documentación completa. Para la actualización, necesitábamos documentar solo nuestra parte.
• Es difícil convencer a la administración (propia y del cliente) de una reescritura si el programa funciona (más o menos)
• La empresa tenía sus propias reglas 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 realmente quiere hacer.

¿Desea reescribir, a pesar de la complejidad?

• Ponga é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 se ajustan a la visión corporativa.
• Muestra las opciones de mejora más allá de los requisitos actuales y describe 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 desea volver a escribir?

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

Si desea 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.

Answer 2

me gusta su lista bastante. Creo que tienes un excelente plan de ataque para comenzar.

Mirar para estandarizar en Spring o EJB 3.0 pero no en ambos.

No lo he leído, pero me pregunto si el libro de Michael Feathers "Working Effectively With Legacy Code" tiene alguna buena idea?

ACTUALIZACIÓN:

Tal vez usted puede ayudar a las cosas, poniéndolos en una construcción automatizado e integración continua - Control de Velocidad, Hudson, o Equipo de la Ciudad. 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.

Añadiría un vistazo al tiempo que llevará 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

De hecho no van a pagar por una reescritura completa, porque:

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

• Podrían estar tratando de vender la empresa lo antes posible

• la administración no entiende nada de desarrollo de software

Me gustaría ir primero con algunos hechos simples:

• utilizar una herramienta para visualizar el SLOC del proyecto
• Ejecutar como lo planeado FindBugs y, finalmente, el PMD, sólo para estimar los defectos
• hacer un perfilado rápida
sesión
• Compruebe las diferentes capas
• Ver (conexiones arroyos, Hibernate o JDBC, etc.) si los recursos son generalmente cerrados
• Ver si se utilizan las tecnologías en las que no se aplican (EJB, servicios web, etc.)
• Ver cómo manejan las excepciones y el registro de
• ver si hay demasiado o no lo suficiente abstracción
• ver si podía añadir algunas clases base para reducir la duplicación de código

intenta 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 empresa. 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 han hecho. 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.