Was halten Sie davon, zuerst für die Befehlszeile zu entwickeln?

https://stackoverflow.com/questions/18984

09-06-2019
|

Frage

Was halten Sie davon, zuerst für die Befehlszeile zu entwickeln und dann nachträglich durch einfaches Aufrufen der Befehlszeilenmethoden eine GUI hinzuzufügen?

z.B.

W: odo AddTask „Treffen mit John, bezüglich:Login Peer Review“ „Johns Büro“ „22.08.2008“ „14:00“

Ladungen todo.exe und ruft eine Funktion namens auf AddTask Das führt eine gewisse Validierung durch und wirft das Meeting in eine Datenbank.

Schließlich fügen Sie hierfür einen Bildschirm hinzu:

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

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

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

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

Wenn Sie auf „Senden“ klicken, wird dieselbe AddTask-Funktion aufgerufen.

Ist dies berücksichtigt:

eine gute Möglichkeit zum Codieren
nur für die Neulinge
schrecklich!.

Nachtrag:

Ich bemerke hier einen Trend zu "gemeinsam genutzten Bibliotheken, die sowohl von der GUI als auch von den ausführbaren CLI-Dateien aufgerufen werden". Gibt es einen zwingenden Grund, warum sie getrennt werden müssten, außer vielleicht die Größe der Binärdateien selbst?

Warum nicht einfach dieselbe ausführbare Datei auf unterschiedliche Weise aufrufen:

"todo /G" wenn Sie die vollwertige grafische Oberfläche wünschen
"todo /I" für eine interaktive Eingabeaufforderung innerhalb todo.exe (Skripterstellung usw.)
einfach alt "todo <function>" wenn man nur eine Sache tun und damit fertig sein möchte.

Nachtrag 2:

Es wurde erwähnt, dass „so wie [ich] die Dinge beschrieben habe, jedes Mal, wenn die GUI etwas tun muss, eine ausführbare Datei erstellt werden muss.“

Auch das war nicht meine Absicht.Als ich erwähnte, dass die Beispiel-GUI „the same AddTask Funktion“ meinte ich nicht, dass die GUI jedes Mal das Befehlszeilenprogramm aufrief.Ich stimme zu, das wäre total böse.Ich hatte beabsichtigt (siehe erster Nachtrag), dies alles in einer einzigen ausführbaren Datei zu speichern, da es sich um ein winziges Beispiel handelte, aber ich glaube nicht, dass meine Formulierung eine gemeinsame Bibliothek unbedingt ausschloss.

Außerdem möchte ich Ihnen allen für Ihren Beitrag danken.Das ist etwas, das mir immer wieder in den Sinn kommt, und ich schätze die Weisheit Ihrer Erfahrung.

Lösung

Ich würde eine Bibliothek mit einer Befehlszeilenanwendung erstellen, die darauf verweist.Anschließend können Sie eine GUI erstellen, die auf dieselbe Bibliothek verweist.Der Aufruf einer Befehlszeile über eine GUI erzeugt externe Prozesse für jeden Befehl und stört das Betriebssystem stärker.

Außerdem können Sie mit einer Bibliothek problemlos Unit-Tests für die Funktionalität durchführen.

Aber selbst solange Ihr Funktionscode von Ihrem Befehlszeileninterpreter getrennt ist, können Sie die Quelle einfach für eine GUI wiederverwenden, ohne beide Arten gleichzeitig zum Ausführen einer Operation zu haben.

Andere Tipps

Platzieren Sie die gemeinsam genutzte Funktionalität in einer Bibliothek und schreiben Sie dann eine Befehlszeile und ein GUI-Frontend dafür.Auf diese Weise ist Ihr Ebenenübergang nicht an die Befehlszeile gebunden.

(Außerdem entsteht auf diese Weise ein weiteres Sicherheitsrisiko:Sollte die GUI nicht zuerst sicherstellen müssen, dass die RICHTIGE todo.exe aufgerufen wird?)

Joel schrieb vor ein paar Jahren einen Artikel, in dem er diese Entwicklung („Unix-Stil“) mit der GUI-First-Methode („Windows-Stil“) vergleicht.Er hat es genannt Bikulturalismus.

Ich denke, unter Windows wird es normal werden (sofern dies nicht bereits geschehen ist), Ihre Logik in .NET-Assemblys zu packen, auf die Sie dann sowohl über eine GUI als auch über einen PowerShell-Anbieter zugreifen können.Auf diese Weise erhalten Sie das Beste aus beiden Welten.

Meine Technik, um zunächst die Backend-Funktionalität zu programmieren, ohne dass eine explizite Benutzeroberfläche erforderlich ist (insbesondere, wenn die Benutzeroberfläche noch nicht meine Aufgabe ist, z. B. wenn ich eine Webanwendung entwerfe, die sich noch in der Entwurfsphase befindet), besteht darin, Komponententests zu schreiben.

