Que pensez-vous de l'élaboration de la ligne de commande en premier?

https://stackoverflow.com/questions/18984

09-06-2019
|

Question

Quelles sont vos opinions sur le développement de la ligne de commande d'abord, puis l'ajout d'une interface graphique après le fait en appelant simplement la ligne de commande de méthodes?

par exemple.

W:\ todo AddTask "rencontre avec John, ré:connexion peer review", "Jean" d'office "2008-08-22" "14:00"

charges todo.exe et appelle une fonction appelée AddTask qui ne la validation de certains et jette à la réunion dans une base de données.

Finalement, vous ajoutez dans un écran de ceci:

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

Lorsque vous cliquez sur envoyer, il appelle la même AddTask fonction.

Est-ce considéré comme:

un bon moyen de code
juste pour les débutants
horrible!.

Addendum:

J'ai remarqué une tendance ici pour "bibliothèque partagée appelé par le GUI et CLI exécutables." Est-il une raison impérieuse, ils devront être séparés, autres que peut-être la taille des binaires eux-mêmes?

Pourquoi ne pas simplement appeler le même exécutable de différentes façons:

"todo /G" lorsque vous souhaitez que le plein sur l'interface graphique
"todo /I" pour une invite de commandes au sein de todo.exe (scripts, etc)
le bon vieux "todo <function>" lorsque vous voulez juste faire une chose et être fait avec elle.

Addendum 2:

Il a été signalé que "la façon dont [j'ai] décrit les choses, vous [aurait] besoin de frayer un exécutable à chaque fois que le GUI doit faire quelque chose."

Encore une fois, ce n'était pas mon intention.Quand j'ai mentionné que l'exemple de l'interface graphique appelée "la même AddTask fonction," je ne voulais pas dire le GUI appelle le programme en ligne de commande à chaque fois.Je suis d'accord que ce serait totalement méchant.J'avais prévu (voir additif) à ce que tout être organisé en un seul exécutable, puisque c'était un tout petit exemple, mais je ne pense pas que mon phrasé nécessairement empêché une bibliothèque partagée.

Aussi, je tiens à tous vous remercier pour vos commentaires.C'est quelque chose qui continue à sauter en arrière dans mon esprit et j'apprécie la sagesse de votre expérience.

La solution

J'irais avec la construction d'une bibliothèque avec une application en ligne de commande que des liens vers elle.Par la suite, vous pouvez créer une interface graphique qui renvoie à la même bibliothèque.L'appel d'une ligne de commande à partir d'une interface graphique engendre un processus externe, pour chaque commande et qui est plus dérangeant pour le système d'exploitation.

Aussi, avec une bibliothèque, vous pouvez facilement faire des tests unitaires pour la fonctionnalité.

Mais même en tant que votre code fonctionnel est séparé de votre interpréteur de ligne de commande, vous pouvez ré-utiliser la source d'une interface graphique sans avoir les deux types à la fois pour effectuer une opération.

Autres conseils

Mettre l'partagé fonctionnalité dans une bibliothèque, puis d'écrire une ligne de commande et une interface graphique avant la fin pour elle.De cette façon, votre couche de transition n'est pas reliée à la ligne de commande.

(Aussi, de cette façon, ajoute un autre problème de sécurité:ne pas le GUI d'abord assurez-vous que c'est la bonne todo.exe qui est appelé?)

Joel a écrit un article pour le comparer ("unix") le développement de l'interface graphique de la première ("Windows") méthode quelques années en arrière.Il l'a appelé Le biculturalisme.

