Tenemos una base de código Java que ha crecido demasiado para un único JAR monolítico (más de 5000 clases). Una de las tareas que estamos investigando es cuánto esfuerzo sería dividir este único JAR en componentes más pequeños con dependencias controladas entre ellos. Sin embargo, es algo difícil mirar una gran bolsa de código y asegurarse de encontrar los mejores puntos de separación sin algún análisis.¿Existe alguna herramienta de visualización que pueda inspeccionar una base de código Java e informar dependencias entre paquetes?
¿Existen buenas herramientas para inspeccionar y visualizar las dependencias entre paquetes? Dados esos, tendremos un conjunto de puntos de corte sugeridos donde podríamos comenzar a separar el código.
Como ejemplo, en los días previos a Netbeans y Eclipse (y en un trabajo diferente), utilizamos TogetherJ y TogetherEnterprise. Esos tenían la capacidad de hacer un análisis de paquete estático y dibujar el diagrama UML. Ese tipo de comportamiento sería óptimo, pero esa característica por sí sola no es suficiente para justificar el costo.
Creo que si se necesita una herramienta para decirle cómo organizar sus clases 5000, entonces usted está en más problemas de tal herramienta puede retirarse de. Buena suerte. – z5h
@ z5h, ¿de verdad? ¿Por qué no usarías una herramienta para buscar dependencias? El resultado de tal herramienta es muy útil para conducir el trabajo de refactorización. Recuerde, este es el tipo de cosa que le ayuda a identificar los nodos con acoplamiento mutuo débil. Esos nodos pueden convertirse en candidatos para productos de desarrollo entregables por separado. Tiempos de construcción más cortos para ambos, cambios localizados, etc., son todas motivaciones fuertes para este tipo de refactorización. Si hay herramientas que ayuden a señalar "comienza aquí, este corte sería fácil", ¿por qué no usarías tal cosa? –
Solo estaba "comentando" que si estás en la etapa en la que tienes 5000 clases y no hay suficiente arquitectura de aplicaciones para guiarte en la dirección correcta sin una herramienta, parece una situación muy mala. Este no es un ejercicio de optimización donde una herramienta te dice qué mirar a continuación. Esta es la * arquitectura completa de su aplicación *, que debería tener un mejor manejo. Si está usando la herramienta como verificación de ideas, entonces eso suena bien. Si está liderando tu diseño, eso suena aterrador. Hiciste sonar como si la herramienta liderara tu diseño. – z5h