language-agnostic - 最初にコマンドライン用に開発することについてどう思いますか？

Question

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

例えば。

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

いくつかの検証を行い、データベースに会議をスローするという関数をロードtodo.exeして呼び出します。AddTask

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

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

イベント：[ジョンとのミーティング、再：ログインピアレビュー]

場所：[ジョンのオフィス]  

日付：[金 2008年8月22日]  

時間：[午後2時]

[クリア][送信]

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

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

これは考慮されますか：

コーディングするのに良い方法
初心者のためだけに
恐ろしい！

補遺：

ここで、「GUIとCLIの両方の実行可能ファイルによって呼び出される共有ライブラリ」の傾向に気づいています。バイナリ自体のサイズ以外に、それらを分離する必要があるという説得力のある理由はありますか？

同じ実行可能ファイルをさまざまな方法で呼び出すだけではどうでしょうか。

"todo /G" フルオンのグラフィカルインターフェイスが必要な場合
"todo /I"内のインタラクティブプロンプトの場合todo.exe（スクリプトなど）
"todo <function>"あなたがただ一つのことをしたいだけでそれでやりたいときは、昔ながらのことです。

補遺2：

「[私が]説明したように、GUIが何かをする必要があるたびに実行可能ファイルを生成する必要がある」と述べられました。

繰り返しますが、これは私の意図ではありませんでした。例のGUIが「同じAddTask機能」と呼ばれると言ったとき、私はGUIが毎回コマンドラインプログラムを呼び出すという意味ではありませんでした。私はそれが完全に厄介になることに同意します。小さな例であるため、これをすべて単一の実行可能ファイルに保持することを意図していましたが（最初の補遺を参照）、私の言い回しが必ずしも共有ライブラリを排除しているとは思いません。

また、皆様のご意見に感謝申し上げます。これは私の心に浮かび上がるものであり、あなたの経験の知恵に感謝します。

score 16 · Accepted Answer

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

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

しかし、機能コードがコマンドラインインタープリターから分離されている限り、一度に 2 種類の操作を実行することなく、GUI のソースを再利用することができます。

score 7 · Accepted Answer

共有機能をライブラリに配置し、コマンドラインとそのGUIフロントエンドを記述します。そうすれば、レイヤー遷移がコマンドラインに関連付けられません。

（また、この方法は別のセキュリティ上の懸念を追加します。GUIは、最初に、呼び出されているのが正しいtodo.exeであることを確認する必要がありますか？）

score 5 · Accepted Answer

Joelは、この（ "unix-style"）開発とGUIファースト（ "Windows-style"）メソッドを数年前に対比した記事を書きました。彼はそれをバイカルチャーリズムと呼んだ。

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

score 5 · Accepted Answer

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

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

score 3 · Accepted Answer

開発しているアプリケーションの種類によって異なると思います。コマンドライン用に設計することで、Alan Cooper がThe Inmates are Running the Asylumで「実装モデル」と呼んでいるものへの近道を歩むことができます。その結果、直感的ではなく、使いにくいユーザーインターフェイスが作成されます。

37signals は、 Getting Realで最初にユーザーインターフェイスを設計することも推奨しています。すべての意図と目的において、ほとんどのアプリケーションでは、ユーザーインターフェイスがプログラムであることを忘れないでください。バックエンドコードは、それをサポートするためのものです。

score 2 · Accepted Answer

機能が正しいことを確認するために、最初にコマンドラインから始める方がおそらく良いでしょう。メインユーザーがコマンドラインを使用できない（または使用しない）場合は、作業の上にGUIを追加できます。

これにより、アプリがスクリプト作成に適したものになるだけでなく、事前のBikesheddingの量が制限されるため、実際のソリューションにすばやく到達できます。

score 2 · Accepted Answer

アプリのコマンドラインバージョンを維持することを計画している場合、この方法で問題が発生することはありません。時間の無駄ではありません。それでも、コマンドライン用にアプリの主な機能をコーディングすることになり、作業の大部分が完了します。

このように機能することが、優れたUIの障壁になるとは思いません。まだ、UIを追加して、使用可能にするなどの時間があります。

この作業方法は、完成したアプリにコマンドラインとGUIの両方のバリエーションを持たせる場合にのみ実際に機能すると思います。UIをモックして機能を組み込み、後でUIを美化するのは簡単です。

Stuに同意します。基本機能は、コマンドラインおよびGUIコードから呼び出されるライブラリに含まれている必要があります。UIから実行可能ファイルを呼び出すことは、実行時に不要なオーバーヘッドです。

score 2 · Accepted Answer

@jcarrascal

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

補足: 別の話題を始めるつもりはありませんが、あなたの質問への回答/コメントに対処するための好ましい方法は何ですか? 私はこれと質問自体の編集の両方を検討しました。

score 2 · Accepted Answer

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

GUI が簡単で直感的に使用できるようにする必要があるという意見には同意します。そのため、両方を同時に開発することも賢明かもしれません...簡単なコマンドライン機能とそれに続く GUI ラッパーを使用して、確実に実行できるようにします。物事を直感的に。

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

score 1 · Accepted Answer

ちょっとプログラムの目標によって異なりますが、そうです、私は時々これを行います-コーディングが速く、デバッグが簡単で、迅速で汚いテストケースを書くのが簡単です。そして、コードを適切に構造化する限り、あまり手間をかけずに、後でGUIに戻って取り組むことができます。

この手法が恐ろしくて使用できないUIになることを示唆している人には、その通りです。コマンドラインユーティリティを作成することは、GUIを設計するためのひどい方法です。CLUIではないUIを作成することを考えている人は誰でも、CLUIとしてプロトタイプを作成しないでください。

ただし、それ自体がUIに依存しない新しいコードを作成している場合は、それを選択してください。

score 1 · Accepted Answer

より良いアプローチは、適切に定義された API を使用してロジックを lib として開発し、開発段階ではインターフェース (またはハードコーディングされたインターフェース) を使用せず、後で CLI または GUI を作成することです。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

John Gruber は、GUI 用に設計されていないプログラムに GUI を追加するという概念について、良い記事を書いています: Ronco Spray-On Usability

まとめ：うまくいきません。ユーザビリティが最初からアプリケーションに設計されていない場合、後でそれを追加することは、誰もが望んでいる以上の作業です。

score 1 · Accepted Answer

私はいくつかの理由でこれを行いません。

デザイン：

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

パフォーマンス：

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

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

score 1 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

Web サービスについては、行き過ぎないでください。yaml または xml-rpc を実行します。複雑にしないでおく。

score 0 · Accepted Answer

Stuが言ったことに加えて、共有ライブラリを持つことで、Web アプリケーションからも使用できるようになります。またはIDEプラグインからでも。

score 0 · Accepted Answer

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

GUI を気にしない場合は、気にしないでください。最終結果が gui になる場合は、最初に gui を作成し、次にコマンドラインバージョンを作成します。または、両方を同時に処理することもできます。

--大量編集--

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

score 0 · Accepted Answer

@モーディテ

コマンドラインアプリは事前にパラメーターをチェックしますが、GUI はチェックしませんが、同じパラメーターをチェックし、いくつかの一般的なワーカー関数に入力します。

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

score 0 · Accepted Answer

この方法が良くない理由はいくつかあります。それらの多くが言及されているので、1つの特定のポイントに固執します.

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

コマンドラインツールは、せいぜいある種の進行状況情報 (改行、テキストの進行状況バー、一連の出力など) を出力するだけです。

その上に GUI を追加したいのですが、どうすればよいでしょうか? 実行時間の長いコマンドラインツールの出力を解析しますか? その出力で WARNING と ERROR をスキャンして、ダイアログボックスを表示しますか?

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

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

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

language-agnostic - 最初にコマンドライン用に開発することについてどう思いますか？

21 に答える 21

Related

Reference