Le développement des applications CLI est-il considéré comme «à retardement»? [fermé]

38

Je suis une DBA débutante avec beaucoup d'expérience en programmation.

J'ai développé plusieurs applications CLI non interactives qui résolvent des tâches répétitives quotidiennes ou éliminent l'erreur humaine de tâches plus complexes bien que moins quotidiennes. Ces outils font maintenant partie de notre boîte à outils.

Les applications CLI sont excellentes, car vous pouvez les inclure dans un flux de travail automatisé.

De plus, la philosophie d'Unix consistant à faire une seule chose mais à bien le faire, et à laisser le résultat d'un processus être la contribution d'un autre, est un excellent moyen de créer un ensemble d'outils qui ne serait pas consolidé en un avantage stratégique.

Mon patron a récemment déclaré que le développement d'outils CLI est "en arrière" ou constitue une "régression".

Je lui ai dit que je n'étais pas d'accord, car la plupart des outils CLI existants ne sont pas des projets hérités, mais des projets en direct avec des versions améliorées publiées tout le temps.

Ce type de développement est-il considéré comme "à l’arrière" sur le marché?

Ça a l'air mauvais sur un rèsumè?

J'ai également examiné toutes les solutions, qu'elles soient Web ou de bureau, devraient avoir des options non interactives en ligne de commande. Certaines personnes considèrent cela comme un gaspillage de ressources de programmation.

Cet objectif est-il digne d'un projet logiciel?

Je pense également que pour une application Web ou de bureau, le fait de disposer d'une interface CLI alternative constitue un excellent moyen de démontrer que la logique métier est complètement découplée de l'interface graphique.

Tulains Córdova
la source
32
Votre patron vient-il d'un milieu technique? On dirait qu'il suit la philosophie "je ne vois pas grand chose, car il n'y a pas grand chose à faire". Ce qui peut être problématique. Demandez-lui s'il pense que les personnes qui développent Oracle sont également en retard.
Joachim Sauer
13
J'aime la façon dont les choses se passent dans le monde Linux. La plupart des applications "majeures" ont à la fois des interfaces CLI et des interfaces utilisateur graphiques - c’est là un principe libre, car vous pouvez écrire un script quand vous en avez besoin et cliquer avec votre souris quand vous n’avez pas besoin de le faire. Je ne vois pas pourquoi vous devez nécessairement choisir l'un par rapport à l'autre. Écrire une CLI ne demande pas beaucoup de travail.
MrFox
6
De toute évidence, votre patron n'a jamais essayé d'écrire le script le plus élémentaire
toasted_flakes.
1
@MrFox Je suis d'accord avec vous, les applications devraient avoir les deux frontaux.
Tulains Córdova
4
Je aime cela , mais malheureusement , il y a aussi parfois cette ;)
wim

Réponses:

21

Avoir la capacité de travailler avec une CLI n’est guère ce que je considérerais à l’arrière. Cela a fière allure sur un CV, surtout si vous pouvez le modifier avec une phrase telle que "Utilisé (Powershell / Bash) pour créer une suite d’outils d’automatisation permettant d’envoyer des SMS lorsque la base de données est en panne".

Lorsque je suis responsable de l’embauche de personnel, je recherche une connaissance pratique de la CLI.

Jonathan Arkell
la source
49

Cela revient essentiellement à "utiliser le bon outil pour le travail".

Si vous devez interagir avec un utilisateur, vous aurez besoin d’une sorte d’interface graphique. Nous avons des décennies de recherche et d'expérience prouvant qu'ils rendent l'informatique beaucoup plus intuitive et productive. C'est pourquoi les interfaces graphiques ont inexorablement envahi le monde depuis 1984: elles fonctionnent mieux pour interagir avec les gens.

Mais si vous automatisez un programme avec des scripts, votre programme n'interagit pas avec les gens; c'est interagir avec un script. Et la meilleure interface pour cela est une interface texte, pour des raisons qui devraient être intuitivement évidentes.

Le développement de programmes CLI pour que les utilisateurs puissent travailler directement avec eux est considéré comme un retour en arrière, et avec raison. Mais si ce n'est pas ce que vous faites, si vous écrivez des outils de productivité automatisés, vous ne faites rien de mal en leur donnant une CLI.

Maçon Wheeler
la source
6
+1 Certains outils fournissent des informations aux utilisateurs, telles que "toutes les sauvegardes de la base de données sont-elles à jour, sinon, dites-moi lesquelles sont anciennes?". Ils impriment la réponse à STDOUT. Mais évidemment, il peut être mis sur une crontab afin d’envoyer un SMS si la réponse est NON. Je pense que même si l'application est une interface graphique, elle devrait avoir un mode CLI avec des paramètres. Je suis moi-même un admirateur des interfaces graphiques, je suis un utilisateur de Mac après tout. De nombreuses applications critiques, en particulier celles développées en interne, n’envisagent jamais une interface de ligne de commande.
Tulains Córdova
23
Même si je suis d'accord à 99%, j'ai également constaté qu'en tant qu'utilisateur technique, je préfère parfois l'interface CLI à une interface graphique. La raison en est que de nombreuses interfaces graphiques me demandent de naviguer, de pointer, de cliquer, de naviguer dans les menus, de rechercher la case à cocher appropriée, etc. la ligne de commande, et le programme fait ce que je veux en moins de temps. Ainsi, alors que les interfaces graphiques sont beaucoup plus simples pour les utilisateurs occasionnels, les utilisateurs assidus privilégient parfois la CLI.
Phil
15
"Le développement de programmes CLI pour que les utilisateurs puissent travailler directement avec eux est considéré comme un retour en arrière et avec raison" non, ce n’est pas si simple, raison pour laquelle toute application graphique suffisamment avancée incorpore un moteur de script avec son propre CLI
jk.
11
@ MasonWheeler: Je pense que vous manquez le point de jk. Lorsqu'une interface graphique devient compliquée, les utilisateurs férus de technologie préfèreront souvent utiliser un moteur de script CLI même pour une tâche ponctuelle . Ce qui est absolument "des utilisateurs qui travaillent directement avec lui".
Ruakh
8
-1 sur "le développement de programmes CLI pour que les utilisateurs puissent travailler directement est considéré comme un retour en arrière, et avec raison", cela dépend totalement de l'application. Souvent, en tant qu'utilisateur, je dois utiliser un programme pour s'exécuter sur une machine dépourvue de GUI ou de moniteur. J'ai vraiment besoin d'un CLI alors!
Mars
35

L'art de la programmation Unix d' Eric Raymond est l'œuvre canonique de votre argumentation. Je ne vais pas essayer de condenser son excellent livre en quelques paragraphes. Cependant, gardez à l'esprit que cet argument s'applique principalement aux programmeurs, aux administrateurs automatisant des tâches à l'aide de scripts ou aux utilisateurs expérimentés de logiciels hautement techniques tels que la CAO.

Même avec des utilisateurs très techniques, vous devez déterminer quels chapeaux ils portent à l’époque. Par exemple, j'écris des logiciels embarqués pour des équipements de réseau de vie. Nos produits ont tous à la fois une interface de ligne de commande et une interface utilisateur graphique, mais les développeurs préfèrent presque universellement la CLI en raison de sa flexibilité, de sa scriptabilité, de sa disponibilité, de sa vitesse, etc.

Cependant, ce même groupe de développeurs préfère de manière prépondérante l'interface graphique de notre logiciel de contrôle de version, même si sa CLI est plus puissante et est prise en charge et documentée, ainsi que l'interface graphique. La différence est que nous sommes les utilisateurs finaux du logiciel de contrôle de version, et non les administrateurs ou les développeurs.

Alors, réfléchissez bien aux rôles de vos utilisateurs lorsqu'ils utilisent vos utilitaires et planifiez l'interface utilisateur en conséquence. Si votre patron le mentionne, il est probablement nécessaire d'améliorer au minimum la documentation et / ou la formation sur la CLI. Si vous indiquez constamment aux utilisateurs qu'une fonctionnalité n'est disponible dans la CLI que lorsqu'ils l'attendent pour l'interface graphique, vous devrez probablement repenser vos priorités de développement, en prenant mieux en compte les besoins de vos utilisateurs.

Karl Bielefeldt
la source
16

Ce n'est pas seulement Unix qui est piloté par des programmes en ligne de commande. Microsoft se dirige également dans cette direction.

Microsoft pousse PowerShell depuis un certain temps déjà. Tous les logiciels de leur serveur actuel (Exchange, SharePoint, Server 2012, System Center, etc.) peuvent être entièrement contrôlés via la ligne de commande PowerShell. Et PowerShell s'appuie sur de petites fonctions qui effectuent bien une tâche et dirigent les données vers la suivante (bien que les objets soient acheminés au lieu de texte uniquement).

