¿Es mejor idea llamar a una aplicación de línea de comandos externa o internalizar la lógica de esa aplicación?

10

Tengo un tipo de proceso de "canalización" que esencialmente es solo unir un conjunto de herramientas existentes para automatizar un flujo de trabajo. Para uno de los pasos, hay una herramienta de línea de comandos existente que ya hace la carne de lo que ese paso debe hacer.

La herramienta CLI externa está basada en Java, y también lo es mi canalización, por lo que sería posible integrar la herramienta directamente en el paso de canalización, pero la herramienta es muy compleja y actualmente está estrechamente vinculada a tener una entrada de línea de comandos (algo así como 37 opciones de bandera de configuración).

La pregunta es: ¿es una mejor idea simplemente llamar e invocar el proceso externo, o sería mejor integrar el código externo dentro de mi aplicación?

¿Cuáles son las ventajas y desventajas de integrar frente a llamar al proceso externo?

java architecture

— cdeszaq
fuente

¿La herramienta de línea de comandos es algo que usted controla o es desarrollada por otra parte?

— cuál es

Es el kit de herramientas de código abierto (licencia de Mozilla) dcm4che DICOM, por lo que ha sido desarrollado por otra parte, pero puedo hacer lo que quiera.

— cdeszaq 01 de

12

¿Es una mejor idea simplemente llamar e invocar el proceso externo, o sería mejor integrar el código externo dentro de mi aplicación?

Es mucho mejor integrar estas cosas.

La interfaz de línea de comandos es solo una interfaz, y particularmente horrible. Es esencial, pero también está lleno de caprichos y limitaciones que no son sensibles.

Cada una de las "herramientas existentes para automatizar un flujo de trabajo" debe tener una clase ordenada que haga el trabajo real después de analizar las opciones de la línea de comandos.

Idealmente, la public static void mainfunción hace dos cosas en cada una de esas "herramientas existentes".

Invoca un analizador de opciones / argumentos de la línea de comandos.
Invoca la clase ordenada que hace el trabajo real. Piense en una tarea Ant o una tarea Maven que hace el trabajo real después de que Ant o Maven haya manejado todo el análisis y la toma de decisiones.

Cuando intentas integrar estas cosas, quieres las clases ordenadas que hacen el trabajo real.

Si no existen, tendrá que reescribir todas esas herramientas para crear la clase ordenada que hace el trabajo real, separada de todo el análisis de la línea de comandos.

Para obtener orientación sobre cómo deberían funcionar estas clases ordenadas, lea Ant (o Maven) para ver cómo definen las diversas tareas de los trabajadores. Es un buen modelo mental de cómo se integran cosas múltiples y dispares sin volver a la línea de comando.

— S.Lott
fuente

En mi caso, la clase que hace el trabajo es la herramienta completa y contiene el mainmétodo, los métodos de análisis de CLI, etc. Es bastante desagradable :(

— cdeszaq

@cdeszaq: en ese caso, necesita ser reparado. No es una reescritura terriblemente difícil, y debe hacerse.

— S.Lott 01 de

3

Agregaría que, dependiendo de sus plazos, podría integrarse con la interfaz CL existente y el puerto a una solución integrada con el tiempo. Pero si tienes tiempo para arreglar esto ahora, entonces hazlo :-)

— Martijn Verburg

1

@MartijnVerburg: Buen punto. A menudo, hay una clara prioridad. Parte del flujo de trabajo está más estrechamente integrado o podría tener un uso separado como "subflujo de trabajo". Esto puede llevar a una acumulación de trabajos atrasados de más valioso a menos valioso.

— S.Lott 01 de

En mi último empleador tuvimos un problema al ejecutar un exe de utilidad (nosotros pero no mi código en absoluto). Al ayudar al desarrollador "senior" a diagnosticar por qué este exe no se ejecutaba, sugerí escribir un archivo bat para iniciarlo. Funcionó. Dejó de buscar el problema y así fue como salió por la puerta. La lección que aprendí es 1. Nunca propongas una mala idea para solucionar un problema a alguien que toma decisiones. 2. Use bibliotecas o internalice su propia lógica tanto como sea posible. Esa "solución" costó una gran cantidad de soporte técnico en algunas máquinas. Tampoco creía en las pruebas o el control de la fuente, así que no es de extrañar ...

— Rig

8

Yo diría que lo dejes en paz si funciona.

Como programador, usted aporta valor a su organización al resolver problemas con el software. Resolver más problemas en calidad y cantidad dentro de un período de tiempo determinado está directamente relacionado con su valor en la organización. Pasar este tiempo para crear código disminuye su valor, ya que le evita resolver un problema más importante.

Sin embargo, un par de factores que podrían mitigar el gasto del tiempo serían la escalabilidad y si hubiera alguna preocupación por la estabilidad de los programas externos.

— bigtech
fuente

Estoy de acuerdo. Puede abrirse a muchos problemas al intentar integrar programas / código de terceros en su aplicación. A veces es necesario pero, como dice el refrán, "Si no está roto, no lo arregles"

— jfrankcarr

55

Resolver problemas es genial. Resolver algunos problemas mientras se abre la puerta a otros problemas no es tan bueno.

— yfeldblum

5

No es "mejor" o "peor". Simplemente hay diferentes costos y beneficios.

A menudo es más costoso escribir y mantener una pieza de software cuanto mayor sea el número de puntos de integración a la complejidad adicional.

Una función que escriba tiene muy poco costo de integración.
Una biblioteca de terceros tiene un costo de integración ligeramente mayor.
Un programa separado que debe ejecutar tendrá un costo de integración aún mayor.

Tenga en cuenta que estos son costos de integración que debe comparar con el costo total, que incluye, entre otras cosas, el costo de escribir y mantener el software.

Puede ser que usted sea un programador muy inexperto, pero un usuario avanzado desde hace mucho tiempo.

Si tuviera que "pagar" su costo total podría ser bajo a pesar del mayor costo de integración, porque puede mitigar el costo de integración con su experiencia y conocimiento.
Si tuviera que escribir la función usted mismo, su costo total podría ser bastante alto a pesar del bajo costo de integración debido a su programación inexperta.

La mejor manera de descubrirlo:

¿Es mejor idea llamar a una aplicación de línea de comandos externa o internalizar la lógica de esa aplicación?

Es calcular los costos por ti mismo. El costo será diferente para diferentes entornos, situaciones y personas. La mayoría de las veces costará más llamar a la línea de comando, pero no siempre es la única forma de asegurarse de que realice el análisis.

— dietbuddha
fuente

En mi caso, es esencialmente una aplicación externa que resulta ser de código abierto y está escrita en Java, al igual que mi aplicación. Desafortunadamente, no hay simplemente una biblioteca que use la aplicación externa, ya que esa biblioteca está integrada en la interfaz de la CLI. Aparte de eso, todos los buenos puntos.

— cdeszaq

1

Lo ideal sería integrarlo. Especialmente si esta es una aplicación que se distribuye, reducir la cantidad de dependencias y configuraciones lo hará más fácil. Pero, por supuesto, es un problema de costo / beneficio para su caso específico.

Dicho esto, una cosa a considerar es la estabilidad. Encontré algo similar hace un par de años y mantuve el programa cli en su lugar. Era demasiado inestable, y no quería que su bloqueo eliminara la aplicación principal, que necesitaba ejecutarse 24/7. Ahora, esta no era una aplicación de Java, pero no obstante, si es un problema que puede aplicarse, es posible que desee tenerlo en cuenta.

— Gran maestro B
fuente