フロントエンドが最初かバックエンドが最初です。良いシステム設計の実践である2つのうち？

現在、私はクライアントに学校入学システムの開発を要求しています。今、これはこの種の挑戦をしている私にとって初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。

私はあなたのほとんどすべてが複雑なソフトウェアを作成したことを知っています。これについてあなたのアドバイスが欲しいです。最初にフロントエンドまたはバックエンドを設計する必要がありますか？

ありがとう！

ここに、私が少し前にインターネットで見つけた記事の結論があります。共有したいだけ

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

フロントエンド開発者とバックエンド開発者（私の意見）

私の個人的なテイク

繰り返しますが、それは訓練の問題であり、いくつかの広範なストロークの一般化です：

フロントエンド開発者

• 通常、CS学位を取得していないか、3級学校のCS学位を取得していません。
• 基本に似た言語で作業する（PHP is Basicを参照）
• フォトショップドキュメントをCSS / HTML /などに変換する視覚的なスキルを持っている。
• 型のない言語のため、反復プログラミングに対して高い許容度を持っている

バックエンド開発者

• CSの学位または豊富な経験がある
• 問題解決のアプローチをより体系的にする
• 漏れているオブジェクトを見つけるのに何日も費やすことを気にしないでください
• 問題を解決するためのツールを試してビルドする

後ろから始めて先に進むと、クライアントを誤解する危険があります。簡単に見たり理解したりできないものを作成するため、要件を満たしているかどうかの検証に参加するのは簡単ではありません。これは、多くの作業を無駄にする可能性があることを意味します。

前面から始めて後方に進むと、画面に単純なフォームを描くだけで、クライアントがほぼ完了したと考えるリスクが生じます。数日でほぼ完成したので、なぜそんなに時間がかかっているのか疑問に思うかもしれません。また、より適切なフロントエンドがより単純な場合、前面と背面を結婚させるためにいくつかの複雑な作業を行う必要があることに気付いたときに、コーナーに自分自身をペイントするリスクもあります。

IMO、機能を優先して作業する必要があります。システムの機能ごとに、フロントエンドとバックエンドを一緒に記述します。これにより、クライアントは進捗状況をより明確に把握できるようになり、あまり苦痛を感じることなく、「いいえ、それは私が意図したことではない」と言う機会を与えられます。

ただし、これがサーバーハードウェアや依存するソフトウェアの機能（使用しているデータベースなど）を考慮する必要がある非常に大きなプロジェクトである場合は、まずその部分について十分に検討する必要があります。

ソフトウェアには多くの側面があります。したがって、過度に単純化された前部対後部は貧弱な質問であり、賢明で有用な答えを提供することは非常に困難です。

1つのビューは、データの静的構造です。このビューには少なくとも3つの次元があります：アーキテクチャレイヤー（「フロントツーバック」）、ユースケースとアクター、および実装のコストまたはリスク。

1つのビューは、処理の動的構造です。また、このビューには少なくとも3つの次元があります。

3番目のビューは、自然にレイヤーに分類され、ユースケースをサポートし、コストとリスクのあるアーキテクチャコンポーネントです。

続けられますが、ポイントはこれです。

フロントエンド開発者とバックエンド開発者（私の意見）

この問題を調べるのに最も有用性の低い方法です。実際の開発者-そして彼らのあなたの意見-はここでは非常に重要です。重要なのは

• ユースケースとアクター

• これらのユースケースをサポートする論理データモデル

• ユースケースの一部として行われるプロセス

• ユースケースの論理要素と処理要素を構築するために使用するコンポーネント。

これが、ほとんどの人が、ユーザーストーリーまたはユースケースごとにシステムを分解する必要があると言う理由です。

開発を行う人について、大まかに一般化しないでください。

どちらでもない。アプリで何ができる必要がありますか？温水バルブが温水を供給し、冷水バルブが冷水を供給し、水が最初に流れることを確認し、必要な場所にパイプを延長し、家のすべての部屋または家が何をするかを実際に配管することを心配する実際に正確に似ています。

フロントエンドは、いくつかのスイッチとレバーが付いた単なるマスクです。バックエンドは、データを取得して処理するリクエストを受け取るものです。最初に、必要な組み合わせで両方を迅速に実装できるポイントに到達します。

しかし、あなたが何をするにしても、一方のデザインが他方のデザインを決定しないようにしてください。そのように狂気があります。

ツールを用意して、開発者がクライアントに必要なものを何でも構築できるようにします。その後、仕様に合わせて構築し、小さなカッシーが最終的に満足するまで再調整します。

また、2008年にフロントエンドの開発者とバックエンドの開発者を比較するのは、Web時代の昔です。楽しみのために、私は質問でそれをリンクしたので、その古い栗にいくつかのことを修正/追加したいだけでなく、（うまくいけば）内にいくつかのヒントを埋め込みたい：

フロントエンド開発者

通常、CS学位を取得していないか、3級学校のCS学位を取得していません。

手のショー。フロントエンドでベストプラクティスを教えられたCS学位の人は何人いますか？または、JavaScriptを台無しにしない方法は？または、IE6-IE9からCSS問題を処理する方法は？アカデミアを運営する教科書業界は、怠shiftingで肥大化しすぎて絶えず変化するテクノロジーを扱うことができないため、大学では「深刻な」注目をほとんど受けていません。これは私のような後期ブルマーにとっては素晴らしいことです。

基本に似た言語で作業する（PHP is Basicを参照）