Je pense que sur Windows, ça deviendra normal (si ce n'est pas déjà fait) pour envelopper votre logique dans .NET assemblées, que vous pouvez ensuite accéder à partir d'une interface graphique et d'un fournisseur PowerShell.De cette façon, vous obtenez le meilleur des deux mondes.

Ma technique pour la programmation backend fonctionnalité première, sans avoir la nécessité expresse de l'INTERFACE utilisateur (en particulier lorsque l'INTERFACE utilisateur n'est pas mon job, par exemple, je suis desigining une application web qui est encore dans la phase de conception) est d'écrire des tests unitaires.

De cette façon, je n'ai même pas besoin d'écrire une application console pour se moquer de la sortie de mon backend code -- c'est dans les tests, et à la différence de votre application console je n'ai pas de jeter le code pour les tests plus loin parce qu'ils sont encore utiles plus tard.

Je pense que cela dépend du type d'application que vous développez.La conception de la ligne de commande vous met sur la voie rapide à ce qu'Alan Cooper se réfère en tant que "Modèle de mise en Œuvre" dans Les Détenus sont en cours d'Exécution de l'Asile.Le résultat est une interface utilisateur qui n'est pas intuitif et difficile à utiliser.

37signals préconise également la conception de votre interface utilisateur dans Getting Real.Rappelez-vous, à toutes fins et intentions, dans la majorité des applications, l'interface utilisateur est le programme.Le code principal est juste là pour le soutenir.

Il est probablement préférable de commencer avec une ligne de commande pour s'assurer que vous avez la fonctionnalité correcte.Si votre principale les utilisateurs ne peuvent pas (ou ne veut pas) utiliser la ligne de commande vous pouvez ensuite ajouter une interface graphique sur le dessus de votre travail.

Cela rendra votre application mieux adapté pour l'écriture de scripts, ainsi que de limiter le montant de l'avance Bikeshedding de sorte que vous pouvez obtenir à la solution réelle plus rapide.

Si vous envisagez de garder votre version de ligne de commande de votre application puis je ne vois pas le problème avec cette façon de faire - ce n'est pas du temps perdu.Vous aurez toujours la fin du codage de la principale fonctionnalité de votre application pour la ligne de commande et vous aurez donc une grande partie du travail accompli.

Je ne vois pas en travaillant de cette façon, comme étant un obstacle à une belle INTERFACE utilisateur - vous avez encore le temps d'ajouter un et le faire est utilisable etc.

Je suppose que cette manière de travailler n'est vraiment travailler si vous avez l'intention de votre application à la fois de la ligne de commande et interface graphique variantes.Il est assez facile de se moquer d'une INTERFACE utilisateur et de construire votre fonctionnalité que puis embellir l'INTERFACE utilisateur plus tard.

D'accord avec Stu:votre fonctionnalité de base doivent être dans une bibliothèque qui est appelée à partir de la ligne de commande et le code de la GUI.L'appel de l'exécutable à partir de l'INTERFACE utilisateur est une surcharge inutile au moment de l'exécution.

@jcarrascal

Je ne vois pas pourquoi il en a à faire de l'interface "mauvaise?"
Ma pensée est qu'elle pourrait vous forcer à penser à ce que le "métier" a réellement besoin pour accomplir, sans trop se préoccuper des choses jolies.Une fois que vous savez ce qu'il doit/peut faire, vous pouvez construire votre interface autour de quelque manière que ce soit fait le plus de sens.

Note de côté:Ne pas commencer un sujet distinct, mais quel est le meilleur moyen d'aborder réponses/commentaires à vos questions?J'ai considéré les deux de ce, et la modification de la question elle-même.

J'ai fait exactement ce sur un outil que j'ai écrit, et il a travaillé beaucoup.Le résultat final est un scriptable outil qui peut également être utilisé via une interface graphique.

Je suis d'accord avec le sentiment que vous devez vous assurer que l'interface graphique est simple et intuitif à utiliser, de sorte qu'il pourrait être sage à même de développer les deux en même temps...un peu de ligne de commande de fonction, suivi par une interface graphique wrapper pour vous assurer de faire les choses de manière intuitive.

Si vous êtes fidèle à la mise en œuvre à la fois aussi, le résultat est une application qui peut être utilisé de manière automatisée, ce qui je pense est très puissant pour les utilisateurs de puissance.

J'ai l'habitude de commencer avec une classe et d'une bibliothèque séparée, vraiment merdique et de base de l'interface graphique.Comme la Ligne de Commande implique l'analyse de la Ligne de Commande, je me sens comme je suis en ajoutant beaucoup de surcharge inutile.

Comme un Bonus, ce qui donne un MVC-comme approche, comme tout le "vrai" code se trouve dans une Bibliothèque de Classe.Bien sûr, à un stade ultérieur, le Refactoring, la bibliothèque avec une vraie interface graphique dans un fichier EXE est également une option.

Si vous faites votre développement à droite, alors il devrait être relativement facile de passer à une interface graphique plus tard dans le projet.Le problème est qu'il est un peu difficile à obtenir de droit.

Kinda dépend de votre objectif pour le programme, mais oui je le fais de temps en temps - c'est plus rapide de code, plus facile à déboguer, et plus facile à écrire "rapide et sale" des cas de test pour.Et tant que je structure mon code correctement, je peux revenir en arrière et de point d'amure sur une interface graphique plus tard sans trop de travail.

Pour ceux qui suggèrent que cette technique aura pour résultat horrible, inutilisable Isu:Vous avez raison.L'écriture d'un utilitaire de ligne de commande est d'une terrible façon de concevoir une interface graphique.Prendre note, tout le monde la pensée de l'écriture d'une INTERFACE n'est-ce pas un CLUI - ne pas le prototype comme CLUI.

Mais, si vous êtes en train de rédiger le nouveau code qui n'est pas elle-même dépend d'une INTERFACE utilisateur, puis aller pour elle.

Une meilleure approche serait de développer la logique comme une lib avec une API et, au dev stade, aucune interface (ou une codés en dur interface), vous pouvez alors wright l'interface CLI ou GUI plus tard

Je ne ferais pas cela pour un couple de raisons.

Conception:

Une interface graphique et une interface CLI sont deux interfaces différentes utilisées pour accéder à un sous-jacent de la mise en œuvre.Ils sont généralement utilisés à des fins différentes (GUI est pour un utilisateur live, CLI est généralement accessible par le script) et ont souvent des besoins différents.Couplage des deux ensemble, c'est pas un choix judicieux et est lié à vous causer des ennuis en bas de la route.

Performance:

La façon dont vous avez décrit les choses, vous devrez lancer un exécutable à chaque fois que le GUI doit d o quelque chose.C'est tout simplement laid.

La bonne façon de le faire est de mettre la mise en œuvre dans une bibliothèque appelée par les deux CLI et l'interface graphique.

John Gruber a un bon post sur le concept de l'ajout d'une interface graphique pour un programme n'est pas conçu pour une: Ronco Pulvérisation Sur La Facilité D'Utilisation

Résumé:Il ne fonctionne pas.Si la convivialité n'est pas conçu dans une application à partir du début, en ajoutant plus tard, il est plus de travail que n'importe qui est prêt à le faire.

@Maudite

La ligne de commande de l'application va vérifier les paramètres à l'avant et à l'interface graphique ne veut pas le faire, mais ils vont encore être la vérification de la même params et entrer dans certains génériques travailleur fonctions.

Toujours le même objectif.Je ne vois pas la version de ligne de commande qui affectent la qualité de l'interface graphique un.

Faire un programme qui vous exposer comme un service web.puis faire l'interface graphique et ligne de commande pour appeler le même service web.Cette approche permet également de faire une web-gui, et aussi pour fournir la fonctionnalité en mode SaaS à l'extranet partenaires, et/ou de mieux sécuriser la logique métier.

Cela permet également à votre programme est plus facile de participer à un SOA de l'environnement.

Pour le web-service, de ne pas aller par dessus bord.ne yaml ou xml-rpc.Garder les choses simples.

En plus de ce qui Stu dit, avoir une bibliothèque partagée, vous permettra de l'utiliser à partir d'applications web ainsi.Ou même à partir d'un IDE plugin.

Il y a plusieurs raisons pourquoi cette façon de faire n'est pas une bonne idée.Beaucoup d'entre eux ont été mentionnés, donc je vais simplement s'en tenir à un point précis.

Outils de ligne de commande sont généralement pas interactif, tandis que GUI sont.C'est une différence fondamentale.C'est par exemple douloureux pour les longues tâches en cours d'exécution.

Votre outil de ligne de commande permet au mieux d'imprimer une sorte de progrès de l'information - retours à la ligne, le texte de la barre de progression, un tas de sortie, ...Tout type d'erreur, il ne peut que la sortie de la console.

Maintenant, vous voulez lancer une interface graphique sur le dessus de cela, que faites-vous ?Analyser la sortie de ce long-running outil en ligne de commande ?Analyse d'AVERTISSEMENT et d'ERREUR, que la sortie de jeter une boîte de dialogue ?

Au mieux, la plupart de l'INTERFACE utilisateur est construit de cette façon, jetez une pulsation bar bondé aussi longtemps que la commande s'exécute, puis vous montrer une réussite ou de l'échec de dialogue lors de la commande ferme.Malheureusement, c'est la façon dont beaucoup de UNIX GUI programmes sont jetés ensemble, faisant d'elle une terrible expérience de l'utilisateur.

La plupart des repliers voici corriger en disant que vous devriez probablement résumé de la fonctionnalité réelle de votre programme dans une bibliothèque, puis d'écrire une interface de ligne de commande et l'interface graphique en même temps.Toutes vos affaires de la logique devrait être dans votre bibliothèque, et l'INTERFACE utilisateur (oui, une ligne de commande est une INTERFACE utilisateur doit seulement faire ce qui est nécessaire pour assurer l'interface entre une logique d'entreprise et de votre INTERFACE utilisateur.

Une ligne de commande est trop pauvre d'une INTERFACE utilisateur à assurez-vous de développer votre bibliothèque assez bon pour GUI utiliser plus tard.Vous devriez commencer avec les deux à partir de l'obtenir-aller, ou de démarrer avec l'interface de programmation.Il est facile d'ajouter une interface de ligne de commande à une bibliothèque de développement pour une interface graphique, mais il est beaucoup plus difficile dans l'autre sens, justement à cause de toutes les fonctionnalités interactives de l'interface graphique aurez besoin (reporting, les progrès, les boîtes de dialogue d'erreur, i18n, ...)

Outils de ligne de commande de générer moins d'événements, puis les applications à interface graphique et l'habitude de vérifier tous les paramètres avant de commencer.Cela permettra de limiter votre interface graphique car pour une interface graphique, il pourrait faire plus de sens de demander les paramètres que votre programme fonctionne ou par la suite.

Si vous n'avez pas de soins sur l'interface graphique, alors ne vous inquiétez pas à ce sujet.Si le résultat final sera une interface graphique, faire de la gui d'abord, puis de faire la version en ligne de commande.Ou vous pourriez travailler sur les deux en même temps.

--Massive edit--

Après avoir passé quelques temps sur mon projet actuel, je me sens comme si j'ai fait un cercle complet de ma précédente réponse.Je pense qu'il est préférable de faire de la ligne de commande d'abord, puis les envelopper d'une interface graphique sur elle.Si vous avez besoin, je pense que vous pouvez faire une grande interface graphique par la suite.En procédant de la ligne de commande tout d'abord, vous bénéficiez de tous les arguments de bas en premier donc il n'y a pas de surprises (jusqu'à ce que les exigences en matière de changement) lorsque vous faites l'UI/UX.

C'est exactement l'une de mes plus importantes réalisations sur le codage et je souhaite que plus de gens prennent une telle approche.

Juste une petite précision:L'interface graphique ne doit pas être un wrapper autour de la ligne de commande.Au lieu de cela on devrait être capable de conduire le noyau du programme à partir d'une interface graphique ou en ligne de commande.Au moins au début et à la base des opérations.

Quand est-ce une bonne idée?

Lorsque vous voulez vous assurer que votre domaine de la mise en œuvre est indépendante de la GUI cadre.Vous souhaitez code autour de le cadre non en le cadre

Quand est-ce une mauvaise idée?

Lorsque vous êtes sûr que votre cadre ne mourra jamais

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow