GUIから開始してアプリケーションを構築すると便利ですか？

アプリケーションの設計と開発の傾向は、「ガッツ」から始まっているようです。ドメイン、データアクセス、インフラストラクチャなどです。通常、GUIはプロセスの後半に来るようです。最初にGUIを構築するのが役に立つのではないかと思います...

私の理論的根拠は、少なくともプロトタイプGUIを構築することで、舞台裏で何が起こる必要があるかをよりよく理解できるため、ドメインとサポートコードで作業を開始するためのより良い位置にいるということです。

サポートコードがまだ記述されていない場合、GUIレイヤーが実際に行うことはあまりないという点で、このプラクティスの問題を見ることができます。おそらく、モックオブジェクトまたはスローアウェイクラス（ユニットテストで行われているようなもの）を構築すると、最初にGUIを構築するのに十分な基盤が提供されます。

これは実際のプロジェクトにとって実行可能なアイデアかもしれませんか？GDD（GUI Driven Development）を頭字語stableに追加できるかもしれません...

高速なGUIプロトタイプを構築することは良いアイデアであり、多くのプロジェクトで使用されていると聞いています。早期のフィードバックは確かに貴重です。ただし、次のような危険があります。

• プロトタイプコードをさらに使用して最終アプリケーションを構築することは（マネージャー/ユーザーにとって）非常に魅力的です。これは非常に長期的な結果を招く可能性があります（これは実際に私が取り組んできたプロジェクトの1つで起こり、存在しないアーキテクチャと私たちのための多くのメンテナンスの頭痛の種の「動作する」製品）
• 平均的なユーザーの場合、GUIはアプリケーションです。したがって、見栄えの良いGUIを見ると、実際の作業の大部分が完了したと考える傾向があるため、「少し残った作業」が非常に長くドラッグされることに非常に怒ってしまう可能性があります。

これらのリスクを軽減するには、積極的な議論と、場合によってはユーザーやマネージャーの教育が必要です。

それに関して私が見る問題は、目標が完全に後方にあるように見えることです。

「私は、少なくともプロトタイプGUIを構築することで、舞台裏で何をする必要があるかをよりよく理解できるので、ドメインとサポートコードで作業を開始するためのより良い位置にいるということです。」

私の意見では、これはビジネス層を見る間違った方法であり、貧弱で拡張不可能なデザインを見つける素晴らしい方法です。データを完全に表現するように設計されたデータレイヤーは、どのUIでも使用できます。特定のUIのニーズに合わせて機能するように設計されたデータレイヤーは、他の何にも適応できず、そのUIに小さな機能が追加されることさえありません。

あなたが話している方法で設計されたシステムの経験から、この方法論を使用するほとんどの設計は短命であるか、複雑すぎると結論付けられます。また、UIとデータレイヤーとの間にカップリングを作成する傾向があります。

データ層とUI層の独立を奨励する必要があります。これが、特定のUIをターゲットにするのではなく、単にデータ全体を表すようにデータレイヤーを構築することが、長期的に見ればうまく機能する理由です。

プロトタイプを作成することは、要件の収集と合意に役立ちますが、その後は破棄する必要があります。実際の製品では、プロトタイプコードの何も実際に使用しないでください。

@Péterは、GUIプロトタイプを構築することをお勧めするのが正しいと思います。私は、ユーザーエクスペリエンスを後向きに提供するという潜在的な落とし穴を補完したいと思います。つまり、最初にオントロジー、アーキテクチャ、インフラストラクチャに焦点を当て、最後に即時のユーザーエクスペリエンスに焦点を当てます。

• 開発タイムラインの最後までプッシュしたユーザーは、データの見積もりとアプリケーションの使用方法を無効にします。
• 時期尚早に開発した精巧なデザインは、最終的にはほとんどまたはまったく役に立たない自己目的の策略であることを証明しています。
• あなたのアプリケーションは、貧弱なユーザーエクスペリエンスの提供が標準となるような状態になる可能性があります。

あなたは勇気を出すと、ユーザーはあなたの仮定から出てきたものを手に入れますが、ユーザーが必要とするものに関心を持ち、それに応じて勇気を構築する必要があります。人々が別の方法でそれを行う理由は、単純に、ユーザーの対話するプレゼンテーションが、アプリケーションの動作が自然に発生するため、システムの最も複雑な部分であり、完全に探索されないか、人々が非常に感じるからです。実際に彼らがそれを構築している理由/何/誰のために考えなければならないことを避けて物事を構築することに自分自身について幸せです。構造的に健全な巨大な構造物を建てることは子供の遊びであり、すべての人の機能的（および審美的）ニーズを満たすためにそれを取得することは最も難しい部分です。

