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

Question

Was sind Ihre Meinungen über die Entwicklung für die Befehlszeile zuerst, dann fügen Sie eine GUI nach, indem Sie einfach die Befehlszeilenmethoden aufrufen?

z.

W: \ todo AddTask "Treffen mit John, re: Login peer review" "Johns Büro" "2008-08-22" "14.00 Uhr"

Lasten todo.exe und ruft eine Funktion genannt AddTask, die einige Validierung und löst das Treffen in einer Datenbank.

Schließlich fügen Sie in einem Bildschirm für diese:

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

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, ruft sie die gleiche Funktion AddTask.

wird dies als:

• ein guter Weg,
• nur für die Neulinge zu kodieren
• horrenden !.

Nachtrag: "Shared Library sowohl von der GUI und CLI ausführbaren Dateien namens"

ich einen Trend hier zu bemerken, Gibt es einen zwingenden Grund, warum sie getrennt werden müssten, außer vielleicht die Größe der Binärdateien selbst?

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

• "todo /G" wenn Sie die voll-auf grafische Oberfläche
• "todo /I" für eine interaktive Eingabeaufforderung innerhalbtodo.exe (Scripting, etc)
• plain old wenn Sie nur eine Sache machen und damit fertig sein wollen.

Nachtrag 2:

Es wurde erwähnt, dass „Die Art und Weise [Ich habe] Dinge beschrieben, Er [würde] benötigen, um eine ausführbare Datei, um laichen jedes Mal, wenn die GUI muss, etwas tun“

Auch dies war nicht meine Absicht. Als ich erwähnte, dass die Beispiel-GUI "dieselbe AddTask-Funktion" nannte, meinte ich nicht, dass die GUI jedes Mal das Befehlszeilenprogramm aufgerufen hat. Ich stimme zu, dass das total gemein wäre. Ich hatte beabsichtigt (siehe ersten Nachtrag), dass dies alles in einer einzigen ausführbaren Datei enthalten ist, da es ein winziges Beispiel war, aber ich denke nicht, dass meine Formulierung notwendigerweise eine gemeinsame Bibliothek ausschloss.

Auch ich möchte Ihnen allen für Ihre Eingabe danken. Das ist etwas, das mir immer wieder in den Sinn kommt und ich weiß die Weisheit deiner Erfahrung zu schätzen.

Answer 1

Ich würde mit dem Erstellen einer Bibliothek mit einer Befehlszeilenanwendung gehen, die darauf verweist. Anschließend können Sie eine GUI erstellen, die auf dieselbe Bibliothek verweist. Das Aufrufen einer Befehlszeile von einer GUI erzeugt externe Prozesse für jeden Befehl und ist für das Betriebssystem störender.

Auch mit einer Bibliothek können Sie problemlos Komponententests für die Funktionalität durchführen.

Aber auch wenn Ihr Funktionscode von Ihrem Befehlszeileninterpreter getrennt ist, können Sie die Quelle einfach für eine GUI verwenden, ohne dass die beiden Arten gleichzeitig ausgeführt werden müssen.

Answer 2

Setzen Sie die freigegebene Funktionalität in eine Bibliothek und schreiben Sie eine Befehlszeile und ein GUI-Front-End dafür. Auf diese Weise ist der Ebenenübergang nicht an die Befehlszeile gebunden.

(Auch fügt diese Art und Weise ein anderes Sicherheitsproblem: sollte nicht der GUI müssen zuerst sicherstellen, dass es die richtige todo.exe dass genannt wird?)

Answer 3

Kinda auf Ihr Ziel für das Programm ab, sondern Ja, ich mache das von Zeit zu Zeit - es ist schneller zu programmieren, einfacher zu debuggen und einfacher, schnelle und schmutzige Testfälle zu schreiben. Und solange ich meinen Code richtig strukturiere, kann ich später ohne viel Arbeit auf eine GUI zurückkehren.

Für diejenigen, die darauf hindeuten, dass diese Technik zu schrecklichen, unbrauchbaren UIs führen wird: Sie haben Recht. Das Schreiben eines Befehlszeilendienstprogramms ist eine schreckliche Methode zum Erstellen einer GUI. Beachten Sie, dass alle da draußen denken, eine Benutzeroberfläche zu schreiben, die nicht ein CLUI ist - prototypieren Sie es nicht als CLUI.

