まずコマンドライン用に開発することについてどう思いますか?

https://stackoverflow.com/questions/18984

09-06-2019
|

質問

最初にコマンドライン用に開発し、その後コマンドラインメソッドを呼び出すだけで GUI を追加することについてはどう思いますか?

例えば。

W:\ todo AddTask "ジョンとのミーティング、再:ログインピアレビュー" "ジョンのオフィス" "2008-08-22" "14:00"

負荷 todo.exe そして、という関数を呼び出します AddTask これにより、何らかの検証が行われ、会議がデータベースにスローされます。

最終的には、このための画面を追加します。

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

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

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

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

[送信] をクリックすると、同じ AddTask 関数が呼び出されます。

これは考慮されますか:

コーディングする良い方法
初心者のためだけに
ひどい！。

補遺:

ここでは、「GUIとCLIの両方の実行可能ファイルの両方が呼ぶ共有ライブラリ」の傾向に気付いています。多分バイナリ自体のサイズ以外に、彼らが分離されなければならない理由は何らかの説得力のある理由がありますか？

同じ実行可能ファイルを別の方法で呼び出してみてはいかがでしょうか。

"todo /G" 完全なグラフィカルインターフェイスが必要な場合
"todo /I" インタラクティブなプロンプトの場合内で todo.exe (スクリプト作成など)
普通の古い "todo <function>" 一つのことだけをして、それで終わりにしたいとき。

補遺 2:

「私が物事を説明した方法では、GUI が何かをする必要があるたびに実行可能ファイルを生成する必要がある」と述べられていました。

繰り返しますが、これは私の意図ではありませんでした。例の GUI が「同じものである」と述べたとき、 AddTask 関数、」という意味は、GUI が毎回コマンドラインプログラムを呼び出すという意味ではありません。それはまったくひどいことになるだろうと私も同意します。これは小さな例だったので、これをすべて 1 つの実行可能ファイルに含めるつもりでした (最初の補遺を参照) が、私の表現が必ずしも共有ライブラリを排除するものではないと思います。

また、ご意見をいただきました皆様に感謝申し上げます。これは私の心に何度も思い出されることであり、あなたの経験から得た知恵に感謝しています。

解決

私なら、ライブラリにリンクするコマンドラインアプリケーションを備えたライブラリを構築することにします。その後、同じライブラリにリンクする GUI を作成できます。GUI からコマンドラインを呼び出すと、コマンドごとに外部プロセスが生成され、OS への影響が大きくなります。

また、ライブラリを使用すると、機能の単体テストを簡単に実行できます。

ただし、関数コードがコマンドラインインタプリタから分離されている限り、操作を実行するために 2 種類のソースを同時に使用しなくても、GUI のソースを再利用することができます。

他のヒント

共有機能をライブラリに配置し、そのためのコマンドラインと GUI フロントエンドを作成します。こうすることで、レイヤーのトランジションがコマンドラインに関連付けられなくなります。

(また、この方法では別のセキュリティ上の懸念が追加されます:GUI はまず、呼び出されているのが正しい todo.exe であることを確認する必要があるのではないでしょうか?)

Joel は数年前に、この (「UNIX スタイル」) 開発と GUI ファースト (「Windows スタイル」) 方法を対比する記事を書きました。彼はそれを呼んだ二文化主義.

Windows では、ロジックを .NET アセンブリにラップすることが (まだそうでない場合は) 通常になると思います。そうすれば、GUI と PowerShell プロバイダーの両方からアクセスできるようになります。そうすれば、両方の長所を活かすことができます。

明示的な UI を必要とせずに、最初にバックエンド機能をプログラミングするための私の手法 (特に UI がまだ仕事ではない場合、たとえば、まだ設計フェーズにある Web アプリケーションを設計している場合) は、単体テストを作成することです。

そうすれば、バックエンドコードの出力をモックするコンソールアプリケーションを作成する必要さえありません。すべてがテスト内にあり、コンソールアプリケーションとは異なり、テスト用のコードを破棄する必要がありません。後で役に立ちます。

開発しているアプリケーションの種類によって異なると思います。コマンドライン用に設計すると、アランクーパーが本書で「実装モデル」と呼ぶものへの素早い軌道に乗ることができます。受刑者が精神病院を運営している. 。その結果、ユーザーインターフェイスは直感的ではなく、使いにくくなります。

37signals は、最初にユーザーインターフェイスを設計することも推奨しています。現実になる. 。あらゆる意味で、ほとんどのアプリケーションでは、ユーザーインターフェイスがはプログラム。バックエンドコードはそれをサポートするために存在します。

おそらく、最初にコマンドラインから開始して、機能が正しいことを確認することをお勧めします。メインユーザーがコマンドラインを使用できない (または使用しない) 場合は、作業内容に GUI を追加できます。

これにより、アプリはスクリプト作成にさらに適したものになり、前払い額も制限されます。自転車置場実際の解決策に早く到達できるようになります。

アプリのコマンドラインバージョンを保持する予定がある場合は、この方法で問題ないと思います。時間の無駄ではありません。最終的にはアプリの主要な機能をコマンドライン用にコーディングすることになるため、作業の大部分が完了することになります。

この方法で作業することが、優れた UI を実現するための障壁になるとは思いません。UI を追加する時間はまだあり、make は使用可能になります。

この作業方法が実際に機能するのは、完成したアプリにコマンドラインと GUI の両方のバリエーションを持たせるつもりの場合だけだと思います。UI をモックしてそこに機能を構築し、後で UI を美しくするのは簡単です。

スチュさんの意見に同意:基本機能は、コマンドラインおよび GUI コードから呼び出されるライブラリ内にある必要があります。UI から実行可能ファイルを呼び出すと、実行時に不要なオーバーヘッドが発生します。

@jcarrascal

なぜこれによって GUI が「悪く」なるのかわかりません。
私の考えでは、物事がきれいであることをあまり心配せずに、「ビジネス」ロジックが実際に何を達成する必要があるかを考える必要があるということです。何をすべきか/何ができるかを理解したら、最も理にかなった方法でそれを中心にインターフェイスを構築できます。

サイドノート：別のトピックを開始するわけではありませんが、質問への回答やコメントに対処するための望ましい方法は何ですか?私はこれと質問自体を編集することの両方を検討しました。

私が作成した 1 つのツールでまさにこれを実行したところ、うまくいきました。最終的には、GUI 経由でも使用できるスクリプト可能なツールが得られます。

GUI が使いやすく直感的に使えるようにすべきだという意見には私も同意します。そのため、両方を同時に開発することさえ賢明かもしれません...直感的に操作できるように、小さなコマンドライン機能とそれに続く GUI ラッパーが追加されています。

両方を同等に実装することに忠実であれば、その結果、自動化された方法で使用できるアプリが得られます。これはパワーユーザーにとって非常に強力だと思います。

私は通常、クラスライブラリと、別個の非常にくだらない基本的な GUI から始めます。コマンドラインにはコマンドラインの解析が含まれるため、不必要なオーバーヘッドが大量に追加されているように感じます。

おまけに、すべての「実際の」コードはクラスライブラリ内にあるため、MVC のようなアプローチが得られます。もちろん、後の段階で、ライブラリを実際の GUI とともに 1 つの EXE にリファクタリングすることもオプションです。

開発を正しく行えば、プロジェクトの後半で GUI に切り替えるのは比較的簡単です。問題は、それを正しく理解するのが少し難しいことです。

プログラムの目標によって多少異なりますが、私は時々これを行います。コードを書くのが速く、デバッグが簡単で、簡単で汚いテストケースを書くのが簡単です。そして、コードを適切に構造化している限り、それほど多くの作業を行わずに、後で戻って GUI を追加することができます。

この手法がひどい、使い物にならない UI をもたらすと示唆している人たちへ:あなたが正しい。コマンドラインユーティリティを作成するのは、GUI を設計するのにひどい方法です。次のような UI を書こうと考えている人は注意してください。 そうではありません CLUI - CLUI としてプロトタイプを作成しないでください。

しかし、 UI に依存しない新しいコードを作成している場合, 、それではどうぞ。

より良いアプローチは、明確に定義された API を備えたライブラリとしてロジックを開発し、開発段階ではインターフェイスなし (またはハードコードされたインターフェイス) で、後から CLI または GUI を作成することです。

いくつかの理由から、私はこれをしません。

デザイン：

GUI と CLI は、基礎となる実装にアクセスするために使用される 2 つの異なるインターフェイスです。これらは通常、さまざまな目的に使用され (GUI はライブユーザー用、CLI は通常スクリプトによってアクセスされます)、さまざまな要件を持つことがよくあります。この 2 つを組み合わせるのは賢明な選択ではなく、将来必ず問題を引き起こすことになります。

パフォーマンス：

あなたが物事を説明した方法では、GUI が何かを行う必要があるたびに実行可能ファイルを生成する必要があります。これはまったく醜いです。

これを行う正しい方法は、CLI と GUI の両方によって呼び出されるライブラリに実装を置くことです。

John Gruber は、GUI 用に設計されていないプログラムに GUI を追加するという概念について、優れた投稿を行っています。ロンコスプレーオンの使用感

まとめ：それは機能しません。ユーザビリティが最初からアプリケーションに組み込まれていない場合、後から追加するのは誰もがやりたがる以上に大変な作業です。

@モーディット

コマンドラインアプリは事前にパラメータをチェックしますが、GUI はチェックしません。ただし、引き続きパラメータをチェックします。同じ params を作成し、それらをいくつかの汎用ワーカー関数に入力します。

それでも目標は同じです。コマンドラインのバージョンが GUI の品質に影響を与えるとは思えません。

Web サービスとして公開するプログラムを実行します。次に、GUI とコマンドラインを実行して、同じ Web サービスを呼び出します。このアプローチにより、Web GUI を作成したり、機能を SaaS としてエクストラネットパートナーに提供したり、ビジネスロジックのセキュリティを強化したりすることもできます。

これにより、プログラムがより簡単に SOA 環境に参加できるようになります。

Web サービスの場合は、やりすぎないでください。yaml または xml-rpc を実行します。単純にする。

それに加えてスチュ共有ライブラリを使用すると、Web アプリケーションからも使用できるようになります。または IDE プラグインからでも。

この方法が得策でない理由はいくつかあります。多くのことが言及されているので、ここでは 1 つの特定の点に限定します。

コマンドラインツールは通常、まったく対話的ではありませんが、GUI は対話的です。これは根本的な違いです。これは、たとえば、長時間実行されるタスクにとっては苦痛です。

コマンドラインツールは、せいぜい何らかの進行状況情報 (改行、テキストの進行状況バー、大量の出力など) を出力する程度です。あらゆる種類のエラーはコンソールにのみ出力されます。

その上に GUI を追加したい場合はどうしますか?長時間実行されるコマンドラインツールの出力を解析しますか?その出力内の警告とエラーをスキャンして、ダイアログボックスを表示しますか?

この方法で構築されたほとんどの UI では、せいぜい、コマンドが実行されている間は脈動するビジーバーが表示され、コマンドが終了すると成功または失敗のダイアログが表示されます。悲しいことに、このように多くの UNIX GUI プログラムが組み合わされており、ユーザーエクスペリエンスがひどいものになっています。

ここでの回答者のほとんどは、プログラムの実際の機能をライブラリに抽象化し、それに対してコマンドラインインターフェイスと GUI を同時に作成する必要があると言っていますが、それは正しいです。すべてのビジネスロジックはライブラリに含める必要があり、いずれかの UI (はい、コマンドラインは UI) は、ビジネスロジックと UI の間のインターフェイスに必要なことのみを行う必要があります。

コマンドラインは、後で GUI で使用するのに十分なライブラリを開発するには不十分な UI です。最初から両方から始めるか、GUI プログラミングから始める必要があります。GUI 用に開発されたライブラリにコマンドラインインターフェイスを追加するのは簡単ですが、その逆は非常に困難です。GUI にはすべての対話型機能 (レポート、進行状況、エラーダイアログ、i18n など) が必要になるためです。 )

コマンドラインツールは、GUI アプリよりも生成するイベントが少なく、通常は開始前にすべてのパラメーターをチェックします。これにより、GUI が制限されます。GUI の場合、プログラムの動作時またはその後にパラメータを要求する方が合理的になる可能性があるためです。

GUI を気にしないのであれば、気にする必要はありません。最終結果が GUI になる場合は、最初に GUI を作成してから、コマンドラインバージョンを実行します。あるいは、両方を同時に取り組むこともできます。

--大規模編集--

現在のプロジェクトにしばらく時間を費やした後、前の答えから一周したように感じます。最初にコマンドラインを実行してから、それに gui をラップする方が良いと思います。必要に応じて、後で素晴らしい GUI を作成できると思います。最初にコマンドラインを実行すると、すべての引数が最初に取得されるため、UI/UX を実行するときに (要件が変更されるまで) 驚くようなことはありません。

それはまさに、コーディングに関する私にとって最も重要な認識の 1 つであり、より多くの人がそのようなアプローチを採用することを願っています。

簡単な説明が 1 つだけあります。GUI はコマンドラインのラッパーであってはなりません。代わりに、GUI またはコマンドラインからプログラムのコアを駆動できる必要があります。少なくとも最初と基本操作だけは。

これが素晴らしいアイデアになるのはいつですか?

ドメインの実装が GUI フレームワークから独立していることを確認したい場合。コーディングしたい その周り 枠組みではない の中へ 枠組み

これはどのような場合に悪い考えでしょうか?

自分のフレームワークが決して死なないと確信できるとき

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow