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

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.

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.

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.

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.

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!

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 )

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

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.