La plupart des interfaces graphiques de ces programmes sont simplement une interface avec les commandes PowerShell. Plusieurs vous indiquent même les commandes à exécuter pour faciliter l’écriture de scripts. Tout ce que vous pouvez faire à partir de l'interface graphique, vous pouvez le faire à partir de PowerShell. L'inverse n'est pas vrai: de nombreuses fonctions ne sont exposées que dans PowerShell.

Donc, si * nix l’a toujours fait et que Microsoft se dirige de cette façon… ne me semble pas très en arrière!

Subvention
la source
5
Juste pour ajouter à cela: Microsoft repousse grandement l’interface utilisateur graphique sur les serveurs . Ils veulent que tout le monde utilise Server Core - pas d’interface graphique, point final. Si vous pouvez créer un script pour un ensemble de tâches sur une machine, vous pouvez le faire pour toute l'entreprise. Bonne chance pour le faire avec une interface graphique. Jeffrey Snover (architecte principal pour Windows) a donné une bonne interview sur le sujet.
alroc
4
"Windows" ne se dirige pas de cette façon; Windows Server est. Un serveur est conçu pour fonctionner en tant que système automatisé avec une interaction humaine minimale, ce qui est donc logique. Mais cela ne se produira jamais sur les parties de l'OS confrontées à l'utilisateur.
Mason Wheeler
3
De plus, Mac OS X est passé d'une interface graphique pure à une architecture * nix avec un accent particulier sur les scripts de ligne de commande. Par conséquent, je dirais que Microsoft et Apple se dirigent tous deux vers plus de CLI.
Brandon
1
+1 Je devais expliquer aux utilisateurs du niveau C comment "Windows" revenait au texte. Cela a du sens: chaque action peut être scriptée, testée et déployée sur des milliers de serveurs plutôt que de se connecter à chaque boîte de dialogue et d'essayer de reproduire avec précision 200 clics de souris. Le PO devrait présenter ses compétences en tant que script / automatisation plutôt qu'en tant que CLI. IIRC Windows offre un support powershell à partir de XP. C'est génial d'installer des pré-requêtes avec un script au lieu de cliquer beaucoup.
Jqa
Vous avez raison, mais gardez à l'esprit que pour la plupart des utilisateurs (stupides), les interfaces utilisateur graphiques sont la seule chose qu'ils connaissent et voient ... c'est particulièrement vrai si vous considérez le fait que l'interface utilisateur est beaucoup plus ancienne d'entre eux ...
Radu Murzea
4

Je ne dirais certainement pas que c'est une mauvaise chose. La bonne chose à propos des programmes CLI est que lors de leur mise en œuvre, vous pouvez avoir une portée très limitée. Par exemple, si je veux écrire un catclone ou "un programme pour imprimer le contenu d'un fichier à l'écran", c'est très faisable avec CLI.

Cependant, si vous n'utilisiez pas la CLI, eh bien, vous auriez un programme de base avec une interface graphique qui afficherait du texte. Mais vous devrez également associer l'ouverture d'un dialogue de fichier à la connexion de celui-ci .. mais quelqu'un voudra aussi pouvoir modifier le texte et le sauvegarder ailleurs ..

Scope Scope est ridicule avec les applications GUI. Il est extrêmement facile d'éviter les applications CLI. "Vous souhaitez modifier le fichier, puis le sauvegarder à nouveau? cat foo > ed > bar" Avec les applications CLI, il est simple pour vos utilisateurs (pas vous, le développeur) de le combiner avec d'autres outils.

Cela dit, les programmes de la CLI commencent à être considérés comme "à l'envers". En effet, de nos jours, de nombreuses applications sont mises au point sur des marchés où les utilisateurs qui associent votre outil à d’autres outils sont pratiquement impossibles. Je ne parlerai pas de cela ici, mais j’ai écrit un billet de blog expliquant comment «les marchés imposent une mentalité de maître absolu», ce qui est tout le contraire d’une application CLI bien conçue (faire une chose et bien la faire )

Earlz
la source
4

L'interface graphique et l'interface de ligne de commande ont toutes deux leur place. L'interface graphique est idéale pour permettre à un utilisateur d'effectuer certaines opérations prédéfinies rapidement. La CLI est pour quand vous voulez faire des choses que l'interface graphique ne vous permet pas de faire. La CLI est généralement plus puissante et plus difficile à utiliser.

Un bon outil de la CLI permet à l'utilisateur de faire des choses auxquelles l'auteur de l'outil n'a jamais pensé. Un exemple est la commande UNIX 'find'. Cette commande:

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