Aber, Wenn Sie neuen Code schreiben, der nicht selbst auf eine UI angewiesen ist, dann gehen Sie dafür.

Answer 4

Joel hat vor ein paar Jahren einen Artikel geschrieben, der diese ("Unix-Stil") Entwicklung mit der GUI-Methode ("Windows-Stil") vergleicht. Er nannte es Biculturalism.

Ich denke, unter Windows wird es normal (wenn nicht schon), Ihre Logik in .NET-Assemblies zu verpacken, auf die Sie dann sowohl von einer GUI als auch von einem PowerShell-Provider zugreifen können. Auf diese Weise erhalten Sie das Beste aus beiden Welten.

Answer 5

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

Dadurch wird Ihre App besser geeignet für das Scripting sowie die Begrenzung der Menge von Upfront Bikeshedding, so dass Sie schneller zur eigentlichen Lösung gelangen können.

Answer 6

Wenn Sie beabsichtigen, Ihre Befehlszeilenversion Ihrer App beizubehalten, sehe ich kein Problem damit, es ist keine Zeitverschwendung. Am Ende werden Sie die Hauptfunktionalität Ihrer App für die Befehlszeile kodieren, sodass Sie einen großen Teil der Arbeit erledigt haben.

Ich sehe nicht, auf diese Weise als Arbeits ein Hindernis für eine schöne UI sein - Sie noch die Zeit, der seine Meinung haben und machen verwendbar usw.

ich diese Arbeitsweise erraten würde nur wirklich funktionieren, wenn Sie beabsichtigen, dass Ihre fertige App sowohl Befehlszeilen- als auch GUI-Varianten enthält. Es ist einfach genug, eine Benutzeroberfläche zu überspielen und Ihre Funktionalität darauf aufzubauen und die Benutzeroberfläche später zu verschönern.

Stimmen Sie mit Stu überein: Ihre Basisfunktionalität sollte in einer Bibliothek sein, die über den Befehlszeilen- und GUI-Code aufgerufen wird. Das Aufrufen der ausführbaren Datei über die Benutzeroberfläche ist zur Laufzeit kein unnötiger Overhead.

Answer 7

@jcarrascal

Ich sehe nicht, warum dies der GUI zu machen hat „schlecht?“
Mein Gedanke wäre, dass es Sie zwingen würde, darüber nachzudenken, was die "Geschäfts" -Logik eigentlich erreichen muss, ohne sich zu sehr darum zu kümmern, dass die Dinge schön sind. Sobald Sie wissen, was es tun soll/kann, können Sie Ihr Interface so aufbauen, wie es am sinnvollsten ist.

Seitennotiz: Nicht ein separates Thema zu starten, aber was ist der bevorzugte Weg, Antworten auf/Kommentare zu Ihren Fragen zu beantworten? Ich überlegte beides und bearbeitete die Frage selbst.

Answer 8

Ich denke, es hängt davon ab, welche Art von Anwendung Sie entwickeln. Das Design für die Befehlszeile bringt Sie auf den schnellen Weg zu dem, was Alan Cooper als "Implementierungsmodell" in The Inmates are Running the Asylum bezeichnet. Das Ergebnis ist eine Benutzerschnittstelle, die nicht intuitiv und schwierig zu verwenden ist.

37signals befürwortet auch, Ihre Benutzerschnittstelle zuerst in Getting Real zu entwerfen. Denken Sie daran, dass in den meisten Anwendungen die Benutzeroberfläche das Programm ist. Der Backend-Code ist nur dazu da, um ihn zu unterstützen.

Answer 9

Ich habe genau das auf einem Werkzeug, das ich schrieb, und es hat gut funktioniert. Das Endergebnis ist ein skriptfähiges Tool, das auch über eine GUI verwendet werden kann.

Ich stimme dem Gefühl zu, dass Sie sicherstellen sollten, dass die GUI einfach und intuitiv zu bedienen ist, also könnte es sinnvoll sein, beides gleichzeitig zu entwickeln ... ein kleines Kommandozeilen-Feature gefolgt von einem GUI-Wrapper stellen Sie sicher, dass Sie Dinge intuitiv tun.

