Cómo organizar proyectos de Java de mayor tamaño: ¿proyectos frente a espacios de nombres?

Question

Me pregunto si hay alguna lectura recomendada, mejor práctica u opinión sobre cómo organizar proyectos de Java de mayor tamaño.

Hice las observaciones de que hay personas que dividen todo en proyectos (es decir, módulos) y crean muchos proyectos que comparten una red de dependencias. Esto tiene la ventaja de que la compilación suele ser superrápida, pero cuando el proyecto se amplía ya nadie sabe qué depende de qué y por qué. Sin hablar de bibliotecas dependientes, conflictos de versiones & co.

La alternativa es tener solo un par de proyectos como frontend, backend, .... El espacio de nombres hace el trabajo.

¿Alguna opinión, lecturas adicionales que alguien pueda recomendar?

Answer 1

Un proyecto muy grande tendrá que tener alguna forma de seguimiento de todas las bibliotecas y otras dependencias que utiliza. El estándar de facto para hacer esto es Maven. Definitivamente es la mejor manera de comenzar a hacer un seguimiento de lo que está entrando en su aplicación.

Luego puede decidir cómo dividir su aplicación. Básicamente, lo que intenta hacer aquí es dividir su aplicación en piezas funcionales completas. Por ejemplo, si tuviera un sitio web que tuviera un formulario de contacto, una galería de fotos, un carrito de compras y un foro, dividiría el proyecto en partes que contuvieran cada uno de esos diferentes módulos.

Answer 2

En cuanto empiezas a dividir un gran proyecto en proyectos más pequeños, encuentras un montón de seguimiento de la dependencia que generalmente no tienes que considerar. Puede hacerlo usted mismo o puede usar un software que ya maneje muchos de los problemas centrales.

I would recommend Apache's Ivy. Se integra bien con Apache's Ant, y tiene un archivo de configuración separado (que se controla) para rastrear lo que se requiere para cada tipo de compilación.

Apache's Maven es otra buena opción; sin embargo, hace mucho más que Apache's Ivy. Algunas veces ese "mucho más" significa que haces menos de lo que hubieras hecho de todos modos, a veces eso "mucho más" significa que estás haciendo (y configurando) cosas que no has hecho antes. Dependiendo del ajuste de su práctica a Maven, la migración a Maven podría ser fácil o muy difícil.

Además, utilizando Ivy, puede configurar su propio repositorio privado de archivos jar "permitidos" para extraer, y eso hará que la auditoría de código sea mucho más fácil. Básicamente, reconfigure la hiedra para que no se extraiga de la web, sino para extraerla de su repositorio local únicamente, y luego controle el acceso al repositorio para que solo permita que los archivos jar revisados ​​tengan una licencia aceptable.

Una vez que tenga el software en su lugar, puede permitirse dividir los proyectos en partes más pequeñas. Esto le permitirá hacer lo correcto (si su proyecto favorece la descomposición pequeña) en lugar de lo conveniente (unos pocos trozos grandes que podrían no serle de gran utilidad en el mantenimiento de la descomposición). En cuanto a dónde hacer los cortes, eso depende en gran medida de los detalles de su aplicación.

Muchas piezas pequeñas tienden a ser más fáciles de digerir una persona nueva una a una. También hacen que la gente piense en dónde se debe agregar funcionalidad a un proyecto; sin embargo, cuesta tiempo y esfuerzo desenredar y separar todos los componentes. El lado positivo es que generalmente es más fácil probar y validar algo más pequeño, la desventaja es que es un camino más largo para descomponer un conjunto monolítico de responsabilidades en muchas unidades pequeñas, bien integradas pero funcionalmente dispares.

Buena suerte

Answer 3

En realidad, querrá utilizar tanto proyectos como espacios de nombres.

El espaciado de nombres es una herramienta importante para diferenciar el propósito de un código en el nivel de código. Sin importar de qué proyecto provenga una clase, el paquete debería darme una idea de su propósito.

En un nivel superior, es más fácil administrar las construcciones y su entorno de desarrollo al tener su código separado en proyectos. Por ejemplo, si está desarrollando una UI, ¿por qué necesita tener el código de la base de datos cargado en su IDE? Es un desorden extra en su espacio de trabajo. También hace que sea más sencillo compartir una funcionalidad común entre diferentes proyectos. Por supuesto, esto llevará a la necesidad de algún tipo de gestión de la dependencia, de la cual cualquiera de las herramientas mencionadas, como Maven o Ivy, será suficiente.

Una nota importante sin embargo. No use paquetes divididos entre proyectos. Esto causa pesadillas si usted o alguien que alguna vez usará su código desea hacerlo en un entorno OSGi. Por lo tanto, sus espacios de nombres deben ser únicos dentro de un proyecto, aunque deben compartir una raíz común con otros proyectos relacionados.