私はフロントエンド開発者としてすぐに新しい仕事を始めています。私が取り組んでいるアプリは、クライアント側の100%Javascriptです。サーバーが返すのは、アプリに必要なすべてのJavascriptファイルをロードするインデックスページだけです。
今ここに問題があります:
アプリケーション全体は、関数を異なる名前空間にラップすることを中心に構築されています。そして、私が見るところによると、ページのHTMLのレンダリングのような単純な関数は、異なる名前空間全体で2つ以上の関数を呼び出すことで実現できます...
私の最初の考えは「これは完璧な解決策のようには思えない」であり、コードを維持し、それを将来的に拡張することに関する多くの問題を想像することができます。
私はすぐにプロジェクトを前進させることに取り組み始め、比較的大量のJavaScriptコードの作成と管理に関して、適切なケースプラクティスについて提案をしたいと思います。
これは非常に良い質問であり、JavaScriptアーキテクチャを進歩させる上での一般的な問題です。
「密結合」の状況を説明しているように思えます。
関数がオブジェクト化されると、名前空間間でさえ、オブジェクトからオブジェクトへ、これらの素晴らしいオブジェクトを直接参照する傾向があります。簡単だからですよね?
var Object1, Object2 = {};
Object1.somefunction = function(){
//Tight Coupling!!
Object2.functionCall();
}
簡単ですが、これらの一見無害なハード参照がつながって、オブジェクトを削除または置換する必要があるときに悲しくなります。これはJavaScriptでよく発生するため、JSコードベースを保守可能にするためには、密結合を理解することが重要です。
ここにいくつかの他の考えがあります:
1-オブジェクトがまだ通信していない場合-イベントのトリガーとリスニング。彼らはする必要があります。これは、ハードリファレンスの解決策です。
2-デザインパターン。すでに解決されている多くの課題があり、標準化された再利用可能なソリューションはデザインパターンです。
パターンがどこにあるかを理解することは、意味のあるソリューションに焦点を合わせるのに役立ちます。オブジェクト間で通信するための1つのパターンは、Publisher/SubscriberまたはPubSubと呼ばれます。
3-これらは保守性に役立ちます:ルーターを備えたMVC、テンプレート-データバインディング、AJAX-プロキシまたはデリゲートオブジェクトを介して。
4-クロスブラウザの問題を解決するフレームワークとライブラリを探します。あなたがもっと知る必要のない車輪を再発明しないでください。環境によっては、いくつかのフレームワークが明白な選択になる場合があります。
5-ビルドシステム、ミニファイ、リンティング、tddなどの拡張と最適化について考えます。
6-また、最も重要なのはモジュールローダーです。 Require.jsを見てください。これは、JSをモジュールに分割し、それらすべてを最適化された方法でロードするための非常に優れた方法です。
お役に立てば幸いです。
私は Steal JS とも呼ばれるJavaScriptモジュールの管理と圧縮を検討することをお勧めします。これは、優れた JavaScript MVC フレームワークの一部です。これは、大規模なJSアプリケーションにとって一般的に興味深いものです。開発中にモジュールファイルを動的にロードでき、本番環境では1つの圧縮JavaScriptファイルを作成できます(CSSも実行できます)。
見る別の方法は RequireJS です。しかし、私はそれを深く探求しませんでした。そのオプションを覚えておいてください。