JavaScript リファクタリング: モジュールのパーティショニングと名前空間

通常、私たちのチームの開発者は、Java 言語レベルでかなりの技術リテラシーと豊富な経験を持ち、多くの成熟した合理的なプロトコル、さまざまなタイプのコードハザード検査ツール、さらにはチーム間の計画的なレビューや抜き打ち検査さえ持っています。ただし、フロントエンドのコードはバックエンドとは異なり、誰も気に留めない子供のようなものであり、過小評価され、軽蔑されやすいだけでなく、品質の低下や保守性の低下につながります。スキルの点で優れたフロントエンド開発者が不足している。
JavaScript はフロントエンド コードの重要な部分であり、バージョンが続き、製品がますます大きくなるにつれて、プロセス全体を通じて JavaScript レベルの再構築を徐々に強化する必要があります。

コードの量が特定のレベルに達すると、JavaScript はページ モジュール コンポーネント (カスタム FreeMarker タグなど) と一緒にモジュール化するのが最適です。
モジュール化によってもたらされる最大のメリットは、独立性と保守性です。大量の JS で問題箇所を特定する必要がなくなり、よりシンプルになり、理解しやすく、カスタマイズしやすくなります。
モジュール間の依存関係はシンプルにするのが最善です。たとえば、common.js がある場合は、それが含まれていない、または統一的に管理されたグローバル変数が含まれていることが必要です。独立して、他のコンポーネント js に簡単に依存できます。たとえば、文字列にトリム メソッドを実装する必要があることがよくありますが、js 自体にはそれがありません。その場合、common.js の文字列プロトタイプを拡張して、外部ユーザーに対して透過的に実装できます。

名前空間の使用は、js が相互に干渉しないようにするための良い方法です。js はオブジェクト指向であるため、カプセル化、継承、ポリモーフィズムの原則に従う必要があります。
Java インポートの使用法を参照して、名前空間がそのような効果をもたらすことを願っています。最も単純な例を見てみましょう。
メソッド webOnlinePlay を含むモジュール play があります。このモジュールがインポートされていない場合、 js の実行が間違っていることを願っています:
Java コード
webOnlinePlay() //エラー! メソッドが見つかりません
しかし、このモジュールを導入すると:
Java コード
import("play"); ; //正解、メソッドは見つかります

実際、デフォルトでメソッド webOnlinePlay() を呼び出す本質は window.webOnlinePlay() であるため、このような効果を実現するのは非常に簡単です。
そのため、import("play") の場合、内部実装メカニズムは次のようになります:
Java コード
var module = new playModule();

このモジュール内のすべてのメソッドは、直接使用するために window オブジェクトにインポートされます。 code
window[methodName] = module[methodName];

実際、ここに謎はありませんが、必要なものを取得するというこのアイデアは、フロントエンドの再構築にアイデアをもたらし、それによってもたらされる可能性があります。カプセル化 メンテナンス強化のアイデアですね。

賢明な方は、次のような質問もできます:
Play モジュールをインポートせず、このページがそれを必要としない場合、play.js をロードすることさえできませんか?
もちろん、次の分解、つまり js の動的読み込みに関する部分に注意してください。