Wird die Entwicklung von CLI-Apps als „rückwärts“ betrachtet? [geschlossen]

38

Ich bin ein DBA-Anfänger mit viel Erfahrung in der Programmierung.

Ich habe mehrere nicht interaktive CLI-Apps entwickelt, die einige sich täglich wiederholende Aufgaben lösen oder das menschliche Versagen bei komplexeren, wenn auch nicht so alltäglichen Aufgaben beseitigen. Diese Werkzeuge sind jetzt Teil unserer Werkzeugkiste.

Ich finde, CLI-Apps sind großartig, weil Sie sie in einen automatisierten Workflow einbinden können.

Auch die Unix-Philosophie, etwas zu tun, aber es gut zu machen und die Ausgabe eines Prozesses als Eingabe eines anderen Prozesses zu betrachten, ist eine großartige Möglichkeit, eine Reihe von Tools zu erstellen, die sich zu einem strategischen Vorteil zusammenfügen lassen.

Mein Chef hat kürzlich kommentiert, dass die Entwicklung von CLI-Tools "rückwärts" ist oder eine "Regression" darstellt.

Ich habe ihm gesagt, dass ich nicht damit einverstanden bin, weil die meisten CLI-Tools, die es derzeit gibt, keine Legacy-Projekte sind, sondern Live-Projekte, bei denen ständig verbesserte Versionen veröffentlicht werden.

Wird diese Art von Entwicklung auf dem Markt als "rückwärts" betrachtet?

Sieht es auf einen Lebenslauf schlecht aus?

Ich habe auch überlegt, ob es sich um Web- oder Desktop-Lösungen handelt, die über nicht interaktive Befehlszeilenoptionen verfügen sollen. Einige Leute halten dies für eine Verschwendung von Programmierressourcen.

Ist dieses Ziel in einem Softwareprojekt ein würdiges Ziel?

Ich denke auch, dass für eine Web- oder Desktop-App die Verwendung einer alternativen CLI-Schnittstelle eine hervorragende Möglichkeit ist, um zu demonstrieren, dass die Geschäftslogik vollständig von der GUI entkoppelt ist.

Tulains Córdova
quelle
32
Hat Ihr Chef einen technischen Hintergrund? Es hört sich so an, als würde er der "Ich sehe nicht viel, ergo steckt nicht viel dahinter" -Philosophie folgen. Welches kann problematisch sein. Fragen Sie ihn, ob er der Meinung ist, dass die Leute, die Oracle entwickeln, auch rückständig sind.
Joachim Sauer
13
Mir gefällt, wie die Dinge in der Linux-Welt gemacht werden. Die meisten 'Hauptanwendungen' haben sowohl CLI- als auch GUI-Fronten - dies ist frei, da Sie Skripte erstellen können, wenn Sie dies benötigen, und mit der Maus klicken können, wenn Sie dies nicht benötigen. Ich verstehe nicht, warum Sie unbedingt einen gegen den anderen auswählen müssen. Das Schreiben einer CLI erfordert nicht viel Arbeit.
MrFox
6
Ihr Chef hat offenbar nie versucht, das grundlegendste Drehbuch zu schreiben
toasted_flakes
1
@MrFox Ich stimme dir zu, Apps sollten beide Frontends haben.
Tulains Córdova
4
Ich mag diese aber leider gibt es auch manchmal diese ;)
wim

Antworten:

21

Die Fähigkeit, mit einer CLI zu arbeiten, ist kaum das, was ich rückwärts betrachten würde. In einem Lebenslauf sieht es großartig aus, besonders wenn Sie ihn in Ihrem Lebenslauf mit einem Satz wie "Verwendet (Powershell / Bash), um eine Suite von Automatisierungstools zum Senden von SMS-Nachrichten zu erstellen, wenn die Datenbank inaktiv war" drehen können.

Wenn ich für die Einstellung von Mitarbeitern zuständig bin, suche ich nach Kenntnissen der CLI.

Jonathan Arkell
quelle
49

Im Grunde kommt es darauf an, "das richtige Werkzeug für den Job zu verwenden".

