MVC モデルのフロントエンドはテンプレートを作成する必要がありますか?

私は最近会社に入社しましたが、チームは開発段階にあります。同社の現在の開発モデルでは、まずフロントエンドがプロトタイプと設計図に基づいてフロントエンドページを作成します。技術マネージャーが設定したルールは、フロントエンドがページを「頭」、「ページ」の 4 つの部分に分割することです。バックエンドのニーズに応じてボディ、メニュー、フットを割り当て、コントローラーはそれらにテスト ページを与えます。フロントエンドページのテストが完了すると、バックエンド開発ページが引き渡されます。

フロントエンドは、Ajax や送信アクションなどの多くのインタラクティブなエフェクトは、最初は独立して実行されます。フロントエンドによって記述され、その後バックエンドがテンプレートに統合されます。テンプレートには数百行の JS コードが記述されていることが多く、Web サイトのコードが非常にわかりにくいと感じます。

第二に、フロントエンド ページはバックエンド テンプレートから分離されているため、フロントエンドが何らかの変更を加える必要がある場合、まずページを変更してから、変更が必要な部分を私たちに知らせます。小さな変更は問題ないとしても、大きな変更は非常に混乱を招き、バックエンドによってテンプレートに追加された JS コードが多数あるため、変更すると多くの競合が発生することがよくあります。また、通常、フロントエンドとバックエンドは同時に開発されるため、バックエンド テンプレートとフロントエンド ページの間の切断により、小さなトラブルが発生することがよくあります。

最初は、テンプレートはすべてフロントエンドによって記述されるべきだと考えていました。単純なテンプレート言語を記述し、バックエンドによって提供される構造に従って Ajax インタラクションを記述するだけで済みます。フロントエンド管理者は、フロントエンドとバックエンドを完全に分離する必要があるとは考えていません。彼は、現在の慣行を放棄して、フロントエンドで純粋に静的な HTML を作成することさえ望んでいます。バックエンドのルールに従ってページを分割する必要はありませんが、この提案は当時採用されませんでした。バックエンドのワークロードと開発時間が増加するためです。

皆さんの意見を聞きたいです。フロントエンドはテンプレートを書くべきですか?

返信内容:

フロントエンド業界のほとんどの人々 (私を含む) の意見では、テンプレート (正確にはプレゼンテーション層) が主にフロントエンドを担当する必要があります。これは、html/css だけがフロントエンドによって行われるわけではないことを意味します。ただし、js と ajax もフロントエンドで実行する必要があります。個別のページ再構築 (HTML/CSS のみ) を行っている企業はまだ多くありますが、一般に、この方法はますます多くのフロントエンド実務者によって疑問視され、否定されています。

もちろんピギーは例外です。 :) フロントエンドとバックエンドが完全に分離されているということは、バックエンドはインターフェイスとデータを提供するだけということではありません...

私たちのアプローチ、バックエンド開発は、フロントエンド開発とのインターフェイスとデータ形式を提供し、データを提供します。 フロントエンド開発はバックエンド テンプレートまたはフロントエンド テンプレートを書き込み、すべての Ajax リクエストとユーザー インタラクションを純粋に作成します。静的 HTML ページ。これはフロントエンドとは呼ばれないと思います。 急いで船に飛び乗ってください。
あなたの会社にはフロントエンドがなく、グラフィックカッターとプログラマーだけがいます。
あなたはカッターとして扱われています。
アリババへの入社に興味がある場合は、プライベート メッセージで履歴書を送信してください。 ランダムにここに来ました。
あなたのフロントエンドマネージャーのコンセプトが、フロントエンドは静的なデモ出力のみを担当し、フロントエンド開発は単なる HTML + CSS + 少量の JS であるというものであれば、次のことがわかると思います。このマネージャーを排除するか、プロジェクトを撤退して変更する方法です。
私の意見では、ユーザー エクスペリエンスを追求するインターネット プロジェクトでは、フロントエンド チームが、クライアント側でレンダリングされたテンプレートやサーバー側のビュー層を含むプレゼンテーション層のすべての業務を引き継ぐ必要があります。ビジネスは、Web パフォーマンスを最大限に最適化することができます。
フロントエンドのものである限り、バックエンドは一線を越えてはなりません。つまり、バックエンドは js のすべてのロジックに関与すべきではありません。一線を越えた者は手を切り落とされ、投げ飛ばされる。

もちろん、純粋に静的なデモもモジュール化できます。数日前にトピックに返信しました。それを参照してください。しかし、私は実際にはその使用方法のドキュメントを書きたくありません。理由はありません。単純すぎると思います。自分で理解してください。

Grunt で静的リソースの場所を設定するにはどうすればよいですか? - フロントエンドエンジニア チーム力が弱すぎる、それはそれで、典型的な学生時代の成長感。 。 。 。


チームにはフロントエンドの包囲ライオンが不足しており、一部は単なるカッターです。急いで履歴書を jieyou に提出して、純粋なバックエンドを体験してください 問題の質問はフロントエンドとバックエンドの分離ではなく、単なるプロセスであると感じます。

プロジェクト マネージャーの要件は、フロントエンドで HTML ファイルを作成し、静的部分をバックグラウンドでコードにコピーして貼り付け、動的部分を動的コードに置き換えることです。ダイナミックなロゴは背景に書かれたままです。ドキュメントのコピーが 2 つあり、1 つは静的、もう 1 つは動的です。