Auf diese Weise muss ich nicht einmal eine Konsolenanwendung schreiben, um die Ausgabe meines Backend-Codes zu simulieren – alles ist in den Tests enthalten, und im Gegensatz zu Ihrer Konsolen-App muss ich den Code für die Tests nicht wegwerfen, weil er immer noch vorhanden ist sind später nützlich.

Ich denke, es hängt davon ab, welche Art von Anwendung Sie entwickeln.Durch das Entwerfen für die Befehlszeile gelangen Sie schnell zu dem, was Alan Cooper als „Implementierungsmodell“ bezeichnet Die Insassen leiten die Anstalt.Das Ergebnis ist eine Benutzeroberfläche, die nicht intuitiv und schwierig zu bedienen ist.

37signals empfiehlt außerdem, zunächst Ihre Benutzeroberfläche zu entwerfen Real werden.Denken Sie im Grunde bei den meisten Anwendungen an die Benutzeroberfläche Ist das Programm.Der Back-End-Code dient lediglich der Unterstützung.

Es ist wahrscheinlich besser, zunächst mit einer Befehlszeile zu beginnen, um sicherzustellen, dass die Funktionalität korrekt ist.Wenn Ihre Hauptbenutzer die Befehlszeile nicht verwenden können (oder wollen), können Sie zusätzlich zu Ihrer Arbeit eine GUI hinzufügen.

Dadurch eignet sich Ihre App besser für die Skripterstellung und der Vorabaufwand wird begrenzt Fahrradabwurf So kommen Sie schneller zur eigentlichen Lösung.

Wenn Sie vorhaben, Ihre Befehlszeilenversion Ihrer App beizubehalten, sehe ich darin kein Problem – es ist keine Zeitverschwendung.Am Ende müssen Sie immer noch die Hauptfunktionalität Ihrer App für die Befehlszeile programmieren und haben somit einen großen Teil der Arbeit erledigt.

Ich sehe diese Arbeitsweise nicht als Hindernis für eine schöne Benutzeroberfläche an – Sie haben immer noch die Zeit, eine hinzuzufügen und sie nutzbar zu machen usw.

Ich denke, diese Arbeitsweise würde nur dann wirklich funktionieren, wenn Sie beabsichtigen, dass Ihre fertige App sowohl über Befehlszeilen- als auch über GUI-Varianten verfügt.Es ist ganz einfach, eine Benutzeroberfläche zu simulieren, Ihre Funktionalität darin zu integrieren und die Benutzeroberfläche später zu verschönern.

Stimme Stu zu:Ihre Basisfunktionalität sollte sich in einer Bibliothek befinden, die über die Befehlszeile und den GUI-Code aufgerufen wird.Das Aufrufen der ausführbaren Datei über die Benutzeroberfläche verursacht zur Laufzeit unnötigen Mehraufwand.

@jcarrascal

Ich verstehe nicht, warum dies die GUI „schlecht“ machen muss?
Meiner Meinung nach würde es Sie dazu zwingen, darüber nachzudenken, was die „Geschäfts“-Logik tatsächlich leisten muss, ohne sich zu viele Gedanken darüber zu machen, ob die Dinge schön sind.Sobald Sie wissen, was es tun soll/kann, können Sie Ihre Schnittstelle auf die sinnvollste Weise darauf aufbauen.

Randnotiz:Ich möchte kein separates Thema eröffnen, aber wie gehen Sie am besten mit Antworten/Kommentaren zu Ihren Fragen um?Ich habe sowohl darüber nachgedacht als auch die Frage selbst bearbeitet.

Ich habe genau das mit einem Tool gemacht, das ich geschrieben habe, und es hat großartig funktioniert.Das Endergebnis ist ein skriptfähiges Tool, das auch über eine GUI verwendet werden kann.

Ich stimme der Meinung zu, dass Sie sicherstellen sollten, dass die GUI einfach und intuitiv zu bedienen ist, daher könnte es sinnvoll sein, sogar beide gleichzeitig zu entwickeln ...eine kleine Befehlszeilenfunktion, gefolgt von einem GUI-Wrapper, um sicherzustellen, dass Sie Dinge intuitiv erledigen.

Wenn man beide gleichermaßen umsetzt, entsteht eine App, die automatisiert genutzt werden kann, was meiner Meinung nach für Power-User sehr leistungsstark ist.

Normalerweise beginne ich mit einer Klassenbibliothek und einer separaten, wirklich beschissenen und einfachen GUI.Da die Befehlszeile das Parsen der Befehlszeile beinhaltet, habe ich das Gefühl, dass ich viel unnötigen Mehraufwand hinzufüge.

