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

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 compañía, no para la que estoy trabajando. En su estado actual se ha vuelto difícil de evolucionar y mantener, nuevo las funcionalidades son difíciles de agregar y a menudo conducen a errores que a veces aparecen en producción. Parece que hay algún código copiado / pegado que resultó en la duplicación del código. La aplicación actual es una especie de compra en línea con contenido similar a cms aquí y allá. Se trata principalmente de Struts y algunos Spring en partes más nuevas del código, tal vez algunos ejbs arrojados por 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 empresa hará una propuesta para reescribir partes de esta aplicación para reducir complejidad, mejorar la calidad y la modularidad, y hacer posible agregar más fácilmente Nuevas funcionalidades sin regresiones. Antes de hacer cualquier compromiso, les gustaría tener algún tipo de aprecio de la calidad del código existente y para evaluar cuánto se puede reutilizar, en orden tener más que una suposición sobre lo que habrá que hacer: reescritura total o parcial reescribir.

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 "básico" cosas: tratamiento de excepciones, registro
• compruebe el nivel de capas (vistas, controladores, capa dao)
• medir la cobertura real de las pruebas unitarias
• quizás ejecute 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 obtener de esto y si realmente significaría algo, tengo la sensación de que lo que pregunta la gerencia es algo incorrecto enfoque, entonces la segunda pregunta sería: ¿alguien tiene una mejor idea?

Agradecería cualquier idea, sugerencia, comentario al respecto.

Editar: agregaré 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 el acceso a datos a nivel JDBC, JSP para la presentación y un marco personalizado para el envío de solicitudes. Afortunadamente para mí, estas configuraciones de bajo nivel me permitieron hacer extensiones y correcciones en dificultad media. Durante el proyecto de 3 años, solo aproximadamente el 20% del código original permaneció como estaba. Tarde o temprano, todo lo demás necesitaba ser cambiado, reemplazado o eliminado (y finalmente pude usar FindBugs y Checkstyle).

También nos enfrentamos al dilema de la reescritura completa. Sin embargo, hubo varios factores en su contra:

• No estoy seguro de que el cliente pagará 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 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 que usaran una nueva interfaz para las funciones antiguas.
• Si hacemos una reescritura completa, debemos 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 compañía tenía sus propias reglas de PMD y el código no pasó. Era más simple argumentar que es suficiente que las nuevas partes pasen la prueba.

Se reduce a lo que realmente quieres hacer.

¿Desea reescribir, a pesar de la complejidad?

• Ponga énfasis en los errores de código. Los gráficos circulares grandes con mucho rojo son convincentes.
• Explique las propiedades del programa y cómo no encajan en la visión corporativa.
• Muestra 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.
• Hacer 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 reescribir?

• 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.
• Solicite un redactor de documentos a tiempo completo.

Si desea probar el código, intente agregar Hello World! función / pantalla a la aplicación. Eso dice cuán difícil y qué tan rápido puede implementar cosas nuevas.

Answer 2

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

• Es una recesión, el costo de reescribirlo desde cero será alto

• Podrían estar intentando vender la empresa lo antes posible

• La gerencia no entiende nada sobre desarrollo de software

Primero iría con algunos hechos simples:

• Use una herramienta para mostrar el SLOC del proyecto
• Ejecute como planeó FindBugs y eventualmente PMD, solo para estimar los defectos
• Hacer una sesión de creación de perfiles rápida
• Verifique las diferentes capas
• Vea si los recursos están generalmente cerrados (Streams, conexiones de 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 hechos, escriba un informe y envíelos a la empresa. Querrán minimizar los costos y le pedirán que evite arreglar el código que no está roto. Comienza con las estadísticas, luego con los hechos y una propuesta con el tiempo / porcentaje aproximado del código afectado / precios.

Por lo general, las aplicaciones Struts heredadas son una tarea difícil de mantener, ya lo hemos hecho. Si no fuera parte de tu trabajo, diría que lo dejes ir. Si te encuentras con "independiente" páginas que no incluyen muchas plantillas y están sujetas a muchos cambios, proponga reescribirlas con alguna otra tecnología.

Answer 3

Te estás enfocando en la capacidad de mantenimiento y la extensibilidad que es perfecta.

Agregaría mirando cuánto tiempo tomará reiniciar el proyecto. ¿Utilizan el 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 debe gestionar las expectativas del cliente por adelantado.

Answer 4

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

Miraría con miras a estandarizar Spring o EJB 3.0 pero no ambos.

No lo he leído yo mismo, pero me pregunto si el libro de Michael Feathers " ; Trabajar eficazmente con código heredado " ¿tiene alguna buena idea?

ACTUALIZACIÓN:

Tal vez pueda ayudar al ponerlos en una compilación automatizada y una integración continua: Cruise Control, Hudson o Team City. Si tiene que hacer alguna refactorización, le ayudará.