CLIアプリの開発は「後方」と見なされますか？[閉まっている]

私はプログラミングの経験が豊富なDBAです。

私はいくつかのCLI、非日常的なアプリを開発しました。これらのアプリは、日々の反復タスクを解決したり、それほど複雑ではないものの、より複雑なタスクから人的エラーを排除したりします。これらのツールは現在、ツールボックスの一部です。

CLIアプリは、自動化されたワークフローに含めることができるので素晴らしいと思います。

また、単一のことを行うがそれをうまく行い、プロセスの出力を別の入力とするというUnixの哲学は、戦略的な利点に統合するよりもツールのセットを構築する優れた方法です。

私の上司は最近、CLIツールの開発は「後方」である、または「回帰」を構成するとコメントしました。

現在存在するほとんどのCLIツールはレガシーではなく、常に改善されたバージョンがリリースされているライブプロジェクトであるため、私は同意しませんでした。

この種の開発は、市場で「後方」と見なされますか？

履歴書では見た目が悪いですか？

また、ウェブであろうとデスクトップであろうと、すべてのソリューションを検討しました。コマンドライン、非対話型オプションが必要です。一部の人々は、これをプログラミングリソースの無駄だと考えています。

この目標は、ソフトウェアプロジェクトの価値ある目標ですか？

また、Webアプリまたはデスクトップアプリの場合、代替CLIインターフェイスを持つことは、ビジネスロジックがGUIから完全に切り離されていることを示す素晴らしい方法だと思います。

CLIを操作する能力を持つことは、私が後方に考えることはほとんどありません。特に、「データベースがダウンしたときにSMSメッセージを送信する自動化ツールのスイートを構築するために使用（Powershell / Bash）」のようなフレーズを使用して履歴書でスピンできる場合は、履歴書に最適です。

私が人を雇う責任があるとき、CLIの実用的な知識は私が探しているものです。

基本的には、「仕事に適切なツールを使用する」ことになります。

ユーザーと対話する必要がある場合は、何らかのGUIが必要になります。コンピューティングをはるかに直感的かつ生産的にすることを示す数十年の研究と経験があります。それが、GUIが1984年以来容赦なく世界を支配してきた理由です。GUIは、人々とのやり取りのためにより良く機能します。

ただし、スクリプトを使用してプログラムを自動化する場合、プログラムは人と対話しません。スクリプトと相互作用しています。そして、そのための最良のインターフェースはテキストベースのものです。理由は直感的に明らかです。

ユーザーが直接作業するためのCLIプログラムの開発は、後向きであり、十分な理由があると考えられています。しかし、それがあなたがしていることではない場合、自動化生産性ツールを書いている場合、それらにCLIを与えることによって何も悪いことをしていません。

エリック・レイモンドの「Unixプログラミングの芸術」は、あなたが行っている議論の標準的な作品です。私は彼の素晴らしい本をいくつかのパラグラフに凝縮しようとはしません。ただし、引数は主にプログラマ、スクリプトを使用してタスクを自動化する管理者、またはCADなどの高度に技術的なソフトウェアのパワーユーザーに適用されることに留意してください。

高度に技術的なユーザーであっても、その時点でどの帽子を着ているかを考慮する必要があります。たとえば、私は生活のためのネットワーク機器用の組み込みソフトウェアを書いています。当社の製品はすべてCLIとGUIの両方を備えていますが、その柔軟性、スクリプト化可能性、可用性、速度などにより、開発者はほとんどの場合CLIを好みます。

ただし、そのまったく同じ開発者グループは、CLIがより強力であり、GUIと同様にサポートおよび文書化されているにもかかわらず、バージョン管理ソフトウェアのGUIを圧倒的に好んでいます。違いは、管理者や開発者ではなく、バージョン管理ソフトウェアのエンドユーザーであることです。

そのため、ユーザーがユーティリティを使用しているときのユーザーの役割を慎重に検討し、それに応じてユーザーインターフェイスを計画してください。上司がそれについて言及している場合は、少なくともCLIのドキュメントやトレーニングを改善する必要がある可能性があります。GUIで期待されるときにのみCLIで機能を使用できるように人々に常に伝えている場合、おそらくユーザーのニーズをより考慮して、開発の優先順位を再考する必要があります。

コマンドラインプログラムによって駆動されるのは、Unixだけではありません。マイクロソフトもその方向に向かっています。

Microsoftはしばらくの間、PowerShellを推進しています。現在のすべてのサーバーソフトウェア（Exchange、SharePoint、Server 2012、System Centerなど）は、PowerShellコマンドラインを使用して完全に制御できます。また、PowerShellは、あることをうまく行い、次のデータにパイプする小さな関数に依存しています（ただし、テキストだけでなくオブジェクトをパイプします）。

これらのプログラムのGUIのほとんどは、PowerShellコマンドの単なるフロントエンドであり、多くの場合、スクリプトを簡単にするためにどのコマンドを実行するかを示しています。PowerShellからできるGUIからできることはすべて。その逆は当てはまりません-PowerShellでのみ公開されている関数がかなりあります。

したがって、* nixが常にそれを行っており、Microsoftがそのように進んでいるのなら...私にはさほど逆行していないようです！

悪いことだとは絶対に言いません。CLIプログラムの良いところは、それらを実装するとき、非常に制限されたスコープを持つことができることです。たとえば、catクローンまたは「ファイルの内容を画面に出力するプログラム」を作成する場合、CLIを使用すると非常に適しています。

