È meglio chiamare un'applicazione da riga di comando esterna o interiorizzare la logica di quell'applicazione?

10

Ho una sorta di "pipeline" di processo che essenzialmente sta semplicemente collegando un insieme di strumenti esistenti per automatizzare un flusso di lavoro. Per uno dei passaggi, esiste uno strumento da riga di comando esistente che fa già la carne di ciò che quel passaggio deve fare.

Lo strumento CLI esterno è basato su Java, così come la mia pipeline, quindi sarebbe possibile integrare lo strumento direttamente nella fase della pipeline, ma lo strumento è molto complesso ed è attualmente strettamente legato all'avere input da riga di comando (qualcosa come 37 opzioni di bandiera di configurazione).

La domanda è: è una migliore idea semplicemente chiamare e invocare il processo esterno o sarebbe meglio integrare il codice esterno nella mia applicazione?

Quali sono i pro / contro dell'integrazione rispetto alla chiamata del processo esterno?

java architecture

— cdeszaq
fonte

Lo strumento da riga di comando è qualcosa che controlli o è sviluppato da un'altra parte?

— whatsisname

È il toolkit DICOM dcm4che open source (licenza Mozilla), quindi è stato sviluppato da un'altra parte, ma posso farci praticamente tutto ciò che desidero.

— cdeszaq,

12

È un'idea migliore semplicemente richiamare e invocare il processo esterno o sarebbe meglio integrare il codice esterno nella mia applicazione?

È molto meglio integrare queste cose.

L'interfaccia della riga di comando è solo un'interfaccia e particolarmente terribile. È essenziale ma è anche pieno di stranezze e limitazioni che non sono sensate.

Ognuno degli "strumenti esistenti per automatizzare un flusso di lavoro" dovrebbe avere una classe ordinata che fa il vero lavoro dopo aver analizzato le opzioni della riga di comando.

Idealmente, la public static void mainfunzione fa due cose in ciascuno di quegli "strumenti esistenti".

Richiama un parser di opzioni / argomenti della riga di comando.
Invoca la classe ordinata che fa il vero lavoro. Pensa a un'attività di formica o un'attività di Maven che fa il vero lavoro dopo che Ant o Maven hanno gestito tutto l'analisi e il processo decisionale.

Quando vai a integrare queste cose, vuoi le classi ordinate che fanno il vero lavoro.

Se non esistono, dovrai riscrivere tutti quegli strumenti per creare la classe ordinata che fa il vero lavoro, separata da ogni analisi da riga di comando.

Per indicazioni su come dovrebbero funzionare queste classi ordinate, leggi Ant (o Maven) per vedere come definiscono i vari compiti dei lavoratori. È un buon modello mentale per l'integrazione di più elementi disparati senza tornare alla riga di comando.

— S. Lott
fonte

Nel mio caso, la classe che fa il lavoro è l'intero strumento e contiene il mainmetodo, i metodi CLI-parse, ecc. È piuttosto brutto :(

— cdeszaq,

@cdeszaq: in tal caso, deve essere corretto. Non è una riscrittura terribilmente difficile, e deve essere fatto.

— S.Lott

3

Aggiungo che a seconda delle scadenze, è possibile integrarsi con l'interfaccia CL e la porta esistenti su una soluzione correttamente integrata nel tempo. Ma se hai tempo per risolvere questo problema, allora fallo :-)

— Martijn Verburg,

1

@MartijnVerburg: buon punto. Spesso c'è una chiara priorità. Parte del flusso di lavoro è più strettamente integrato o potrebbe potenzialmente avere un uso separato come "flusso di lavoro secondario". Ciò può comportare un arretrato di rilavorazioni dal più prezioso al meno prezioso.

— S.Lott