trouve dans le répertoire en cours (mais limité à 5 niveaux inférieurs) les fichiers dont le nom commence par 'xyzzy' et qui ont été modifiés il y a plus de 3 jours, puis les suppriment (note: code non testé). Et c'est un usage assez simple. Vous pouvez utiliser un gestionnaire de fichiers pour faire ce genre de chose, mais cela prendra plus de temps et est sujet à des erreurs. Bien sûr, être plus puissant signifie que la CLI peut être plus facilement mal utilisée et créer des problèmes pour vous-même!

Un bon développeur peut écrire un outil CLI de manière à ce qu’il dispose également d’une interface graphique permettant d’effectuer un ensemble limité d’opérations. L'utilisateur peut commencer par l'interface graphique et apprendre plus tard les complexités de la CLI.

Un bon (long et biaisé (?)) Lu sur le compromis CLI / GUI est à:

http://www.cryptonomicon.com/beginning.html
Rzzzwilson
la source
1
+1, en particulier pour la référence à "Au début était la ligne de commande"
Ben Lee
1

Non, ce n'est pas du tout en arrière.

La "direction" a beaucoup à voir avec notre perspective. Un utilisateur satisfait du chemin actuel menant à des interfaces simples, "one experience all devices", verra l'interface de ligne de commande comme une régression ou une régression. Cela ne correspond pas à leurs attentes générales.

Un programmeur, un administrateur ou un utilisateur expérimenté peut très bien y voir une progression logique des outils en fonction de leur expérience. Beaucoup d'entre eux commencent par utiliser des outils d'interface graphique. Lorsqu'ils souhaitent ou doivent évoluer, ils comprennent rapidement pourquoi la CLI existe et cette progression résonne chez ceux qui construisent davantage d'outils de la CLI.

Paul Ferris l’a mentionné: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Pour moi personnellement, l'idée de syntaxe différencie les deux. Lorsque la syntaxe est quelque peu présente dans une interface graphique, le résultat n'est presque jamais bon et aussi souple que la syntaxe de la CLI bien pensée. Lorsque cela est associé aux canaux et à la redirection, l’interface graphique tombe à plat car elle n’est pas très utile en dehors des cas d’utilisation prévus.

Ma préférence personnelle à cet égard concerne les outils CLI qui offrent une option --gui ou --verbose suffisante pour permettre à un wrapper d’interface graphique d’interagir de manière robuste, y compris des barres d’état et d’autres éléments de base sur lesquels les utilisateurs se tournent vers l’interface graphique.

Bien sûr, le coût de cette opération est essentiellement constitué de deux programmes dont l’un est plutôt inutile sans l’autre, mais le principal avantage est d’incorporer un ou plusieurs grands outils de la CLI dans une interface graphique personnalisée sans modification desdits outils de la CLI. Le plus souvent, ceci est uniquement fait pour offrir une option d'interface graphique sur une CLI particulière, mais l'idée de piloter plusieurs outils avec une interface graphique orientée "processus" ou "cas d'utilisation" peut produire des résultats similaires à ceux de piping, redirection et script pour ce cas d'utilisation. en le rendant disponible aux personnes qui ne réaliseraient pas ces opérations assez régulièrement pour atteindre la maîtrise sans pour autant empêcher les utilisateurs de l'interface de ligne de commande.

J'ai rencontré cette approche sur SGI IRIX et ça m'a vraiment plu. Je me suis retrouvé à utiliser l'interface graphique ou la ligne de commande selon les besoins, et la bonne chose à faire était de savoir exactement ce que faisaient les boutons fantaisie.

Là où il y a beaucoup d'environnements d'exploitation différents, les interfaces graphiques peuvent différer considérablement sans que l'outil CLI soit affecté.

Je le vois aujourd'hui sous Linux avec des outils tels que les outils de disque / système de fichiers, où l'interface graphique peut ajouter beaucoup de valeur même aux utilisateurs familiers de la CLI.

Dans le cas de systèmes de fichiers / disques / périphériques connus, désactiver l'interface de ligne de commande n'est pas compliqué et il peut être scripté, bien sûr. Les erreurs peuvent cependant être douloureuses.

Là où ceux-ci peuvent ne pas être connus, ou peut-être que l'exécution des opérations n'est pas assez régulière pour rester solide et sans erreur, l'exécution de l'interface graphique fournit un environnement facilement vérifiable, des opérations chaînées et exécutées en toute confiance, aucun script requis.

utilisateur94936
la source