Wenn Sie mit einem Benutzer interagieren müssen, benötigen Sie eine GUI. Wir haben jahrzehntelange Forschung und Erfahrung, die zeigen, dass sie das Computing viel intuitiver und produktiver machen. Deshalb haben GUIs seit 1984 unaufhaltsam die Welt erobert: Sie funktionieren einfach besser für die Interaktion mit Menschen.

Wenn Sie jedoch ein Programm mit Skripten automatisieren, interagiert Ihr Programm nicht mit Personen. Es interagiert mit einem Skript. Und die beste Oberfläche dafür ist eine textbasierte, aus Gründen, die intuitiv offensichtlich sein sollten.

Die Entwicklung von CLI-Programmen, mit denen Benutzer direkt arbeiten können, wird aus gutem Grund als rückständig angesehen. Aber wenn Sie dies nicht tun oder Produktivitätswerkzeuge für die Automatisierung schreiben, können Sie nichts falsch machen, indem Sie ihnen eine CLI zuweisen.

Mason Wheeler
quelle
6
+1 Nun, einige der Tools geben Benutzern Informationen wie "Sind alle Datenbank-Backups auf dem neuesten Stand, wenn nicht, sagen Sie mir, welche sind alt?". Sie drucken die Antwort an STDOUT. Aber offensichtlich kann es auf eine Crontab gelegt werden, um eine SMS zu senden, wenn die Antwort NEIN ist. Ich denke, auch wenn die App GUI ist, sollte es einen CLI-Modus mit Parametern haben. Ich selbst bin ein Bewunderer von GUIs, ich bin immerhin ein Mac-Benutzer. Viele geschäftskritische Apps, insbesondere solche, die im eigenen Haus entwickelt wurden, berücksichtigen niemals eine CLI.
Tulains Córdova
23
Obwohl ich zu 99% damit einverstanden bin, habe ich auch festgestellt, dass ich als technischer Benutzer die CLI manchmal einer GUI vorziehe. Der Grund dafür ist, dass ich in vielen GUIs navigieren, zeigen, klicken, durch Menüs gehen, nach dem richtigen Kontrollkästchen suchen usw. Auf einer CLI muss ich jedoch nur das Englisch in meinem Kopf auf "Computerisch" übersetzen die befehlszeile und das programm macht was ich will in kürzerer zeit. Während GUIs für Gelegenheitsbenutzer viel einfacher sind, bevorzugen erfahrene Benutzer manchmal die CLI.
Phil
15
„Die Entwicklung von CLI - Programmen für Benutzer zur Arbeit mit direkt nach hinten betrachtet wird, und das mit gutem Grunde“ um, nein, es ist nicht so einfach, also warum jeder so weit fortgeschritten GUI - Anwendung Endes up einig Scripting - Engine mit einer eigenen CLI Einbettung
jk.
11
@ MasonWheeler: Ich denke, du vermisst den Punkt von jk. Wenn eine GUI kompliziert wird, bevorzugen technisch versierte Benutzer häufig die Verwendung einer CLI-Skript-Engine, selbst für eine einmalige Aufgabe . Die absolut ist „Benutzer arbeitet mit [it] direkt“.
Ruakh
8
-1 zu "Die Entwicklung von CLI-Programmen, mit denen Benutzer direkt arbeiten können, wird als rückwärts betrachtet, und dies hängt aus gutem Grund völlig von der Anwendung ab." Als Benutzer muss ich oft mit einem Programm arbeiten, um auf einem Computer zu laufen, der nicht einmal eine GUI oder einen Monitor hat. Dann brauche ich unbedingt eine CLI!
Mittwoch,
35

Eric Raymonds The Art of Unix Programming ist die kanonische Arbeit für das Argument, das Sie vorbringen. Ich werde nicht versuchen, sein ausgezeichnetes Buch in ein paar Absätze zu fassen. Beachten Sie jedoch, dass dieses Argument hauptsächlich für Programmierer, Administratoren, die Aufgaben mithilfe von Skripten automatisieren, oder Power-User von hochtechnischer Software wie CAD gilt.