これはフロントエンドとバックエンドの分離ではなく、PSD 画像を切り取ってサンプル HTML を生成し、それをバックエンド エンジニアに渡してページを作成するだけです。

実際の MVC テンプレートには、プロジェクトの一部であるバックグラウンドにテンプレート コードが埋め込まれている必要があります。
たとえば、本文の場所は {{CONTENT}}、タイトルは {{TITLE}} です。または、プロジェクトで @xiaozhu などの場所タグを使用し、実行時にデータをバインドします。フロントエンドとバックエンドは同じファイルを維持します。

フロントエンドとバックエンドの実際の分離は、バックエンドがインターフェイスのみを提供し、HTML レンダリングを含まないことです。たとえば、angular js の使用は典型的なアプリケーションの 1 つです。

フロントエンド開発チームがいくつかのスクリプトの概念を理解していれば、バックエンドの関与をあまり必要とせずに変更を加え、開発効率を向上させることができます。しかし、それはフロントエンドの生産性を解放することではなく、バックエンドのワークロードを軽減することです:P フロントエンド マネージャーに伝えてください。私は彼の意見に完全に同意します。ただし、フロントエンドは HTML を記述するだけで十分です。ただし、これをサポートするには適切なテクノロジが必要です。それらはどれもフロントエンド向けに設計されたものではなく、すべてバックエンドエンジニアがフロントエンドを欺くために自分たちの都合のために書いたものです。

それで、私たちはフロントエンドの生産性を解放するという旗の下に登場しました、そうです、絶望している人や不満を持っている人は私と一緒に来てください、1、2、3。 。 。

フロントエンド開発とバックエンド開発はどのように連携しますか? - Xiaozhu の回答

Knot.js を評価するには? - Xiaozhu の回答

ちなみに、上記の回答の下に私が返信したコメントを抜粋します

小さい豚（作者）は何世軍に返信しました

あなたは私たちのデザインが外部委託されていると推測しましたが、それは間違いです、私たちのデザインが独立したチームであることは事実ですが、それは私たちの内部チームなので、彼らを独立させているだけです。これは、エンジニアとデザイナーの間には違いがあると考えているためです。優れたエンジニアが同時に優れたデザイナーになることはほとんど不可能であり、その逆もまた同様です。 。

======純粋な不満========
Facebook を含む多くの企業は、テンプレートとデータ ロジック間の相関作業を解決するためにフルスタック エンジニアを使用しようとしています。エンジニアにページを完成させましょう 仕事の一部として、デザイナーのmmが秋と月の悲しみとともに風景を観察し、美的インスピレーションを育んでいる間、私たちは寮でゲームをして大量の汗をかいています。私たちのような偉い人が、人々を美しいと感じさせるページを作成することを期待しています。 。 。
==================

そこで、私たちは意図的にそのようなチーム構造を構築し、そこから技術的な解決策を探し始めました。チームの構造が技術的な構造に影響を与えるというのは、おっしゃるとおりです。


彼 Shijun は Xiaozhu (著者) に答えました
つまり、あなたはアウトソーシング チームではありませんが、あなたの話によると、独立したチームの状況はアウトソーシングの状況と似ています。実際、私は個人的にこの構成について非常に懐疑的です。なぜなら、そのような構成で悪い結果が得られる例を数多く見てきたからです（それが社内の独立したチームをアウトソーシングするか、準アウトソーシングするかにかかわらず）。しかし、私はあなたの実際の作業状況を見たことがありません。評価をすることです。

Zhu (著者) He Shijun への返信 そうですね、私たちが持っている 2 つのフレームワークを除いて、この種のチーム構造に適合するフレームワークは他にありません。独自のフレームワークを作成します。成功するかどうかについては、私の自己評価は素晴らしいです。 既存の技術スタックは全てエンジニア向けであり、デザイン部分を無理に剥がすと必ず破れや出血が発生します。しかし、見方を変えると、失敗例も多く見られるということは、このような仕組みが求められているということなので、みんながやってみるのは正しい道を進んでいる少数派だと思います。さらに、既存のエンジニア指向の技術スタックでは分離設計を十分にサポートできないため、経験豊富な技術リーダーはこの種のチーム構成を避けることになるため、分離設計に対する実際の需要はこれまで見てきた以上にあるはずです。失敗するケースのほうがはるかに多いです。

一見複雑そうに見えますが、当社ではカットアウトなどのサービスのみを行っております。 役職はJAVAジュニアソフトウェア開発エンジニアです。仕事はJavaWebの仕事です。
様々なコードを書いたり、Controllerを提供したりします。
次に、AJAX ページを実行して、データ、イベント バインディング、その他の操作を取得する必要があります。

UI チームは静的ページといくつかの簡単な操作イベント (すべて選択、ラジオ選択、ポップアップ ボックス) のみを提供し、最終的にはバックエンド担当者にさまざまな JavaScript の作業を任せます...
私は 1 年働いていますが、Java よりも JS を書くことが多く、開発はバックエンドに向けています。 あなたとデザイナーは何を恐れていますか? 私たちはプロトタイプに基づいてページを直接作成し、最終的にすべてのプロセスが完了し、ページのスタイルとレイアウトを決定しました。オンラインになるまでに一週間の大変な作業が必要でした。