Nel mio ultimo datore di lavoro abbiamo avuto un problema nell'esecuzione di un exe di utilità (noi ma non il mio codice). Aiutando lo sviluppatore "senior" a diagnosticare perché questo exe non sarebbe stato eseguito, ho suggerito di scrivere un file bat per dare il via. Ha funzionato. Ha smesso di cercare il problema ed è così che è uscito dalla porta. La lezione che ho imparato è 1. Non proporre mai una cattiva idea per risolvere un problema a qualcuno che prende decisioni. 2. Utilizzare le librerie o interiorizzare la propria logica il più possibile. Quella "correzione" è costata una miriade di supporto tecnico su alcune macchine. Inoltre non credeva nei test o nel controllo del codice sorgente, quindi nessuna sorpresa ...

— Rig

8

Direi che lasciarlo da solo se funziona.

Come programmatore dai valore alla tua organizzazione risolvendo problemi con il software. La risoluzione di più problemi sia in termini di qualità che di quantità in un determinato periodo di tempo è direttamente correlata al tuo valore nell'organizzazione. Trascorrere questo tempo nella creazione di codice riduce il valore poiché ti allontana dalla risoluzione di un problema più importante.

Tuttavia, un paio di fattori che potrebbero mitigare il passare del tempo sarebbero la scalabilità e se ci fossero preoccupazioni per la stabilità dei programmi esterni.

— bigtech
fonte

Sono d'accordo. Puoi aprirti a molti problemi cercando di integrare programmi / codice di terze parti nella tua app. A volte è necessario ma, come dice il proverbio, "Se non è rotto, non aggiustarlo"

— jfrankcarr,

5

Risolvere i problemi è fantastico. Risolvere alcuni problemi mentre si apre la porta ad altri problemi non è così grande.

— yfeldblum,

5

Non è "migliore" o "peggiore". Ci sono semplicemente costi e benefici diversi.

Spesso è più costoso scrivere e mantenere un software più grande è il numero di punti di integrazione rispetto alla complessità aggiunta.

Una funzione che scrivi ha costi di integrazione molto bassi.
Una libreria di terze parti ha costi di integrazione leggermente maggiori.
Un programma separato che dovrai eseguire avrà un costo di integrazione ancora maggiore.

Si noti che si tratta di costi di integrazione che devono essere confrontati con il costo totale che comprende, tra l'altro, i costi per la scrittura e la manutenzione del software.

È possibile che tu sia un programmatore inesperto, ma un utente esperto da molto tempo.

Se dovessi "sborsare" il tuo costo totale potrebbe essere basso nonostante i costi di integrazione più elevati, perché puoi mitigare il costo di integrazione con la tua esperienza e conoscenza.
Se dovessi scrivere la funzione da solo, il costo totale potrebbe essere piuttosto elevato nonostante il basso costo di integrazione a causa della tua programmazione di inesperienza.

Il modo migliore per capire:

È meglio chiamare un'applicazione da riga di comando esterna o interiorizzare la logica di quell'applicazione?

È calcolare i costi per te stesso. Il costo sarà diverso per diversi ambienti, situazioni e persone. Il più delle volte costerà di più chiamare dalla riga di comando, ma non sempre e l'unico modo per essere sicuri di fare l'analisi.

— dietbuddha
fonte

Nel mio caso, si tratta essenzialmente di un'applicazione esterna che sembra essere open source e scritta in Java, proprio come la mia applicazione. Sfortunatamente, non esiste semplicemente una libreria utilizzata dall'applicazione esterna, poiché tale libreria è strettamente integrata nell'interfaccia CLI stessa. A parte questo, tutti i punti positivi.

— cdeszaq,

1

Idealmente, vorresti integrarlo. Soprattutto se si tratta di un'app che viene distribuita, riducendo il numero di dipendenze e configurazioni sarà più facile. Ma è ovviamente un problema di costi / benefici per il tuo caso specifico.

Detto questo, una cosa da considerare è la stabilità. Ho incontrato qualcosa di simile un paio di anni fa e ho mantenuto il programma cli in atto. Era troppo instabile e non volevo che il suo arresto anomalo eliminasse l'applicazione padre, che doveva essere eseguita 24/7. Ora questa non era un'app Java, ma comunque, se è un problema che potresti applicare, potresti voler tenerlo in considerazione.

— GrandmasterB
fonte