最初にフロントエンドまたはバックエンド。良いシステム設計の実践である二つのうち？
現在、就学登録システムの開発を求めているクライアントがいます。今、これはこの種の挑戦をするのは初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。
あなたのほとんどが複雑なソフトウェアを作成したことを私は知っています。最初にフロントエンドまたはバックエンドを設計する必要がありますか？
ありがとう！
さっきインターネットで見つけた記事のまとめです。共有したいだけ
http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157
フロントエンド開発者とバックエンド開発者の比較（私の意見）
私の個人的な見解
繰り返しますが、それはトレーニングの問題であり、いくつかの広範なストロークの一般化です。
フロントエンド開発者
- 通常、CSの学位を取得していないか、3層の学校でCSの学位を取得しています。
- 基本に似た言語で作業する（PHPは基本）を参照）
- PhotoshopドキュメントをCSS/HTMLなどに変換する視覚的なスキルがある。
- タイプフリー言語のため、反復プログラミングに対する高い許容度があります
バックエンド開発者
- CSの学位または多くの経験を持っている
- 彼らの問題解決アプローチで私にもっと体系的になる傾向があります
- 漏れている1つのオブジェクトを見つけるのに何日も費やしてもかまいません
- 問題を解決するためのツールを試して構築する
後ろから始めて前に進むと、クライアントを誤解する危険があります。あなたは彼らが簡単に見ることも理解することもできないものを作成することになるので、あなたが要件を満たしているかどうかを検証することに、彼らは非常に簡単に参加することはできません。つまり、多くの作業を無駄にする可能性があります。
前面から開始して後退すると、画面上に単純なフォームを描画するだけで、クライアントはそれがほぼ完了したと考えるリスクがあります。あなたはそれが数日でほとんど終わっていたので、彼らはそれからなぜそれがそんなに時間がかかるのか疑問に思うかもしれません。また、フロントエンドとバック結婚するために複雑な作業を行わなければならないことに気づいたとき、より適切なフロントエンドの方がシンプルだったとしたら、自分を隅に塗るリスクを冒します。
IMO、機能優先で作業する必要があります。システムの機能ごとに、フロントエンドとバックエンドを一緒に記述します。これにより、クライアントに進行状況の可視性が高まり、あまり苦痛を与えることなく、「いいえ、それは私が意図したものではありません」と言う機会が与えられます。
とはいえ、これが非常に大規模なプロジェクトであり、サーバーハードウェアまたは依存するソフトウェアの機能（たとえば、使用しているデータベース）を考慮する必要がある場合は、最初にその部分について十分に検討する必要があります。
ソフトウェアには多くの側面があるため、過度に単純化した表と裏を対比することはよくない質問であり、賢明で有用な答えを提供することは非常に困難です。
1つのビューは、データの静的構造です。このビューには少なくとも3つの側面があります。それは、アーキテクチャー層（「前から後ろ」）、ユースケースとアクター、および実装のコストまたはリスクです。
1つのビューは、処理の動的な構造です。このビューには、少なくとも3つの次元があります。
3番目のビューは、自然にレイヤーに分類され、ユースケースをサポートし、コストとリスクを伴うアーキテクチャコンポーネントです。
続けられますが、ポイントはこれです。
フロントエンド開発者とバックエンド開発者（私の見解）
問題を調べるのに最も役に立たない方法です。ここでは、実際の開発者とその意見はほとんど関係ありません。重要なことは
ユースケースとアクター
これらのユースケースをサポートする論理データモデル
ユースケースの一部として行われるプロセス
ユースケースの論理要素と処理要素を構築するために使用するコンポーネント。
これが、ユーザーストーリーまたはユースケースによってシステムを分解する必要があると多くの人が言う理由です。
開発を行う予定の人について、脳卒中の一般化を行わないでください。
どちらでもない。アプリでできることは何ですか？高温のバルブが温水を供給し、低温のバルブが冷水を供給し、最初に水が流れること、必要に応じてパイプを延長して、家のすべての部屋に実際の配管を実装すること、または家が何をするかを心配することを確認してください実際には正確に似ています。
フロントエンドは、いくつかのスイッチとレバーが付いた単なるマスクです。バックエンドは、データを取得して処理するリクエストを受け取るものにすぎません。最初に、両方を任意の組み合わせで迅速に実装できるようにします。
しかし、あなたが何をするにせよ、一方の設計が他方の設計に影響を与えないようにしてください。そのように狂気はあります。
開発者が何度も気が変わっても、クライアントに必要なものを何でも構築できるツールを用意します。次に、それを仕様に合わせて構築し、小さなカスクが最終的に満足するまで再調整します。
また、2008年にフロントエンド開発者とバックエンド開発者を比較することは、Web時代ではかなり昔のことです。面白さのために、質問にリンクしているので、古い栗にいくつか修正/追加したいと思いますが、（うまくいけば）いくつかのヒントを埋め込んでいます：
フロントエンド開発者
通常、CSの学位を取得していないか、3層のCSの学位を取得しています。
手のショー。 CSの学位を持つ何人の人々がフロントエンドでベストプラクティスを教えられましたか？それともJavaScriptで混乱しないようにするには？または、IE6-IE9からCSSの問題を処理する方法は？アカデミアを運営する教科書業界は、怠惰で肥大化し、絶えず変化するテクノロジーを処理することができないため、大学では「深刻な」注目をほとんど受けていません。これは、私のような後期ブルーマーにとっては素晴らしいことです。
基本に類似した言語で作業します（PHP is Basic）を参照）
PHPはクライアント側のテクノロジーですか？）または、主にSchemeから着想を得たJavaScriptは、BasicよりVisual Basicと共通しているため、フロントエンドではもはや問題ではなくなり、本当にありましたが、バックエンド.NET Webアプリケーションでまだ利用できますか？このブログでは、独学のオープンソースWeb開発者と、企業で人気の高い技術を使用しているCS卒業生Web開発者を比較しています。その特定の戦いの両側で共有しますが、彼はまだ道OTそこにいます。
photoshop文書をCSS/HTML/etcに変換する視覚的なスキルがある
少し広い「ビジュアルスキル」よりも細部に注意を向けます。私たち全員が美的デザインのスキルを持っているわけではありません。しかし、はい、私たちのほとんどはこのことをジュニアレベルで学ぶ必要があり、CSSメスが行うときにJSハンマーを使用しない優れたUIを作成することは、実際には非常に完全に重要です。
型自由言語のため、反復プログラミングに対して高い許容度があります
これが、先に述べた部分を最初に配置したい理由です。押されたボタンを渡し、商品を生産/回収します。梱包してお届けします。これらの事柄が何らかの方法で互いに強く結び付けられる理由はありません。また、本当にOOPをしゃべらなければ、厳密なタイピングは反復プロセスを妨げるべきではありません。しかし、悪臭があったとしても、フロントエンドは予測可能なアクセスポイントしか必要とせず、JSON以外のJavaScriptを動的に記述するような愚かなことをしない限り、バックエンドで必要なことを何でも実行できます。または、成功したバックエンドの動作をHTML構造に「そのまま」と強く結び付けます。* cough * Java devs */cough *
これに対する単一の正しい答えはありません。どちらの方法も、特定の状況では良い（そして悪い）場合があります。
（受け入れと単体）テストによってリードされるTDDアプローチを検討することをお勧めします。
まず、システムのスケルトンを組み立てることから始めます：最小限の機能を備えた基本的なインフラストラクチャ。これは、コンセプトが機能し、さまざまなコンポーネントが連携できることを示すためだけのものです。これには最低限のUI（該当する場合）も含まれます。これは、実際に実行したり、最小限のものを表示したりするのに十分です。
次に、詳細を具体化し、機能ごとに機能を追加します：特定の機能/シナリオの受け入れテストを記述し、それを失敗させ、それを満たすコードを記述します。これにより、外側から内側に向かって作業します：システムは入力メッセージを受け取るため、そのメッセージを処理/変換し、それを使って何かを行う必要があります。結果をUIに反映します。途中で、ドメインの概念を発見し、UIからドメインレイヤーに、そしてその逆に、新しいクラスでそれらを表現します。
このアプローチの場合、推奨される読み物は Growing Object-Oriented Software、Guided by Tests です。
最初にAPI
両方のチームのエンジニアが、フロントエンドとバックエンドの間のAPIで共同で作業する必要があります。その後、両方のチームが設計されたAPIに基づいて作業を開始できます。これには、チームが並行して作業を開始できるという明らかな利点に加えて、別のフロントエンドチームも作業を開始できる（Webクライアントの後にモバイルの可能性がある）という利点があります。
反復アプローチと組み合わせると、次のようになります。
- シンプルなAPIを設計する
- 両方のチームがAPIに基づいて開発とテストを行います
- 統合テスト
- クライアントに見せて、フィードバックを受け取ります。
- APIを拡張して繰り返します。
フロントエンドから始めますが、まず、なぜ彼らはすでに存在するアプリケーションを見つけられないのでしょうか？これにより、このプロジェクトについてさらに洞察が得られます。彼らはいくつかのユニークな要件を持っていますか、それともあなたはより安価に構築できると思いますか？
彼らのセキュリティの期待と法律が要求するものを完全に理解してください。学校の種類はわかりませんが、生徒の情報には通常、ある程度の機密性が要求されます。
潜在的な学生がWebサイトにデータを入力する場合、グラフィックデザインはさらに問題になります。
彼らの要求に基づいて、フロントエンドのモックアップを描きます。 GUIが真っ向から進んでいないと思われる場合は、何かを機能的にして、動作を確認できるようにする必要がある場合があります。彼らは、登録をデータ入力に基づいて異なる方向に分岐するある種の「ウィザード」と見なす場合があります。
次に、データベースに永続化された情報の取得を開始できます。
私のコメントを拡大する：
最初に要件を収集し、次にそれらをユースケースと設計に変えます。
最初に、詳細なデータベース定義を示します。クライアントがそれを完全に理解していなくてもかまいません、私は彼らに座ってそれを見るように強制します-そしてそれをサインオフします（おそらくその後、彼らのより技術に詳しい人の1人がそうするべきであることに気づかせるよう強制します） ）、続行する前に。
どのようにして、BEなしでFEから始めることができますか？何のためのFE ???データベースを定義してください!!それがFEの操作です。
さて、問題とその後の微調整があるでしょう、そして私はdoクライアントの前でシンプルなサンプルのGUIをできるだけ早く取得するのが良いことに同意します。ほとんどが理解しています。
しかし、私は1）stressこれは、ネズミイルカのためのラフなモックアップにすぎないこと、および2）意図的に醜くするしかし機能的 、理解できない人は、その入力ボックスを幅400pxで、背景を水色にするように細工して指示することができます。
ここでのほとんどの回答（および私はそれらをフォローしています）は顧客に集中しすぎる傾向があると思いましたが、純粋にソフトウェアの観点から、最初にBEを操作するためのFEを設計することはできないと私は主張しますそのBEを設計します。
はい、OPがしばらく前に尋ねたことに気付きました。バックエンドから始めますが、フロントエンドをMOCK UPして、ユーザーがあなたの想像したことを確認できるようにします。フロントエンドは、それが価値があるすべてのために、ただの鐘と笛です。バックエンドはお金がどこにあるかであり、あなたがそのストレートを持ったら、FEは肉の上にある肉汁だけです。