PHPはクライアント側のテクノロジーですか？あるいは、Schemeから主にインスパイアされたJavaScriptは、フロントエンドの継続的な関心事ではなくなり、バックエンド。このブログでは、独学で学んだオープンソースWeb開発者とCS卒業生Web開発者を、この時点で企業で人気のある技術を使用して比較しています。私はその特定の戦いの両側で耐え難い能力を発揮しましたが、彼はまだそこにいるのです。

フォトショップドキュメントをCSS / HTML /などに変換する視覚的なスキルを持っている。

少し広い「視覚スキル」よりも細部への注意。私たち全員が美的デザインのスキルを持っているわけではありません。しかし、はい、私たちのほとんどはジュニアレベルでこのことを学ぶ必要があり、CSSメスが行うときにJSハンマーを使用しない良いUIを書くために実際に非常に重要です。

型のない言語のため、反復プログラミングに対して高い許容度を持っている

これが、先に述べたピースを最初に配置したい理由です。押されたボタンを渡し、あなたが商品を生産/回収します。パッケージ化して配信します。これらの事柄が互いに密接に結びついている理由はありません。また、実際には、通常、厳密に言えば、技術的にクラスを持っていない言語について高慢になりたいほとんどの人がOOPを嫌がらない限り、厳密なタイピングが反復プロセスを妨げるべきではありません。しかし、たとえ悪臭を放ったとしても、フロントエンドは予測可能なアクセスポイントを必要とするだけであり、JSONまたは成功するバックエンドの動作をHTML構造に「ちょうど」結合します。*咳* Java開発者* /咳*

これに対する単一の正しい答えはありません。特定の状況では、どちらのアプローチも良い（そして悪い）場合があります。

TDDアプローチを検討することをお勧めします。TDDアプローチは、（受け入れとユニット）テストによって導かれます。

システムのスケルトン、つまり最低限の機能を備えた基本インフラストラクチャをまとめることから始めます。これは、コンセプトが機能し、さまざまなコンポーネントが連携して機能することを示すためです。これには、最低限必要なUI（該当する場合）も含まれています。

次に、機能ごとに詳細を具体化します。特定の機能/シナリオの受け入れテストを作成し、失敗させ、それを満たすコードを作成します。これにより、外部から内向きに作業できます。システムは入力メッセージを受信するため、そのメッセージを処理/変換し、それを処理してから、結果をUIに反映する必要があります。途中で、ドメインの概念を発見し、UIからドメインレイヤーに向かって、そしてその逆に新しいクラスでそれらを表現します。

このアプローチの場合、推奨される参考資料は、テストにガイドされたGrowing Object-Oriented Softwareです。

APIファースト

両チームのエンジニアは、フロントエンドとバックエンドの間でAPIを共同で作業する必要があります。その後、両方のチームが設計されたAPIに基づいて作業を開始できます。これには、チームが並行して作業を開始できるという明らかな利点に加えて、別のフロントエンドチームも作業を開始できるという利点があります（Webクライアントの後にモバイルになる場合があります）。

反復アプローチと組み合わせると、次のようになります。

1. シンプルなAPIを設計する
2. 両チームはAPIに基づいて開発とテストを行います
3. 統合テスト
4. クライアントに見せてフィードバックを受け取ります。
5. APIを強化して繰り返します。

フロントエンドから始めますが、まず、既存のアプリケーションを見つけることができないのはなぜですか？これにより、このプロジェクトに関する洞察が得られます。彼らにはいくつかの固有の要件がありますか、それともあなたはより安く構築できると思いますか？

セキュリティに対する期待と、法律が要求するものを完全に把握してください。これがどのタイプの学校かはわかりませんが、生徒の情報には通常、ある程度の機密性が必要です。

潜在的な学生がウェブサイトでデータを入力している場合、グラフィカルなデザインはより大きな問題になるでしょう。

リクエストに基づいて、フロントエンドのモックアップを作成します。GUIがまっすぐ前方にあるとは思わない場合、何かを機能させる必要があるかもしれません。彼らは、登録を、データ入力に基づいてさまざまな方向に分岐する「ウィザード」の一種と見なす場合があります。

その後、データベースに永続化された情報の取得を開始できます。

はい、私はOPがしばらく前に尋ねたことに気付きました。バックエンドで開始しますが、フロントエンドをMOCK UPして、ユーザーが思い描くものを見ることができるようにします。フロントエンドは、それだけの価値があるため、ただの付加機能です。バックエンドはお金のある場所であり、そのストレートが得られると、FEは肉の肉汁になります。

私のコメントを拡張する：

最初に要件を収集し、次にそれらをユースケースと設計に変えます。

まず、詳細なデータベース定義があります。クライアントがそれを完全に理解していないかどうかは気にしません、私は彼らに座ってそれを見るように強制します-そして、サインオフします）、続行する前に。

BEなしでFEから始めるにはどうすればよいですか？何のためにFE ？？？データベースを定義してください!! それがFEの操作です。

わかりました、問題と後で微調整があります、そして、氷山のその特定の先端が最も最も理解するものであるので、私はクライアントASAPの前に単純な、サンプル、GUIを得るのが良いことに同意します。

しかし、I 1）ストレス、これが唯一のラフなモックディスカッションイルカのためのアップ、および2であることを）意図的に、それは醜い作る、しかし、機能を理解していない人は、その入力ボックスを作るために私をnitpick＆伝えることができるように、正確に400ピクセル幅が広く、背景は水色です。

ここでのほとんどの回答（そして私はそれらに従っています）は顧客に集中しすぎる傾向があると思いましたが、純粋にs / wの観点から、最初にせずにBEを操作するためにFEを設計することはできないと主張しますそのBEを設計します。