Est-il préférable d'appeler une application de ligne de commande externe ou d'internaliser la logique de cette application?

10

J'ai une sorte de processus «pipeline» qui consiste essentiellement à relier un ensemble d'outils existants pour automatiser un flux de travail. Pour l'une des étapes, il existe un outil de ligne de commande existant qui fait déjà l'essentiel de ce que cette étape doit faire.

L'outil CLI externe est basé sur java, tout comme mon pipeline, il serait donc possible d'intégrer l'outil directement dans l'étape du pipeline, mais l'outil est très complexe et est actuellement étroitement lié à la saisie en ligne de commande (quelque chose comme 37 options de drapeau de configuration).

La question est: est-ce une meilleure idée d'appeler et d'appeler simplement le processus externe, ou serait-il préférable d'intégrer le code externe dans mon application?

Quels sont les avantages / inconvénients de l'intégration par rapport à l'appel du processus externe?

java architecture cdeszaq
la source
L'outil de ligne de commande est-il quelque chose que vous contrôlez, ou est-ce développé par une autre partie?
whatsisname
Il s'agit de la boîte à outils open source (licence Mozilla) dcm4che DICOM, donc il a été développé par une autre partie, mais je peux faire à peu près tout ce que je souhaite.
cdeszaq

Réponses:

12

Est-il préférable de simplement appeler et invoquer le processus externe, ou serait-il préférable d'intégrer le code externe dans mon application?

Il est beaucoup mieux d'intégrer ces choses.

L'interface de ligne de commande n'est qu'une interface, et particulièrement horrible. C'est essentiel, mais il est également rempli de bizarreries et de limitations qui ne sont pas raisonnables.

Chacun des "outils existants pour automatiser un flux de travail" devrait avoir une classe bien rangée qui fait le vrai travail après l'analyse des options de ligne de commande.

Idéalement, la public static void mainfonction fait deux choses dans chacun de ces "outils existants".

  1. Il appelle un analyseur d'options / arguments en ligne de commande.

  2. Il appelle la classe ordonnée qui fait le vrai travail. Pensez à une tâche Ant ou à une tâche Maven qui fait le vrai travail après que Ant ou Maven a géré l'ensemble de l'analyse et de la prise de décision.

Lorsque vous allez intégrer ces choses, vous voulez les classes bien rangées qui font le vrai travail.

S'ils n'existent pas, vous devrez réécrire tous ces outils pour créer la classe bien rangée qui fait le vrai travail, séparée de toute analyse en ligne de commande.

Pour des conseils sur le fonctionnement de ces classes bien rangées, lisez Ant (ou Maven) pour voir comment elles définissent les différentes tâches de travail. C'est un bon modèle mental pour la façon dont plusieurs choses disparates sont intégrées sans revenir à la ligne de commande.

S.Lott
la source
Dans mon cas, la classe qui fait le travail est tout l'outil, et contient la mainméthode, les méthodes d'analyse CLI, etc. C'est plutôt désagréable :(
cdeszaq
@cdeszaq: Dans ce cas, il doit être corrigé. Ce n'est pas une réécriture terriblement difficile, et cela doit être fait.
S.Lott
3
J'ajouterais qu'en fonction de vos délais, vous pourriez intégrer avec l'interface CL existante et le port à une solution correctement intégrée au fil du temps. Mais si vous avez le temps de résoudre ce problème maintenant, faites-le :-)
Martijn Verburg
1
@MartijnVerburg: Bon point. Souvent, il y a une priorité claire. Une partie du flux de travail est plus étroitement intégrée ou pourrait potentiellement avoir une utilisation distincte en tant que «sous-flux de travail». Cela peut conduire à un arriéré de retouches du plus précieux au moins précieux.
S.Lott
Chez mon dernier employeur, nous avons eu un problème lors de l'exécution d'un exe utilitaire (nous mais pas mon code du tout). Aider le développeur «senior» à diagnostiquer pourquoi cet exe ne s'exécuterait pas, j'ai suggéré d'écrire un fichier bat pour le lancer. Ça a marché. Il a arrêté de chercher le problème et c'est comme ça que ça s'est passé. La leçon que j'ai apprise est 1. Ne jamais proposer une mauvaise idée pour résoudre un problème à quelqu'un qui prend des décisions. 2. Utilisez des bibliothèques ou intériorisez votre propre logique autant que possible. Cette «correction» a coûté une foule de support technique sur certaines machines. Il ne croyait pas non plus aux tests ni au contrôle des sources, donc pas de surprise ...
Rig
8