Auch bei hochtechnischen Anwendern muss man sich überlegen, welche Hüte sie gerade tragen. Zum Beispiel schreibe ich eingebettete Software für Netzwerkgeräte für den Lebensunterhalt. Unsere Produkte haben sowohl eine CLI als auch eine GUI, aber Entwickler bevorzugen die CLI aufgrund ihrer Flexibilität, Skriptfähigkeit, Verfügbarkeit, Geschwindigkeit usw. fast überall.

Genau diese Gruppe von Entwicklern bevorzugt jedoch die GUI unserer Versionskontrollsoftware, obwohl die CLI leistungsfähiger ist und genau so gut wie die GUI unterstützt und dokumentiert wird. Der Unterschied besteht darin, dass wir die Endbenutzer der Versionskontrollsoftware sind, keine Administratoren oder Entwickler.

Überlegen Sie sich daher genau, in welchen Rollen Ihre Benutzer Ihre Dienstprogramme verwenden, und planen Sie die Benutzeroberfläche entsprechend. Wenn Ihr Chef dies erwähnt, müssen Sie wahrscheinlich zumindest die Dokumentation und / oder die Schulung für die CLI verbessern. Wenn Sie anderen Personen ständig mitteilen, dass eine Funktion nur dann in der CLI verfügbar ist, wenn sie dies für die GUI erwartet, müssen Sie wahrscheinlich Ihre Entwicklungsprioritäten überdenken und die Bedürfnisse Ihrer Benutzer besser berücksichtigen.

Karl Bielefeldt
quelle
16

Nicht nur Unix wird von Befehlszeilenprogrammen gesteuert. Microsoft steuert ebenfalls in diese Richtung.

Microsoft pusht seit einiger Zeit PowerShell. Die gesamte aktuelle Serversoftware (Exchange, SharePoint, Server 2012, System Center usw.) kann vollständig über die PowerShell-Befehlszeile gesteuert werden. Und PowerShell basiert auf kleinen Funktionen, die eine Sache gut machen und Daten an die nächste weiterleiten (obwohl sie Objekte anstelle von nur Text weiterleiten).

Die meisten GUIs für diese Programme sind lediglich ein Frontend für die PowerShell-Befehle. Viele sagen Ihnen sogar, welche Befehle ausgeführt werden sollen, um die Skripterstellung zu vereinfachen. Alles, was Sie von der GUI aus tun können, können Sie von PowerShell aus tun. Das Gegenteil ist nicht der Fall - es gibt einige Funktionen, die nur in PowerShell verfügbar gemacht werden.

Also, wenn * nix es immer getan hat und Microsoft in diese Richtung geht ... scheint mir nicht sehr rückständig zu sein!

Gewähren
quelle
5
Nur um das noch zu ergänzen: Microsoft drängt die GUI auf Servern in großem Umfang von sich weg . Sie möchten, dass jeder Server Core ausführt - keine grafische Benutzeroberfläche, Punkt. Wenn Sie eine Reihe von Aufgaben auf einem Computer ausführen können, können Sie sie im gesamten Unternehmen ausführen - viel Glück mit einer grafischen Benutzeroberfläche. Jeffrey Snover (leitender Architekt für Windows) gab ein gutes Interview zu diesem Thema.
Alroc
4
"Windows" steuert nicht in diese Richtung. Windows Server ist. Ein Server soll als automatisiertes System mit minimaler menschlicher Interaktion ausgeführt werden. Dies ist also sinnvoll. Aber Sie werden nie sehen, dass dies in den benutzerbezogenen Teilen des Betriebssystems passiert.
Mason Wheeler
3
Außerdem wechselte Mac OS X von einer reinen GUI zu einer * nix-Architektur mit starkem Fokus auf Befehlszeilenskripting. Daher würde ich sagen, dass sowohl Microsoft als auch Apple auf dem Weg zu mehr CLI sind.
Brandon
1
+1 Ich musste den Leuten auf C-Level erklären, wie 'Windows' zum Text zurückkehrt. Es ist sinnvoll - jede Aktion kann per Skript ausgeführt, getestet und auf Tausenden von Servern bereitgestellt werden, anstatt sich in jeder Box anzumelden und zu versuchen, 200 Mausklicks genau zu replizieren. Das OP sollte seine / ihre Fähigkeiten als Skript / Automatisierung und nicht nur als CLI einsetzen. IIRC Windows bietet Powershell-Unterstützung ab XP. Es ist großartig, Pre-Reqs mit einem Skript zu installieren, anstatt mit vielen Klicks.
JQA
Sie haben Recht, aber denken Sie daran, dass GUIs für die Masse der (dummen) Computerbenutzer das Einzige sind, was sie wissen und sehen. Dies gilt insbesondere, wenn Sie die Tatsache berücksichtigen, dass die GUI älter als viel ist von ihnen ...
Radu Murzea
4