Als Bonus ergibt sich dadurch ein MVC-ähnlicher Ansatz, da sich der gesamte „echte“ Code in einer Klassenbibliothek befindet.Zu einem späteren Zeitpunkt ist natürlich auch das Refactoring der Bibliothek zusammen mit einer echten GUI in eine EXE-Datei eine Option.

Wenn Sie Ihre Entwicklung richtig machen, sollte es relativ einfach sein, später im Projekt auf eine GUI umzusteigen.Das Problem ist, dass es ziemlich schwierig ist, es richtig zu machen.

Irgendwie hängt es von Ihrem Ziel für das Programm ab, aber ja, ich mache das von Zeit zu Zeit – es ist schneller zu programmieren, einfacher zu debuggen und einfacher, schnelle und schmutzige Testfälle dafür zu schreiben.Und solange ich meinen Code richtig strukturiere, kann ich später ohne großen Aufwand eine grafische Benutzeroberfläche erstellen.

An diejenigen, die behaupten, dass diese Technik zu schrecklichen, unbrauchbaren Benutzeroberflächen führen wird:Sie haben Recht.Das Schreiben eines Befehlszeilenprogramms ist eine schreckliche Art, eine GUI zu entwerfen.Beachten Sie, dass jeder da draußen darüber nachdenkt, eine solche Benutzeroberfläche zu schreiben ist nicht ein CLUI – erstellen Sie keinen Prototyp als CLUI.

Aber, wenn Sie neuen Code schreiben, der selbst nicht von einer Benutzeroberfläche abhängt, dann mach es.

Ein besserer Ansatz könnte darin bestehen, die Logik als Bibliothek mit einer gut definierten API und in der Entwicklungsphase ohne Schnittstelle (oder einer fest codierten Schnittstelle) zu entwickeln, dann können Sie die CLI oder GUI später erstellen

Ich würde das aus mehreren Gründen nicht tun.

Design:

Eine GUI und eine CLI sind zwei verschiedene Schnittstellen, die für den Zugriff auf eine zugrunde liegende Implementierung verwendet werden.Sie werden im Allgemeinen für unterschiedliche Zwecke verwendet (GUI ist für einen Live-Benutzer, CLI wird normalerweise über Skripting aufgerufen) und können oft unterschiedliche Anforderungen haben.Beides miteinander zu verknüpfen, ist keine kluge Entscheidung und wird Ihnen später zwangsläufig Ärger bereiten.

Leistung:

So wie Sie es beschrieben haben, müssen Sie jedes Mal eine ausführbare Datei erzeugen, wenn die GUI etwas tun muss.Das ist einfach hässlich.

Der richtige Weg, dies zu tun, besteht darin, die Implementierung in einer Bibliothek abzulegen, die sowohl von der CLI als auch von der GUI aufgerufen wird.

John Gruber hatte einen guten Beitrag über das Konzept, einem Programm eine GUI hinzuzufügen, die nicht dafür konzipiert ist: Ronco Spray-On-Benutzerfreundlichkeit

Zusammenfassung:Es funktioniert nicht.Wenn die Benutzerfreundlichkeit nicht von Anfang an in eine Anwendung integriert ist, ist das spätere Hinzufügen mehr Arbeit, als irgendjemand bereit ist zu leisten.

@Maudite

Die Befehlszeilen-App überprüft die Parameter im Voraus, die GUI jedoch nicht – sie überprüft sie aber trotzdem Dasselbe Parameter und deren Eingabe in einige generische Worker-Funktionen.

Immer noch das gleiche Ziel.Ich sehe keinen Einfluss der Befehlszeilenversion auf die Qualität der GUI-Version.

Erstellen Sie ein Programm, das Sie als Webdienst bereitstellen.Führen Sie dann die GUI und die Befehlszeile aus, um denselben Webdienst aufzurufen.Mit diesem Ansatz können Sie auch eine Web-GUI erstellen und die Funktionalität als SaaS für Extranet-Partner bereitstellen und/oder die Geschäftslogik besser sichern.

Dadurch kann Ihr Programm auch einfacher an einer SOA-Umgebung teilnehmen.

Übertreiben Sie es beim Webservice nicht.Mache Yaml oder XML-RPC.Halte es einfach.

Zusätzlich zu was Stu Mit einer gemeinsam genutzten Bibliothek können Sie diese auch aus Webanwendungen verwenden.Oder sogar von einem IDE-Plugin.

Es gibt mehrere Gründe, warum es keine gute Idee ist, dies auf diese Weise zu tun.Viele davon wurden erwähnt, daher bleibe ich nur bei einem bestimmten Punkt.

