Webのスタートアップで、機能のフロントエンドとバックエンド（基本的に機能全体を担当する）を担当するエンジニアがいる方が一般的ですか？または、エンジニアはバックエンドとフロントエンドを分離しましたか？
どちらがより有益で、どのような状況に適していますか？
機能全体を担当するエンジニアが1人いることの欠点は、フロントエンドまたはバックエンドの開発のどちらかではなく、両方ではなく、スピードと品質が低下することがあることです。
1つの機能にフロントエンドとバックエンドの開発者を配置すると、機能の速度と品質が向上し、コラボレーションが促進されます。しかし、1人のエンジニアを別の機能に配置して作業を行うことができるため、2人のエンジニアが1つの機能を使用してリソースの使用率が低い可能性があることを心配しています。
小規模の初期段階のスタートアップでバックエンド/フロントエンドのエンジニアリングリソースを割り当てるための一般的/ベストプラクティスは何ですか？そして、成長するにつれてどのように変化しますか？
回答:
ここに14年の経験からの私の知恵があります：
最良の答えは@Sharkからですが、最後の部分「依存する」のみです。私の経験では、約16年かそこらで、両方のオプションがさまざまな異なる構成で試行されたのを見てきました。自分でフルスタック開発者であるため、ここで学んだことは次のとおりです。
*（BE =バックエンド、FE =フロントエンド）
アジャイル開発プラクティス（最近の一般的な戦略）は、機能の開発を推奨しています。この機能は、顧客の観点からの機能の単一の貴重なチャックです。この観点から、開発者に両方を実装させる必要があります。
サーバーの境界に沿ってスタックを分割すると、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を知らない「Web開発者」がいます。
2番目に大きな不満は、開発チームを簡単にセグメント化できることです。FE開発者は、BEコードを変更した後にバグを作成し、チームはクロススタック開発の卸売を制限するために投票します。コードレビューと教育が問題を解決できるのに対して、人々は代わりに領土になります。
RESTful APIは、FEがないため、この説明に最適です。多くの場合、企業は最初にRESTful APIに取り組み、次にその上でWebアプリケーションを開発します。この場合、FEがアプリケーションを終了している間、BEチームが次のメジャーバージョンに焦点を合わせ続ける強いケースがあります。しかし、解約の危険性は依然として存在します-特にFE開発フェーズで発見された新しい情報がBE APIに重要な変更を必要とする場合。
FEとBEの間の不均衡なワークロードも、FEのみのチームを作成する場合に適しています。繰り返しますが、これは非常に状況がよく、おそらく主な開発がデスクトップアプリケーションを介して行われ、会社は「ライト」Webインターフェイスの開発を試みています。
新規/ジュニア開発者のトレーニング。インターンまたはジュニア開発者を雇っており、それらをディープエンドに投入することを懸念している場合、そのコミュニケーション/統合コストの一部をピア開発システムに投資することは良い選択肢です。
最初のポイントはかなり大胆です-そして、あなたがそれらの「良い自己組織化チーム」の1つを持っていないならば、それはすぐに失敗します。そのチームを持っているとしても、彼らと彼らの利益のために彼らの境界を押し広げることは重要です。そして、優れた自己組織化チームは、常にそうするように自発的に動機付けられているわけではありません。
あなたの2番目のポイントは間違っています。最新のWeb開発には、パフォーマンスが高く、安全で、非同期で安全で、XSSに耐性があり、クロスブラウザーであり、迅速に開発されるFEコードが必要です。目標は単純にBEと競合せず、実質的に同等です。
3番目の点も悪い仮定です-FE開発は、BEの基礎作業なしで、純粋なhtml / css / jsから始めることができます。そこから、BEレンダリング用のテンプレートに分解するのは簡単なことです。多くの場合、FEの作業から始めるのが最善です。なぜなら、視覚的な進歩を前もって確認するために、利害関係者が温かくあいまいな感じを感じるからです。
結論：
あなたがスタートアップであり、たまたま多くの時間やお金を費やしていないなら、FEやBEだけの開発者を雇わないでください。上級レベルのWeb開発者と優れたux / designerを雇うと、彼らはあなたのアプリケーションを可能な限り迅速に開始します。コストはかかりますが、生産性ははるかに高く、必要なものは少なくなります。
質問は間違っていると思います。
私が参加したすべてのスタートアップは、FE-BEのみのアーキテクチャを持っていませんでした。
私が知っているほとんどのスタートアップは：
APIはステートレスであり、簡単にm笑されます-コア開発者がなくてもです。地獄、私がゼロからプロジェクトを開始しなければならなかった場合、私はモックで純粋に動作するUI全体から始めるかもしれません-これはプレゼンテーションに最適です。フィードバックのほとんどはUIによるものです。顧客はさらに多くのことに注意します-（対象読者によって異なります。）
たとえば、Google検索にはWebをクロールし、インデックスを作成するなどのコアコンポーネントがあり、Google UIはまったく異なる世界です。このコアは非WWW検索を簡単にサポートできますが、UIはサポートできません。
これにより、UIが「プラグイン可能」になり、懸念事項が分離されます。
開発知識に言及しましたが、プロジェクト管理の側面を見落としています。コアチームは2週間のスプリント期間を必要とするかもしれませんが、UIチームはCIを使用します。すべてが常にアップロードされます。コアチームには下位互換性が必要ですが、UIには必要ありません。
言語が異なります。おそらく、CoreコンポーネントのC開発者が必要になるでしょう。また、単一のOSで実行する場合は大丈夫です。UIはクロスOS言語で記述されます。
テストは異なります。UIテストの世界は、私がソフトウェア開発で知っている中で最も複雑なものの1つです。ほとんどのスタートアップはそれを無視し、この決定を後悔しています。テスト時にBEとFEを分離することはできません。それを処理する単一のユニットでなければなりません。
オープンソースUI-2つを分離する最大の利点の1つは、UIをオープンソースにできることです。UIプロジェクトにはオープンソースのサポートが必要です。
機能全体を 理解できないUI開発者を想像することはできませんsession。あなたが知っている-あなたがログインし、異なるリクエスト間でログインしたままになります。確かに彼らはJavaではなくPHPを知っているかもしれませんが、BEの概念は明確でなければなりません（たとえば、暗号化されたCookieを使用する）。特定の言語障壁は間違っています-すべての開発者は、どの言語でも喜んで作業する必要があります。数年前にJavaScriptでBEを書くと誰が思ったでしょうか？
コア、BE、FEの3つのチームが存在する場合、リソースの無駄遣いです。DBはどうですか？DBAが必要ですか？BE開発者がDBを知っていて、FE開発者がBEとDBを知らないのはなぜですか？制限はありません。
あなたが専門家を必要とし、あなたがそうするなら、彼らをアウトソーシングすることはかなりうまくいきます。通常、高品質のコードを配信し、非常に高速に実行します。退社すると迷子になるため、必ずしも社内に配置する必要はありません。さらに、今日オンラインで素晴らしいアドバイスを得ることができます。最先端のものは異なるアプローチを必要とするかもしれません。
したがって、結果は基本的にすべてのFE開発者が開発できるUIの非常に薄いBEです。UIに厚いBEがある場合は、おそらくCoreに必要なAPI機能がいくつかあります。
残りの中で際立っている開発者は常に少なくとも1人います。このような薄いFEがあれば、BEコードで他の開発者をサポート（開発ではなく）することができます。私の意見では、この開発者は非常に優れた立場にあり、適切に授与されるべきです（ただし、給与ではなく、他の何か）。また、ビルドプロセスを処理して適切にビルドできることも信頼しています。
このモデルは、BE開発に関して優れた柔軟性を提供します。BEの世界ではここ数年でいくつかの転換が知られているため、とにかくBEの安定性に頼りすぎることはお勧めしません。コアは別の話です。
FEとBEは同じプロジェクトである必要がありますか？次のことに注意してください
先に進むことはできますが、BEとFEは同じチームである必要があると思いますが、プロジェクトが異なる可能性があることは明らかです。
実装の成功にはいくつかのことが考えられます。強力なバックエンドを備えているが、ユーザーインターフェイスとすべての「フロントエンド」の部分を十分に把握している唯一の開発者がいる場合、おそらく成功する可能性があります。ただし、個人的な経験では、通常はそうではありません。たとえば、私は自分自身をバックエンド開発者と考えています。しかし、私は自分で多くのプロジェクトに取り組んでいます。プレゼンテーションとクライアント側の作品に取り組んでいますか？確かに。彼らは実際の才能のあるデザイナーやクライアント側の開発者が作るのと同じくらい良いように見えますか？絶対違う。
それはすべてギブアンドテイクです。ただし、2人の開発者が協力してtheすることは避けてください。開発者とデザイナーの間で生産性を最大化するための試行された真の方法があります。
言い換えれば... それは依存します
if you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best.