Web開発プロジェクトでは、バックエンドとフロントエンドを2つの位置に分けることは一般的ですか？
Webスタートアップでは、エンジニアが機能のフロントエンドとバックエンド（基本的には機能全体を担当）を担当する方が一般的ですか？または、エンジニアはバックエンドとフロントエンドを分離していますか？
どちらがより有益で、どのような状況に適していますか？
機能全体を担当する1人のエンジニアがいることの欠点は、フロントエンドまたはバックエンドのどちらか一方の開発だけが得意であり、両方がそうでないため、速度と品質が低下する場合があることです。
フロントエンド開発者とバックエンド開発者が1つの機能を使用することで、機能の速度と品質が向上し、コラボレーションが促進されます。しかし、1人のエンジニアが別の機能に取り掛かることができるため、2人のエンジニアが1つの機能に取り組んでいることを懸念しています。
小規模な初期段階のスタートアップでバックエンド/フロントエンドエンジニアリングリソースを割り当てるための一般的な/ベストプラクティスは何ですか？そして、それが成長するにつれてどのように変化しますか？
ここに14年の経験からの私の知恵があります：
- スタートアップ企業の場合は、役割を割り当てないでください。優れた自己組織化チームを編成してください。誰もがお互いを知っているなら、誰もが誰が最善を尽くすかを知っています。プロジェクトマネージャーは邪魔になるだけです。
- 後で、フロントエンドとバックエンドの違いがわかります。バックエンドでは、品質は最も重要です。コードは、パフォーマンスが高く、安全で、トランザクションに対して安全でなければなりません。フロントエンドでは、実装時間が重要になります。そして、優れたバックエンドに依存できる必要があります。フロントエンドとバックエンドの異なる目標は、うまく機能しません。
- フロントエンドのコーダーが機能し始める前に、バックエンドがすでに存在している必要があります。そうしないと、フロントエンドコーダーの速度が低下しすぎます。
- バックエンドは、速度を落とさないようにするために、フロントエンド要件に迅速に対応できる必要があります
最良の答えは@Sharkからですが、最後の部分のみ「状況による」です。私の経験では、約16年かそこらで、両方のオプションがさまざまな異なる構成で試行されるのを見てきました。私自身がフルスタックの開発者であるため、ここで私が学びました。
*（BE =バックエンド、FE =フロントエンド）
スプリットスタック開発の一般的な注意事項：
アジャイル開発プラクティス（最近の一般的な戦略）は、機能開発を推奨しています。この機能では、顧客の観点から、機能は1つの価値ある機能の集まりです。この観点から、開発者に両方を実装させる必要があります。
スタックをサーバーの境界に沿って分割すると、2人の開発者の間に統合ポイントが作成されます。彼らが効果的にコミュニケーションを取り、うまく連携しない限り、2つの機能を組み合わせると、かなりの数のバグが発生します。
Mythical Man-Monthの通信のn（n-1）/ 2ルールを適用すると、2人で機能を2つの部分に分割すると、全体的なワークロードが増加することがわかります。このルールは機能にも適用されますが、スタックを分割すると通信量が2倍になります。
デザイナーは、BE開発者が魅力的なインターフェースを一から作成できないという問題を解決します。これは、少なくともhtmlとcssを知っていて、デザイナーが作成したスクリーンショットと一致するインターフェイスを生成できることを前提としています。
機能は通常、他の機能とほとんど相互作用しない分離されたコンポーネントです。これは常に当てはまるわけではありませんが、通常、対話のポイントはデータベースやファイルシステムのように低レベルです。したがって、フルスタックの開発者が機能を実装することを妨げることはあまりありません。しかし、FE開発者がBE開発者がタスクを完了するのを待つ必要がある場合、ポイント3の生産性の損失に加えて、さらに遅延が追加されます。
Web2.0は、FEとBEの違いをさらに曖昧にします。 MVCフレームワークとクライアント側で構築されるアプリケーション全体により、安全で効率的なFEアプリケーションを実装するには、BEに関する十分な知識が必要になります。
このプラクティスに対する私の最大の不満は、プロジェクトに関わるすべての人の能力を制限することです。これは2000年代初頭の一般的な慣行でしたが、両方を実行できる開発者を見つけるのはかなり困難だったため（純粋に新しさのためではなく、両方を学習することの本質的な難しさのためではありません）、それは不必要に行われました。 10年経った今でも、CSSを知らない「ウェブ開発者」がいます。
私の2番目に大きな不満は、開発チームを簡単に分割できることです。 FE開発者はBEコードを変更した後にバグを作成し、チームは投票してクロススタック開発の卸売りを制限します。コードレビューと教育で問題を解決できるのに対し、人々は代わりに領土になります。
スプリットスタック開発の利点/使用例：
FEがないため、RESTful APIはこの描写に最適です。多くの場合、企業は最初にRESTful APIに取り組み、次にWebアプリケーションを開発します。この場合、FEがアプリケーションを終了している間、BEチームが次のメジャーバージョンに集中できるようにする強力なケースがあります。ただし、解約の危険は依然として存在します。特に、FE開発フェーズで発見された新しい情報にBE APIへの重要な変更が必要な場合はなおさらです。
FEとBEの間のワークロードが不均衡であることも、FEのみのチームを作成する良い例です。繰り返しますが、これはおそらく主な開発がデスクトップアプリケーションを介して行われ、会社が「ライトな」Webインターフェイスを開発しようとしている状況です。
新規またはジュニア開発者のトレーニング。インターンまたはジュニアの開発者を雇用していて、それらをディープエンドに投入することを懸念している場合は、そのコミュニケーション/統合コストの一部をピア開発システムに投資することをお勧めします。
このページでの@Ralfの承認済み回答に関する懸念：
最初の点はかなり大胆です-そしてあなたがそれらの「良い自己組織化チーム」の一つを持っていなければすぐに失敗します。あなたがそのチームを持っていたとしても、彼らの境界を押し上げることはあなたと彼らの利益にあります。そして、優れた自己組織化チームは、常にそうするように動機付けられているわけではありません。
2つ目のポイントは間違っています。最新のWeb開発には、パフォーマンスが高く、安全で、非同期で安全で、XSSに対応し、クロスブラウザーであり、迅速に開発されるFEコードが必要です。目標は単純にBEと競合せず、実質的に同等です。
3番目のポイントも悪い前提です。FE開発は、BEの基礎作業なしで純粋なhtml/css/jsから始めることができます。そこから、それをBEレンダリング用のテンプレートに分解するのは簡単なことです。多くの場合、FEの作業から始めるのが最善です。なぜなら、視覚的な進行状況を前もって確認するために、関係者に暖かくファジーな感覚を与えるからです。
結論：
あなたがスタートアップであり、あなたが時間とお金を費やす時間があまりない場合は、開発者だけを雇ったり、FEを雇ったりしないでください。上級レベルのWeb開発者と優れたux/designerを雇うと、彼らはあなたのアプリケーションをできる限り早く着手させます。コストは高くなりますが、生産性ははるかに高く、必要な数は少なくなります。
質問は間違っていると思います。
私が参加したすべてのスタートアップは、FE-BEのみのアーキテクチャを持っていませんでした。
私が知っているほとんどの新興企業が持っています：
- コア-インターフェースを公開する実際の製品
- UI-BEおよびFE。 BEはコアのAPIを使用します。
APIはステートレスであり、簡単にモック化されます-コア開発者がいなくても。地獄、私が最初からプロジェクトを始めなければならないなら、純粋にモックで動作するUI全体から始めるかもしれません-これはプレゼンテーションに最適です。フィードバックのほとんどはUIによるものです。より多くのことに顧客は気づきます対象とする視聴者に依存します。）
たとえば、Google検索には、ウェブのクロール、インデックス作成などを行うコアコンポーネントがあり、Google UIはまったく別の世界です。このコアは、WWW以外の検索を簡単にサポートできますが、UIはサポートできません。
このようにして、UIは「プラグ可能」であり、懸念事項を分離できます。
あなたは開発知識を参照しましたが、プロジェクト管理の側面を見落としている。コアチームは2週間のスプリント期間を必要とする可能性がありますが、UIチームはCIを使用します-すべてが常にアップロードされます。コアチームには下位互換性が必要ですが、UIには必要ありません。
言語が異なります。おそらくCoreコンポーネントのC開発者が必要でしょう-それが単一のOSで実行されれば、UIはクロスOS言語で記述されるので問題ありません。
テストは異なります。 UIテストの世界は、ソフトウェア開発において私が知っている最も複雑なものの1つです。ほとんどのスタートアップはそれを無視し、後でこの決定を後悔している。テスト時にBEとFEを分離することはできません。それを処理する単一のユニットである必要があります。
オープンソースUI-2つを分離する最大の利点の1つは、UIをオープンソースできることです。 UIプロジェクトにはオープンソースのサポートが必要です。
---（全体session機能を理解できないUI開発者は想像できません。あなたが知っている-あなたはどこにログインし、異なるリクエスト間でログインしたままです。 PHPであり、Javaではありません。しかし、BEの概念は明確である必要があります（たとえば、暗号化されたCookieを使用します）。特定の言語の障壁は間違っています-すべての開発者は、言語数年前にJavaScriptでBEを書くと誰が思ったでしょうか。
コア、BE、FEの3つのチームを持つことは、リソースの無駄遣いです。 DBはどうですか？ DBAが必要ですか？ BE開発者がDBを知っていて、FE開発者がBEとDBを知らないのはなぜですか？制限はありません。
専門家が必要な場合は、専門家をアウトソーシングすることでかなりうまくいきます。彼らは通常高品質のコードを提供し、それを非常に高速に行います。あなたが彼らが去るとあなたは迷子になるので、あなたは必ずしも彼らを社内で望んでいるわけではありません。加えて、今日オンラインで素晴らしいアドバイスを得ることができます。最先端のものは異なるアプローチを必要とするかもしれません。
したがって、結果は基本的に、すべてのFE開発者が開発できるUIの非常に薄いBEです。 UIにシックBEがある場合、コアで必要なAPI機能がいくつかある可能性があります。
常に少なくとも1人の開発者が他の人より際立っています。そのような薄いFEを与えられれば、彼/彼女はBEコードで他の開発者にサポートを与える（開発しない）ことを管理できます。私の意見では、この開発者は非常に良い立場にあり、適切に授与されるべきです（給与ではなく、他の何かで）。また、ビルドプロセスを処理して適切にビルドできることも信頼しています。
このモデルは、BEの開発に関して大きな柔軟性を提供します。 BEの世界では、ここ2、3年でいくつかのターンアラウンドが判明しているため、BEの安定性に頼りすぎることはお勧めしません。コアは別の話です。
まだ疑問が残っています-FEとBEは同じである必要がありますproject？次のことに注意してください
- 静的リソースはフロントサーバーから提供するのが最適です。フロントエンドサーバー（nginxなど）は非常に強力であり、静的リソースにキャッシュを使用できるため、静的リソース（すべてのHTMLコンテンツ、JS、CSS、画像である必要があります）の単一のデプロイメントで管理できます。
- バックエンドコードには同じ贅沢がないため、分散システムが必要です。これもフロントサーバーによって管理されます。
- FEコードは、JavaScriptをサポートするすべての新しいテクノロジーで再利用する必要があります。これで、JavaScriptを使用してデスクトップアプリケーションとモバイルアプリケーションを作成できます。
- ビルドプロセスは完全に異なります。これには、パッチの配信、アップグレード、インストールなども含まれます。
続行できますが、BEとFEは同じチームでなければならないことは明らかですが、プロジェクトが異なる可能性があります。
実装を成功させるにはいくつかのことがあると思います。強力なバックエンドを持っているが、ユーザーインターフェイスとすべての「フロントエンド」部分を適切に把握している唯一の開発者がいる場合、おそらく成功する可能性があります。ただし、これは通常は当てはまりません（私の個人的な経験では）。たとえば、私は自分自身をバックエンド開発者と見なしています。しかし、私は自分で多くのプロジェクトに取り組んでいます。プレゼンテーションとクライアント側の作品に取り組んでいますか？承知しました。彼らは実際の才能のあるデザイナーとクライアント側の開発者が作るのと同じくらいよく見えますか？絶対違う。
それはすべてギブアンドテイクです。ただし、2人の開発者が協力していることをためらわないでください。開発者と設計者の間で生産を最大化するために試行された真の方法があります。
言い換えれば...場合によります