あなたが尋ねるために懇願してきたときに、各craptastic経験、風変わりな流れ、悪い併置情報については、明白な機能のインスタンスを単純に間違っているものが欠けている「と思いついただけでその天才その？」、嘘を無視することを何か、否定かユーザーを開発努力の最前線として開示しました。

一般に、モデルはビューの前に開発する必要があります。アプリケーションの論理的な基盤を確立したら、そのモデルの1つ以上のビューを作成できます（たとえば、データを表またはグラフで表示できます）。通常、モデルはGUIよりも重要です。これは、GUIが通常標準的な方法で行われるエンタープライズ開発に特に当てはまります。

ただし、GUIがアプリケーションの最も重要な部分である場合があります。斬新で具体的な方法でデータを確認したい場合があります。そこからデータを取得して、モデルを開発します。たとえば、CashCurveは、ポイントがGUIにあるようなアプリケーションですが、データモデル自体は、誰でも数分でモデル化できる標準的な退屈なものです。（免責事項：私はCashCurveと提携しておらず、非常に満足しているユーザーです。）

これは、Webサービスまたは他のAPIの設計にも関連します。「契約優先」設計として知られているのはそこだけです。

したがって、すべてに関して、最初に何を設計するかについてのルールはありません。モデルの場合もあれば、GUIの場合もあります。経験則として、「最初に最も重要な部分を設計する」ことにします。

GUIを最初に設計する際に考慮すべき注意事項があります。たとえば、GUIプロトタイプのみが存在する場合、ユーザーはアプリケーションの完成には程遠いことを理解するのに苦労するでしょう。

特にアジャイル開発環境では、アプリケーション設計にアプローチする非常に良い方法だと思います。私が取り組んだ成功したプロジェクトのほとんどは、最終的に本物になったプロトタイプから始まりました。

GUIはシステム（つまり、データベース、ファイルシステムなど）へのウィンドウであることを理解する必要があります。プロジェクトの要件がスラッシュの山と同じくらいあいまいな状況では、バックエンドから開始して正しいソリューションを得ることに地獄の希望はありません。ほとんどの場合、意図的に設計されたバックエンド開発者は、ユーザーの操作に関係のないAPIを多数開発します。

GUIを起動することで、顧客は自分が望むものについてより良いアイデアを得ることができます。この段階が進むにつれて、GUIの開発（モックとスタブを使用）がドメインモデルを生み出します。その後、このドメインモデルをバックエンドに転送し、バックエンドの開発者が永続性とトランザクションロジックの開発を開始できます。

そして、なぜあなたはプロトタイプを捨てたいのですか？私たちはマッチスティックで作られたスタジアムを扱っていません。いまいましいことを良いものにリファクタリングするだけです。

GUIを見ている人がそれが単なるシェルであり、ボタンとプロセスが文字通り機能しないことを理解している場合は、まったく悪いことではありません（新しいNotImplementedException（）;;）をスローします）。

MVCスタイルのアーキテクチャの使用に固執する場合、「ビュー」はそのようなことをまったく定義しないため、将来のメンテナンスや構築の問題は予見できません。「コントローラ」と「モデル」は、スケーラビリティ/設計のニーズなどに必要なインフラストラクチャに後で付属します。

管理については、3つの部分からなる大きな円グラフを描き、「M」、「V」、「C」というラベルを付けます。Vに約20％を与え、パイの残りが「TBC」であることを説明してください;）。

合理的なサイズのシステムでは、舞台裏で何をする必要があるかは、GUIの外観と大まかに関係しています。GUIは要件の一部のみを提供します。多くの場合、GUIを持たないコンポーネントが多数あります。

システムが開発された後、追加のインターフェイス（新しいGUIを含む）が必要になる場合があります。これを成功させるには、ビジネス要件を理解して実装することが重要です。

GUIやその他の入出力メカニズムの設計が役立つのは、モデルの検証です。出力されることのない属性は必要ない場合があります。（それらを保持する理由があるかもしれませんが、それらはおそらく監査または規制当局の要件になるでしょう。）

他の人が言ったように、GUIが機能するようになれば、多くのクライアントは完了したと思うでしょう。ただし、背後にインフラストラクチャがない場合があります。紙のプロトタイプは、GUIのレイアウトとコンテンツを検証するのに適したオプションです。

開発後にインターフェースを調整する必要があるかもしれないことを忘れないでください。5ステップのチェックアウトプロセスで、チェックアウトインターフェイスの交換に失敗したという報告を受けています。はるかに単純なインターフェースは、ユーザーに適切なセキュリティ感を与えず、完了率がはるかに低かった。Speed Bumps：The Magical Ingredient in Marketingを聞いてください。