フロントエンド技術に憤りを感じないようにする方法

フロントエンドがいかに混乱し圧倒的になったかについて多くのことが書かれています (概要については、「JavaScript フレームワーク - 2025 年に向けて」を参照してください)。私はそれが、さまざまな当事者と話し合い、存在する穴を埋め、より健全なエコシステムを構築するには何が必要かについて話し合います。

開発者にとっての現実

フロントエンド開発者がさまざまなテクノロジーを検討する場合、関係者 (ビジネス関係者と開発仲間の両方) を説得する方法が必要です。そのための唯一の方法は、ものを構築して測定し、その利点とメリットを証明することです。期待を管理すること。 (推進力となるのは、まったく新しいものを構築する必要性、既存のものを改善する必要性、あるいは、たとえば外部関係者が関与している場合には、変更の必要がなく、代替案によって得られるメリットがないことを証明することさえあるかもしれません。企業にそれを検討するよう圧力をかけています。)

一例としては、より多くの React Server コンポーネントの利用を検討している開発者が挙げられます (RSC 自体に焦点を当てているわけではありません。他のもの、別のフレームワーク、または別の技術部分を使用することも可能です)。サーバーを含めるようにアーキテクチャを適応させ、新しいプログラミング パターンを採用し、新しいルーターとディレクティブを使用したファイル構成を検討し、それらすべての制約について推論し、これらすべてについて人々を教育し、社内のベスト プラクティスとニーズに合わせて調整する必要があります。顧客と話し合い、SLA とドキュメントを更新します...これはすべて非常にコストがかかり、リスクが伴うため、軽々しく決定を下してはいけません。

(さまざまなテクノロジーを比較し、アーキテクチャの移行を行うという、この厳しくて非常にコストのかかるプロセスは、世界中のかなりのチームが経験していることです。技術の一部 (Next.js は必要ありません – 最新のものとして Next から React に移行した理由)。)

しかし、開発者は POC の構築を開始するとすぐに、多くの技術製品が「信じてください」という議論を通じて宣伝されていることに気づきます。

フレームワークキッチンから生み出される新しいテクノロジーはどれも、それを示すかなりプラスチック的なデモとともに、素晴らしい改善の物語を伝えます。しかし、現実ははるかに厄介で、メリットはわずかであり、しかも実験と移行には非常にコストがかかります。課題は、すべての企業とすべてのチームが車輪を再発明し、特定のケースに実際に何らかの有用性があることを証明する方法を考え出すことです。さまざまなオプションを総合的かつ徹底的に検討し、テストするには、膨大な量のリソースと社内の専門知識が必要です。

Trust Me Bro™ の主張からも明らかなように、Yet Another™ 機能を The Now Best Thing Ever™ として高額で提供する企業が、開発者にそれに同意させ、移行しようと努力しても、実際、難しい問題は解決するのが難しく、ROI が得られないことがわかります。時間が経つにつれて、このように何度も火傷を負うと、憤り、燃え尽き症候群、そして将来のリスクに対する全体的な嫌悪感につながります。

これらのクールな新しいテクノロジーを構築している企業 (そして、本当にクールな可能性もあります!) は、人々が憤りを感じていることに驚き、そのような取り組みに必要な作業量や検証可能な方法が利用できないことを考慮していないように見えることがあります。現実的な期待は何なのか。それはすべて、不誠実に見える可能性があります。

認識されているのは、これらの新しいテクノロジーを構築する企業は、広告だけでなく、開発者に意思決定の指針を与え、メリットを確認するためのツールを提供することによって、そのテクノロジーが機能することを証明する責任を負っているということです。 .

ツール

では、これらのツールは実際にはどのようなものなのでしょうか?

これらのツールは、開発者が関心を持っている (客観的に測定できる) メトリクスを継続的にレポートし、開発者がトレードオフを理解するのに役立つ変更と全体的に組み合わせて関連付けます。

• バンドル サイズ (ページごとおよび共有バンドルに関する包括的なレポート、遅延 (インタラクション時) および/または自動的に (サービス ワーカー、プリロード、その他のウォームアップ) ロードされる追加のバンドルに関する洞察)
• ネットワーク経由のメトリクス (シリアル化を増やすと、クライアントでの実際の節約額と、それがサーバーとクライアント間の通信にどのような影響を与えるかを知ることができます)
• タイミング分割とパフォーマンス (サーバーとクライアントの両方が含まれます。例: コンテンツのレンダリングにかかる​​時間と、そのうちのどれくらいがサーバーとクライアントにかかるか、ネットワークの遅延と転送など)
• Web Vitals (ロードとレンダリングの両方が段階的に行われる Web ページのさまざまな部分に対して、より詳細な分割が必要ですか? 初期ロードのみの 1 回限りのメトリクスではもう十分ですか?)
• プロジェクト全体のレベルでのこれらのさまざまなメトリクスすべての（経時的な）傾向と相関関係（これにより、チームは物事の進捗状況を追跡し、時間の経過によるパフォーマンスの低下やエッジケースの導入によって不愉快な驚きを避けることができます）一部の場所と一部のページのみ)

ここで言及されているものは、どのチームでも気にするものと同じですが、そのような種類の洞察を得るツールはセットアップが難しく複雑に思え、黒人のように動作するフレームワークを扱う場合には事実上不可能な場合もあります。ボックス。

インセンティブ

この種のツールは、必ずしもこれらの新しい技術を自社で開発しているのと同じ企業が提供する必要はありませんが、別の企業が構築することもできます (同様の考慮事項のヒントがすでに存在する可能性があります? Evan You - Vue, Vite、VoidZero、JavaScript ツールの将来、そうでないと、Evan の言っていることを誤解している可能性があります)。しかし、新しいテクノロジーを構築する同じ会社が、その利益を検証するためのツールも提供する会社であるべきだと私は信じています。なぜなら、インセンティブは彼らの側にあるからです。

さまざまなメトリクスやさまざまな実装間の差異を透過的にレポートするツールを構築することで、新しい技術やフレームワークを構築している企業は、まず内部で進捗状況や主張を検証し、トレードオフを理解し、最適化することができます。正しい指標。そうすることで、会社の説明責任と誠実さが保たれます。したがって、改善のフィードバック ループ全体が、一般に公開されるよりずっと前に、内部で発生する可能性があります。

その後、同じツールを一般公開することで、同社は虚偽の主張や失望のリスクを回避し、代わりに誰もが自分のプロジェクトで自分自身で簡単に検証できる機能を提供できるようになります。それはひいては、さらなる信頼と感謝を生み出すことになるでしょう。

テクノロジーを構築している企業は、そのためのツールを構築するのにも最適な立場にあります。API と機能、そしてツールを機能させるためにどれくらいの量を開く必要があるのか​​、またはどれだけの量を開く必要があるのか​​を最もよく理解しています (これは別の方法です)会社を誠実かつ公正に保つため)。

最終的に、企業がそのツールを有料にしてビジネス モデルを拡張したい場合は、そうすることも可能です。 (現在、同様のアプローチは通常、クライアント企業との契約と直接関与を通じて実現されますが、ツールを使用すると全体がはるかに利己的なものになり、すべての関係者に利益をもたらす可能性があります。)

結論

私たちはテクノロジーが競合する時代にいますが、単一の最適なソリューションは存在せず、ますます大規模化するプロジェクトでのアーキテクチャの移行は決して安くはありません。スマートな決定と移行を可能にするためには、すべてが完了してからレポートするだけでなく、意思決定、変更、トレードオフを継続的にガイドおよび評価する、より包括的なツールとレポートが必要です。

これらの新しいテクノロジーやフレームワークを構築している企業は、そのようなツールから最も恩恵を受ける企業であり、ツールを構築するのに最適な立場にあります。

以上がフロントエンド技術に憤りを感じないようにする方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。