Ich würde definitiv nicht sagen, dass es eine schlechte Sache ist. Das Schöne an CLI-Programmen ist, dass Sie bei der Implementierung einen sehr eingeschränkten Umfang haben können. Wenn ich zum Beispiel einen catKlon oder ein Programm zum Drucken des Inhalts einer Datei auf dem Bildschirm schreiben möchte , ist dies mit CLI sehr gut möglich.

Was wäre, wenn Sie CLI nicht verwenden würden? Dann hätten Sie ein Basisprogramm mit einer GUI, die Text anzeigt. Dann müssten Sie aber auch einen Dateidialog öffnen und diesen anhängen. Dann möchte aber auch jemand den Text ändern und an einer anderen Stelle speichern können.

Scope Creep ist mit GUI-Apps lächerlich. Mit CLI-Apps lässt sich dies jedoch ganz einfach vermeiden. "Sie möchten die Datei bearbeiten und dann erneut speichern? cat foo > ed > bar" Bei CLI-Apps ist es für Ihre Benutzer (nicht für Sie, den Entwickler) trivial , sie mit anderen Tools zu kombinieren.

Abgesehen davon werden CLI-Programme allmählich als "rückwärts" betrachtet. Dies liegt daran, dass heutzutage viele Anwendungen auf Märkten entwickelt werden, auf denen Benutzer Ihr Tool kaum mit anderen Tools kombinieren können. Ich werde hier nicht darauf eingehen, aber ich habe einen Blogbeitrag darüber geschrieben, wie "Marktplätze die Mentalität eines Meisters ohne Grenzen durchsetzen", was das genaue Gegenteil einer gut gestalteten CLI-App ist (um eine Sache zu tun und es gut zu machen) )

Earlz
quelle
4

GUI und CLI haben ihren Platz. Die GUI ist großartig, damit ein Benutzer bestimmte Vorgänge schnell ausführen kann. Mit der CLI können Sie Dinge erledigen, die die GUI nicht zulässt. Die CLI ist normalerweise leistungsfähiger und schwerer zu bedienen.

Ein gutes CLI-Tool ermöglicht es dem Benutzer, Dinge zu tun, an die die Person, die das Tool geschrieben hat, nie gedacht hat. Ein Beispiel ist der UNIX-Befehl 'find'. Dieser Befehl:

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

findet Dateien im aktuellen Verzeichnis (jedoch auf 5 Ebenen darunter begrenzt), deren Name mit 'xyzzy' beginnt und die vor mehr als 3 Tagen geändert wurden, und löscht sie dann (Hinweis: ungetesteter Code). Und das ist eine mäßig einfache Verwendung. Sie können dazu einen Dateimanager verwenden, der jedoch länger dauert und fehleranfällig ist. Stärker zu sein bedeutet natürlich, dass die CLI leichter missbraucht werden kann und Probleme für Sie selbst schafft!

Ein guter Entwickler kann ein CLI-Tool so schreiben, dass es auch über eine grafische Benutzeroberfläche verfügt, mit der eine begrenzte Anzahl von Vorgängen ausgeführt werden kann. Der Benutzer kann mit der GUI beginnen und später die Komplexität der CLI erlernen.

Eine gute (lange und voreingenommene (?)) Lektüre zum CLI / GUI-Kompromiss lautet:

