Diario de Programación

En el trabajo estamos juntos dos departamentos en uno solo. Las filosofías de trabajo de ambos eran distintas y nos está costando integrar nuestro código precisamente por eso.

Unos trabajan con la filosofía de EL.jar, es decir, todo el proyecto en un solo jar. Los proyectos corren con tres ejecutables distintos, uno de ellos de interface gráfica de usuario básicamente, pero todos ellos son el mismo jar. Sólo se cambia inidica en el arranque cual es la clase que tiene el main().

Este método demuestra ser eficiente en el sentido de evitar complejidad. EL.jar lo tiene todo, es lo que hay que arrancar y se compila siempre todo junto y a la vez. Cuando viene otro proyecto similar, se copia entero y se sigue desarrollando en la nueva copia.

La pega que tiene es que cuando necesitas algo suelto de ahí, puedes obtenerlo, pero trayéndote EL.jar completo. Si necesitas un pequeño panel de interface de usuario que es capaz de pedir una serie de datos, tienes que traerte EL.jar. Si necesitas un algoritmo que tienen que convierte peras en castañas, también necesitas EL.jar. Al estar todo junto, los programadores no controlan muy bien -y de hecho les da igual- el tema de dependencias de unas clases con otras.

La otra filosofía existente es la de hacer muchos.jar. Cada módulo, tema, etc, se hace en un jar más o menos independiente y separado.

Esto evita el problema anterior. Si necesitas algo concreto, te traes un jar pequeño -si acaso con otros jar pequeños de los que depende- y puedes usar ese algo concreto. La gran pega de este sistema es que el despliegue del proyecto se hace relativamente complicado -es casi obligatorio el uso de herramientas o scripts que lo hagan automáticamente-. También el gestionar dependencias y versiones de los jar pequeñitos y las dependencias entre ellos.

Dos filosofías de trabajo distintas. ¿De cual eres partidario? ¿Qué ventajas e inconvenientes ves además de los expuestos?