Wenn Sie beides gleichermaßen implementieren, ist das Ergebnis eine App, die auf automatisierte Weise verwendet werden kann, was meiner Meinung nach sehr leistungsfähig für Power User ist.

Answer 10

Befehlszeilentools generieren weniger Ereignisse als GUI-Apps und überprüfen normalerweise alle Parameter vor dem Start. Dies wird Ihre Gui begrenzen, denn für ein GUI könnte es sinnvoller sein, nach den Parametern zu fragen, wie Ihr Programm funktioniert oder danach.

Wenn Sie sich nicht um die GUI kümmern, dann machen Sie sich keine Sorgen darüber. Wenn das Endergebnis ein GUI ist, machen Sie zuerst die GUI und dann die Befehlszeilenversion. Oder du könntest gleichzeitig an beiden arbeiten.

--Massive edit--

Nachdem er einige Zeit auf meinem aktuellen Projekt zu verbringen, ich fühle mich, als ob ich den Kreis aus meiner früheren Antwort gekommen. Ich denke, es ist besser, die Befehlszeile zuerst zu machen und dann eine Gui darauf zu wickeln. Wenn du es brauchst, denke ich, dass du danach ein tolles Gui machen kannst. Wenn Sie zuerst die Befehlszeile ausführen, erhalten Sie alle Argumente zuerst herunter, so dass es keine Überraschungen gibt (bis sich die Anforderungen ändern), wenn Sie die UI/UX ausführen.

Answer 11

@Maudite

Die Befehlszeilen App wird params vorne überprüfen und die GUI wird nicht - aber sie werden immer noch die gleichen params werden überprüft und sie in einige generische Arbeiter Funktionen eingeben.

Immer noch das gleiche Ziel. Ich sehe nicht, dass die Befehlszeilenversion die Qualität der GUI beeinflusst.

Answer 12

Meine Technik zum Programmieren der Backend-Funktionalität zuerst, ohne dass ich eine explizite UI benötige (besonders wenn die UI noch nicht meine Aufgabe ist, z. B. eine Webanwendung, die sich noch in der Entwurfsphase befindet) Unit-Tests schreiben.

So muss ich nicht einmal eine Konsolenanwendung schreiben, um die Ausgabe meines Backend-Codes zu verspotten - es ist alles in den Tests, und im Gegensatz zu Ihrer Konsolenanwendung muss ich den Code für die Tests nicht werfen weg, weil sie später noch nützlich sind.

Answer 13

Ich beginne normalerweise mit einer Klassenbibliothek und einer separaten, wirklich beschissenen und einfachen GUI. Da die Befehlszeile das Parsen der Befehlszeile umfasst, habe ich das Gefühl, dass ich unnötigen Overhead hinzufüge.

Als Bonus ergibt dies einen MVC-ähnlichen Ansatz, da der gesamte "echte" Code in einer Klassenbibliothek enthalten ist. Zu einem späteren Zeitpunkt ist natürlich auch eine Refactoring der Bibliothek zusammen mit einer echten GUI in eine EXE möglich.

Answer 14

Wenn Sie Ihre Entwicklung richtig machen, dann sollte es relativ einfach sein, später im Projekt zu einer GUI zu wechseln. Das Problem ist, dass es irgendwie schwierig ist, es richtig zu machen.

Answer 15

John Gruber hatte einen guten Beitrag über das Konzept einer GUI zu einem Programm nicht für eine entworfen hinzuzufügen: Ronco Spray-On Usability

Zusammenfassung: Es funktioniert nicht. Wenn Usability nicht von Anfang an in eine Anwendung integriert ist, ist das Hinzufügen zu einem späteren Zeitpunkt mehr Arbeit als jeder andere bereit ist.

Answer 16

Machen Sie ein Programm, das Sie als Web-Service bereitstellen. dann führe die GUI und die Befehlszeile aus, um denselben Webservice aufzurufen. Dieser Ansatz ermöglicht es Ihnen auch, eine Web-GUI zu erstellen und die Funktionalität als SaaS für Extranet-Partner bereitzustellen und/oder die Geschäftslogik besser zu sichern.

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

Für den Web-Service, gehen Sie nicht über Bord. mach yaml oder xml-rpc. Halte es einfach.

