¿Cómo profundizo en el código que no tiene un único punto de entrada?

Trabajo en proyectos Java empresariales que no tienen un único punto de entrada desde donde puedo rastrear el flujo de ejecución. Algunos de los proyectos tienen cientos de clases, y cuando se me pide que agregue una característica a un proyecto, a menudo me encuentro perdido en cuanto a dónde comenzar a mirar el código.

¿Cuál es la mejor manera de sumergirme en tales proyectos para que pueda implementar la función rápidamente sin perder tiempo?

¿El proyecto tiene un conjunto de pruebas unitarias bien mantenidas? Las pruebas unitarias son documentación programática de lo que hace el código.

Además, debe aprender lo suficiente sobre la arquitectura de la aplicación para identificar los lugares donde necesita insertar código para sus nuevas funciones, e ignorar más o menos el resto. No necesita conocer toda la base de código para hacer esto; Si los proyectos están bien diseñados, la funcionalidad ya está suficientemente encapsulada y desacoplada para que pueda centrarse en las partes relevantes. Si tiene suerte, los proyectos ya siguen una arquitectura bien conocida que le servirá de mapa para que la siga.

El código siempre tiene uno o más puntos de entrada. Para proyectos MVC, el punto de entrada es un método de controlador basado en una URL; Es casi seguro que el método accederá a un repositorio de datos y devolverá una vista. Comience por ahí.

Comience con el nivel medio (capa de lógica de negocios).

Ese es uno de los lugares en los que el control llega para cualquier acción del usuario o evento desencadenante si es una aplicación no basada en la interfaz de usuario. Si está en modo de depuración, puede rastrearlo hasta la parte superior e inferior (muy probablemente la capa de acceso a datos).

Tomará algún tiempo, pero esta es la manera eficiente de saltar a proyectos indocumentados.

Si el proyecto usa algún marco (struts-config.xml, ejb config xmls, spring config xmls) tendrá una interfaz definida y usted puede comenzar desde allí también.

Siempre hay un punto de entrada. Para las aplicaciones empresariales de Java: los servlets, los filtros y los oyentes de contexto están en la parte superior, normalmente conducen al arranque de aplicaciones, por ejemplo, el cargador de contexto de Spring, que luego conduce a controladores, luego a entidades y vistas. En realidad, es bastante sencillo, especialmente si se usa un marco como un resorte, tapiz o wicket. Una vez que sepa cómo el marco procesa una solicitud, debería poder identificar los puntos de extensión que necesita.

Comenzaría con una jerarquía de clases. Si tiene uno excelente, si no, encuentre una herramienta que pueda aplicar ingeniería inversa a su código y crear uno para usted. A partir de eso, puede comenzar a ver cómo se pueden relacionar las cosas. Una vez que pueda ver cómo se relacionan las cosas, puede al menos apuntar a áreas en lugar de tener una gran "mezcla de clases". Puede apuntar a un área donde puede ver cómo se asocian entre sí (es esta clase una asociación de esta, es este conjunto de clases un patrón de diseño, etc.). Intente agregar algo de orden y estructura alrededor de lo que está viendo y luego desglosar cada sección.

EDITAR:

Aquí hay algunas publicaciones del desbordamiento de pila que describen las herramientas que podría usar en eclipse (o como aplicaciones independientes) para realizar ingeniería inversa y generar un modelo:

• /programming/51786/recommended-eclipse-plugins-to-generate-uml-from-java-code
• /programming/43344/is-there-some-tool-to-visualize-java-class-hierarchies-and-relations

"¿Cómo se come un elefante". "Un bocado a la vez".

Es casi imposible extender su proyecto de Java si no obtiene los puntos de entrada y una documentación clara de lo que se ha hecho y por qué.

FYI: Cuando entregamos un proyecto a nuestros clientes, ahora nos unimos sistemáticamente a un modelo UML, así como a Java Doc y una documentación impresa. Creamos cientos de vistas del modelo que se muestra como diagramas de clase. Agregamos muchos comentarios y explicamos la arquitectura estática, así como las reglas comerciales y el flujo de métodos. Si nuestros clientes desean tomar su código y dárselo a otra compañía, les será fácil modificar el software existente no solo a nivel de implementación sino también a nivel de arquitectura. Uso potente, simple y brillante de vistas dinámicas de UML desde un solo modelo.

Dicho esto, conozco muy pocos integradores interesados ​​en proporcionar toda esta información porque una vez que el cliente está atrapado, es mejor no dejarlo ir. Dar un modelo completo y una navegación UML dinámica permitirá a los clientes ser independientes y, por lo tanto, esto no es bueno para los ingresos comerciales. Todavía no entiendo por qué los grandes bancos o las compañías de telecomunicaciones son tan ingenuos para quedar atrapados por los integradores y no preguntan el modelo completo en la entrega del proyecto. El código de Java o una documentación impresa no es suficiente. La documentación impresa suele ser un proceso automático. No tiene ningún valor real extraer información del código para imprimirlo o proporcionar un PDF.

SIEMPRE hay puntos de entrada, solo tienes que encontrarlos. Si se trata de una aplicación por lotes programada, hay tareas configuradas en algún lugar. Si se trata de una aplicación web (con Spring), hay asignaciones y controladores. Si se trata de una aplicación de servicios web, hay puntos finales de servicio. Si es una aplicación Swing, hay controladores de eventos o somesuch. Y si se trata de una aplicación de línea de comandos grande y peluda, hay un main()método.

En cuanto a "sumergirse rápidamente", bueno, cuánto tiempo lleva encontrar los puntos de entrada es realmente individual. Si el sistema está escrito de acuerdo con patrones establecidos y está familiarizado con los marcos y las reglas y procesos comerciales subyacentes, entonces debería poder resolverlos muy rápido. Si no, puede llevar más tiempo. Pero no hay un "truco" universal. Acumulas experiencia, aprendes a reconocer patrones y entiendes cómo se construyen y organizan los marcos y mejoras.

En cuanto a tratar con código heredado:

• El libro de Michael Feathers ofrece algunas buenas prácticas sobre cómo abordar el software heredado.

Respecto al flujo de ejecución:

• Es un proyecto de Spring, así que espera que el flujo de control haga trucos de magia. Podría hacer muchos métodos de llamada por reflexión, o incluso AOP. Intentar comprender el "flujo de ejecución" utilizando un depurador puede causar frustración.
• Es un proyecto de Spring, por lo que la estructura del proyecto es bastante homogénea. Aprenda Spring (si aún no lo ha hecho) para comprender los conceptos de frijoles y cableado. Esto te dice qué clases trabajan juntas.

En cuanto al punto de entrada:

• Déjame adivinar: es una aplicación web. Déjame adivinar de nuevo: está usando Spring MVC. Aprenda este también, para saber cómo encontrar las clases de controlador para las páginas. Estos son los puntos de entrada a su aplicación. Se llaman por reflexión, por lo que no los encontrará utilizando el análisis estático del código fuente.