ただし、CLIを使用しなかった場合、テキストを表示するGUIを備えた基本的なプログラムが必要になります。しかし、その後、ファイルダイアログを開いて接続することも必要になります。しかし、誰かがテキストを変更して別の場所に保存できるようにしたい場合もあります。

スコープクリープは、GUIアプリではばかげています。CLIアプリを使用すれば、非常に簡単に回避できます。「あなたがファイルを編集し、それを保存し直し？したいcat foo > ed > barCLIは、それがために些細だアプリで」ユーザー（ないあなたを、開発者が）他のツールとそれを結合します。

現在、CLIプログラムは「後方」と見なされ始めています。これは、最近のアプリケーション開発の多くは、ユーザーがツールを他のツールと組み合わせることがほとんど不可能な市場で行われるためです。私はここでそれに行くことはありませんが、私は書いたブログ記事を一つのことを行うために、よくそれを行うにはうまく設計されたCLIアプリケーションの完全な反対で、（「市場は、マスター・オブ・なし考え方を強制する」方法について）

GUIとCLIの両方にそれぞれの場所があります。GUIは、ユーザーが特定の既定の操作をすばやく実行できるようにするのに最適です。CLIは、GUIで許可されていないことを実行する場合に使用します。通常、CLIはより強力で使いにくいです。

良いの CLIツールは、ユーザーがツールを書いた人は考えもしないことを行うことができます。1つの例は、UNIXの「find」コマンドです。このコマンド：

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

「xyzzy」で始まる名前を持ち、3日以上前に変更されたファイルを現在のディレクトリ（ただし、5レベル以下に制限）の下で検索し、それらを削除します（注：テストされていないコード）。そして、それはややシンプルな使用法です。ファイルマネージャーを使用してそのようなことを行うことができますが、時間がかかり、エラーが発生しやすくなります。もちろん、より強力であるということは、CLIがより簡単に悪用され、自分自身で問題が発生する可能性があることを意味します！

優れた開発者は、限られた一連の操作を実行できるGUIを備えた方法でCLIツールを作成できます。ユーザーはGUIから始めて、CLIの複雑さを後で学ぶことができます。

CLI / GUIのトレードオフに関する適切な（長く偏った（？））読み取りは、次の場所にあります。

http://www.cryptonomicon.com/beginning.html

いいえ、それはまったく逆ではありません。

「方向」は私たちの見方に大きく関係しています。単純な「すべてのデバイスを体験する」インターフェースへの現在のパスに満足しているユーザーは、CLIを確実に先祖返りまたはリグレッションとして見るでしょう。彼らの全体的な期待に沿っていません。

プログラマー、管理者、またはパワーユーザーは、経験に応じてツールを論理的に進化させたものと見なすでしょう。これらの多くは、GUIツールを使用して開始します。スケーリングを希望する場合、またはスケーリングする必要がある場合、CLIが存在する理由と、その進行がより多くのCLIツールを構築する人々と共鳴することを迅速に把握します。

これはポール・フェリスであり： http://www.linuxplanet.com/linuxplanet/opinions/1505/1

私にとって個人的には、構文の考え方が2つを区別しています。GUIに構文がある程度存在する場合、結果はほとんど決して良くなく、よく考えられたCLI構文と同じくらい柔軟です。これがパイプとリダイレクトと組み合わされると、GUIは計画されたユースケース以外ではあまり役に立たないためフラットになります。

これに関する私の個人的な好みは、GUIバーがステータスバーやGUIを探している他の基本的な要素を含む堅牢な方法で対話できるようにするのに十分な--guiまたは--verboseオプションを提供するCLIツールです。

もちろん、このコストは基本的に2つのプログラムであり、一方はもう一方がなければ役に立たないが、主な利点は、CLIツールを変更せずに1つ以上の優れたCLIツールをカスタムGUIに組み込むことができることです。ほとんどの場合、これは特定のCLIでGUIオプションを提供するためだけに行われますが、1つの「プロセス」または「ユースケース」指向のGUIで複数のツールを駆動するという考え方は、そのユースケースのパイピングとリダイレクトおよびスクリプトに似た結果を提供できます。これらの操作を定期的に実行せずに、CLIユーザーを抑制せずに習得できるユーザーが使用できるようにします。

SGI IRIXでこのアプローチに出会い、本当に気に入りました。必要に応じてGUIまたはコマンドラインのいずれかを使用していることに気付きました。素晴らしいことは、派手なボタンが実際に何をしていたかを正確に知っていたことです。

さまざまなオペレーティング環境が多数ある場合、GUIラッパーはCLIツールにも影響を与えずに大幅に異なる場合があります。

Linuxのディスク/ファイルシステムツールのようなものでこれを見ると、GUIはCLIの使い慣れたユーザーにも大きな価値をもたらします。

既知のファイルシステム/ディスク/デバイスの場合、CLIをノックアウトするのは難しくなく、もちろんスクリプト化できます。ただし、間違いは痛みを伴う場合があります。

それらがわからない場合、または操作の実行が確実でエラーのない状態を維持するのに十分な頻度で行われていない場合、GUIを実行すると、簡単に検証し、操作をチェーン化してから自信を持って実行できる環境が提供され、スクリプトは不要です。