Answer 17

Ein besserer Ansatz könnte sein, die Logik als lib mit einem gut definierten API und auf der dev Stufe zu entwickeln, keine Schnittstelle (oder eine Schnittstelle hart codiert), dann können Sie wright die CLI oder GUI später

Answer 18

Zusätzlich zu dem, was Stu gesagt, mit einer gemeinsam genutzten Bibliothek können Sie es auch von Web-Anwendungen verwenden. Oder sogar von einem IDE-Plugin.

Answer 19

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

Entwurf:

Eine GUI und ein CLI sind zwei verschiedene Schnittstellen verwendet, um eine darunter liegende Implementierung zuzugreifen. Sie werden im Allgemeinen für verschiedene Zwecke verwendet (GUI ist für einen Live-Benutzer, CLI wird normalerweise durch Skripting aufgerufen) und kann oft unterschiedliche Anforderungen haben. Die beiden zusammen zu koppeln, ist keine kluge Wahl und wird dir auf der Straße Ärger bereiten.

Performance:

Die Art und Weise Sie die Dinge beschrieben haben, müssen Sie jedes Mal eine ausführbare Datei, um laichen die GUI muss d o etwas. Das ist einfach nur hässlich.

Der richtige Weg, dies zu tun, ist die Implementierung in eine Bibliothek, die sowohl von der CLI und der GUI aufgerufen wird.

Answer 20

Es gibt mehrere Gründe, warum es so nicht sinnvoll ist. Viele von ihnen wurden erwähnt, also bleibe ich bei einem bestimmten Punkt.

Befehlszeilentools sind normalerweise überhaupt nicht interaktiv, während GUI's sind. Dies ist ein grundlegender Unterschied. Dies ist zum Beispiel für lang andauernde Aufgaben schmerzhaft.

Ihr Befehlszeilentool wird im besten Fall eine Art von Fortschrittsinformationen ausgeben - Zeilenumbrüche, eine Textfortschrittsleiste, eine Reihe von Ausgaben, ... Jede Art von Fehler kann nur auf der Konsole ausgegeben werden.

Jetzt wollen Sie noch eine GUI dazu schlagen, was machen Sie? Analysieren Sie die Ausgabe Ihres lang laufenden Befehlszeilenprogramms? Nach WARNING und ERROR in dieser Ausgabe suchen, um ein Dialogfeld zu öffnen?

Im besten Fall erzeugen die meisten auf diese Weise erstellten Benutzeroberflächen einen pulsierenden Busy-Balken, solange der Befehl ausgeführt wird, und zeigen dann beim Beenden des Befehls einen Erfolgs- oder Fehlerdialog an. Leider werden so viele UNIX-GUI-Programme zusammengeworfen, was es zu einer schrecklichen Benutzererfahrung macht.

Die meisten Replikatoren hier sind richtig, wenn Sie sagen, dass Sie wahrscheinlich die tatsächliche Funktionalität Ihres Programms in eine Bibliothek abstrahieren sollten, dann schreiben Sie eine Befehlszeilenschnittstelle und die GUI gleichzeitig dafür. Die gesamte Geschäftslogik sollte in Ihrer Bibliothek enthalten sein, 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 zu schlecht, um sicherzustellen, dass Sie Ihre Bibliothek für die spätere Verwendung der grafischen Benutzeroberfläche gut genug entwickeln. Sie sollten von Anfang an mit beiden beginnen oder mit der GUI-Programmierung beginnen. Es ist einfach, eine Befehlszeilenschnittstelle zu einer Bibliothek hinzuzufügen, die für eine GUI entwickelt wurde, aber umgekehrt ist es viel schwieriger, genau wegen all der interaktiven Funktionen, die die GUI benötigt (Berichte, Fortschritt, Fehlerdialoge, i18n, ...).)

Answer 21

Das ist genau eine meiner wichtigsten Erkenntnisse über Codierung und ich wünschte, mehr Menschen würden einen solchen Ansatz nehmen.

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 von einer GUI oder einer Befehlszeile aus zu steuern. Zumindest am Anfang und nur Grundoperationen.

Wann ist das eine großartige Idee?

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

Wann ist dies eine schlechte Idee codieren?

Wenn Sie sicher sind, Ihr Framework nie