Je dirais de le laisser tranquille si ça marche.

En tant que programmeur, vous apportez de la valeur à votre organisation en résolvant les problèmes avec les logiciels. Résoudre plus de problèmes de qualité et de quantité dans un laps de temps donné est directement lié à votre valeur dans l'organisation. Passer ce temps à créer du code diminue votre valeur car cela vous éloigne de la résolution d'un problème plus important.

Cependant, deux ou trois facteurs qui pourraient atténuer le temps passé seraient l’évolutivité et s’il y avait des problèmes pour la stabilité des programmes externes.

bigtech
la source
Je suis d'accord. Vous pouvez vous exposer à de nombreux problèmes en essayant d'intégrer des programmes / codes tiers dans votre application. Parfois, c'est nécessaire mais, comme le dit le proverbe, "Si ce n'est pas cassé, ne le
répare
5
La résolution des problèmes est excellente. Résoudre certains problèmes tout en ouvrant la porte à d'autres problèmes n'est pas si génial.
yfeldblum
5

Ce n'est ni "meilleur" ni "pire". Il y a simplement des coûts et des avantages différents.

L'écriture et la maintenance d'un logiciel sont souvent plus coûteuses, plus le nombre de points d'intégration augmente la complexité.

  • Une fonction que vous écrivez a un coût d'intégration très faible.
  • Une bibliothèque tierce a un coût d'intégration légèrement plus élevé.
  • Un programme distinct que vous devez exécuter aura un coût d'intégration encore plus élevé.

Notez que ce sont des coûts d'intégration que vous devez comparer avec le coût total qui comprend entre autres le coût d'écriture et de maintenance du logiciel.

Il se peut que vous soyez un programmeur très inexpérimenté, mais un utilisateur expérimenté de longue date.

  • Si vous deviez «débourser» votre coût total pourrait être faible malgré le coût d'intégration plus élevé, car vous pouvez atténuer le coût d'intégration avec votre expérience et vos connaissances.
  • Si vous deviez écrire la fonction vous-même, votre coût total pourrait être assez élevé malgré le faible coût d'intégration en raison de votre programmation inexpérimentée.

La meilleure façon de comprendre:

Est-il préférable d'appeler une application de ligne de commande externe ou d'internaliser la logique de cette application?

Est de calculer les coûts par vous-même. Le coût sera différent pour différents environnements, situations et personnes. La plupart du temps, il vous en coûtera plus cher d'appeler la ligne de commande, mais pas toujours et le seul moyen d'être sûr de faire l'analyse.

Dietbuddha
la source
Dans mon cas, il s'agit essentiellement d'une application externe qui se trouve être open-source et écrite en Java, tout comme mon application. Malheureusement, il n'y a pas simplement une bibliothèque que l'application externe utilise, car cette bibliothèque est étroitement intégrée à l'interface CLI elle-même. A part ça, tous les bons points.
cdeszaq
1

Idéalement, vous voudriez l'intégrer. Surtout s'il s'agit d'une application qui est distribuée - la réduction du nombre de dépendances et de configurations facilitera cela. Mais c'est bien sûr un problème de coût / bénéfice pour votre cas spécifique.

Cela dit, une chose à considérer est la stabilité. J'ai rencontré quelque chose de similaire il y a quelques années et j'ai maintenu le programme cli en place. C'était trop instable, et je ne voulais pas que son plantage supprime l'application parente, qui devait fonctionner 24h / 24 et 7j / 7. Maintenant, ce n'était pas une application java, mais néanmoins, si c'est un problème qui peut s'appliquer, vous voudrez peut-être garder cela à l'esprit.

GrandmasterB
la source