http://www.cryptonomicon.com/beginning.html
rzzzwilson
quelle
1
+1, insbesondere für den Verweis auf "Am Anfang war die Befehlszeile"
Ben Lee
1

Nein, es ist überhaupt nicht rückwärts.

Die "Richtung" hat viel mit unserer Perspektive zu tun. Ein Benutzer, der mit dem aktuellen Weg zu einfachen "One Experience All Devices" -Oberflächen zufrieden ist, wird die CLI mit Sicherheit als Rückschritt oder Regression betrachten. Es entspricht nicht ihren allgemeinen Erwartungen.

Ein Programmierer, Administrator oder Hauptbenutzer kann dies als logischen Fortschritt von Werkzeugen entsprechend ihrer Erfahrung ansehen. Viele von ihnen verwenden zunächst GUI-Tools. Wenn sie skalieren möchten oder müssen, finden sie schnell heraus, warum es die CLI gibt, und diese Entwicklung kommt bei denen zum Tragen, die mehr CLI-Tools erstellen.

Es gibt dies von Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Für mich persönlich unterscheidet die Idee der Syntax die beiden. Wenn die Syntax in einer GUI etwas vorhanden ist, ist das Ergebnis fast nie gut und ebenso flexibel wie die durchdachte CLI-Syntax. Wenn dies mit Pipes und Umleitungen gekoppelt ist, fällt die GUI flach aus, da sie außerhalb der geplanten Anwendungsfälle nicht sehr nützlich ist.

Ich persönlich bevorzuge CLI-Tools, die eine Option --gui oder --verbose bieten, die ausreicht, um einem GUI-Wrapper eine robuste Interaktion zu ermöglichen, einschließlich Statusleisten und anderer grundlegender Elemente, nach denen die Benutzer der GUI suchen.

Natürlich sind die Kosten dafür im Wesentlichen zwei Programme, von denen eines ohne das andere ziemlich nutzlos ist. Der Hauptvorteil besteht jedoch darin, dass ein oder mehrere hervorragende CLI-Tools in eine benutzerdefinierte GUI integriert werden können, ohne dass Änderungen an den CLI-Tools vorgenommen werden müssen. Meistens wird dies nur durchgeführt, um eine GUI-Option für eine bestimmte CLI anzubieten. Die Idee, mehrere Tools mit einer "prozessorientierten" oder "anwendungsfallorientierten" GUI zu betreiben, kann jedoch zu Ergebnissen führen, die der Weiterleitung und Umleitung sowie der Skripterstellung für diesen Anwendungsfall ähneln. Bereitstellung für Personen, die diese Vorgänge nicht regelmäßig genug ausführen würden, um die Meisterschaft zu erlangen, ohne die CLI-Benutzer zu behindern.

Ich bin auf diesen Ansatz bei SGI IRIX gestoßen und er hat mir sehr gut gefallen. Ich stellte fest, dass ich entweder die GUI oder die Befehlszeile nach Bedarf verwendete und das Schöne war, genau zu wissen, was die ausgefallenen Tasten tatsächlich taten.

Bei vielen verschiedenen Betriebsumgebungen können sich die GUI-Wrapper erheblich unterscheiden, ohne dass dies auch Auswirkungen auf das CLI-Tool hat.

Ich sehe dies heute in Linux mit Dingen wie Festplatten- / Dateisystem-Tools, bei denen die GUI selbst CLI-vertrauten Benutzern viel Wert hinzufügen kann.

Bei bekannten Dateisystemen / Datenträgern / Geräten ist es nicht schwierig, die CLI auszuschalten, und es kann natürlich ein Skript erstellt werden. Fehler können jedoch schmerzhaft sein.

Wenn diese möglicherweise nicht bekannt sind oder die Ausführung der Vorgänge nicht regelmäßig genug erfolgt, um stabil und fehlerfrei zu bleiben, bietet das Ausführen der GUI eine Umgebung, die einfach überprüft, Vorgänge verkettet und dann zuverlässig ausgeführt werden kann, ohne dass Skripts erforderlich sind.

user94936
quelle