Befehlszeilentools sind im Gegensatz zu GUIs normalerweise überhaupt nicht interaktiv.Das ist ein grundlegender Unterschied.Dies ist beispielsweise bei lang andauernden Aufgaben schmerzhaft.

Ihr Befehlszeilentool gibt im besten Fall irgendeine Art von Fortschrittsinformation aus – Zeilenumbrüche, einen Fortschrittsbalken in Textform, eine Menge Ausgaben, ...Jegliche Art von Fehlern kann nur auf der Konsole ausgegeben werden.

Nun möchten Sie eine grafische Benutzeroberfläche darüber legen. Was tun Sie?Die Ausgabe Ihres Befehlszeilentools mit langer Laufzeit analysieren?In dieser Ausgabe nach WARNUNG und FEHLER suchen, um ein Dialogfeld aufzurufen?

Bestenfalls zeigen die meisten auf diese Weise aufgebauten Benutzeroberflächen eine pulsierende Besetztleiste an, solange der Befehl ausgeführt wird, und zeigen Ihnen dann einen Erfolgs- oder Fehlerdialog an, wenn der Befehl beendet wird.Leider sind viele UNIX-GUI-Programme auf diese Weise zusammengewürfelt, was zu einer schrecklichen Benutzererfahrung führt.

Die meisten Antworten hier haben Recht, wenn sie sagen, dass Sie wahrscheinlich die eigentliche Funktionalität Ihres Programms in eine Bibliothek abstrahieren und dann gleichzeitig eine Befehlszeilenschnittstelle und die GUI dafür schreiben sollten.Ihre gesamte Geschäftslogik sollte sich in Ihrer Bibliothek befinden, und jede Benutzeroberfläche (ja, eine Befehlszeile ist eine Benutzeroberfläche) sollte nur das tun, was für die Schnittstelle zwischen Ihrer Geschäftslogik und Ihrer Benutzeroberfläche erforderlich ist.

Eine Befehlszeile ist eine zu schlechte Benutzeroberfläche, um sicherzustellen, dass Sie Ihre Bibliothek gut genug für die spätere Verwendung mit der Benutzeroberfläche entwickeln.Sie sollten von Anfang an mit beidem beginnen oder mit der GUI-Programmierung beginnen.Es ist einfach, einer für eine GUI entwickelten Bibliothek eine Befehlszeilenschnittstelle hinzuzufügen, aber andersherum ist es viel schwieriger, gerade wegen all der interaktiven Funktionen, die die GUI benötigt (Berichterstellung, Fortschritt, Fehlerdialoge, i18n, ...) )

Befehlszeilentools generieren weniger Ereignisse als GUI-Apps und überprüfen normalerweise alle Parameter, bevor sie beginnen.Dadurch wird Ihre GUI eingeschränkt, da es für eine GUI sinnvoller sein könnte, nach den Parametern zu fragen, während Ihr Programm läuft oder danach.

Wenn Ihnen die GUI egal ist, machen Sie sich darüber keine Sorgen.Wenn das Endergebnis eine GUI sein soll, erstellen Sie zuerst die GUI und dann die Befehlszeilenversion.Oder Sie könnten an beiden gleichzeitig arbeiten.

--Massive Bearbeitung--

Nachdem ich einige Zeit mit meinem aktuellen Projekt verbracht habe, habe ich das Gefühl, dass sich der Kreis meiner vorherigen Antwort schließt.Ich denke, es ist besser, zuerst die Befehlszeile zu erstellen und dann eine GUI darauf zu packen.Wenn nötig, kann man meiner Meinung nach im Nachhinein eine tolle GUI erstellen.Wenn Sie zuerst die Befehlszeile ausführen, erhalten Sie zuerst alle Argumente, sodass es bei der Ausführung der Benutzeroberfläche/UX keine Überraschungen gibt (bis sich die Anforderungen ändern).

Das ist genau eine meiner wichtigsten Erkenntnisse zum Thema Codierung und ich wünschte, mehr Menschen würden diesen Ansatz verfolgen.

Nur eine kleine Klarstellung:Die GUI sollte kein Wrapper um die Befehlszeile sein.Stattdessen sollte man in der Lage sein, den Kern des Programms entweder über eine GUI oder eine Befehlszeile zu steuern.Zumindest am Anfang und nur grundlegende Operationen.

Wann ist das eine tolle Idee?

Wenn Sie sicherstellen möchten, dass Ihre Domänenimplementierung unabhängig vom GUI-Framework ist.Sie möchten codieren um der Rahmen nicht hinein der Rahmen

Wann ist das eine schlechte Idee?

Wenn Sie sicher sind, dass Ihr Framework niemals sterben wird

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow