大規模プロジェクトの開発における問題

確かに、この傾向には論理的な説明が1つあります。他の人の製品に関わることへの恐怖です。開発中に、そのようなインターフェイスをアクセシブルなツールで開発するのは非常に難しくなり、松葉杖、他の人のフレームワークの編集などが生まれます。 この問題の解決策を提案したいと思います。 インターフェイス(モジュール)のマネージャーの作成。 1つのモジュールでExtJS、別のdhtmlx、または純粋なJavascriptを使用できます
見知らぬ人ではない-しかし、オープン
既製のソリューションを使用する利点は何ですか? 有名なサードパーティ製品を使用すると、プロジェクトの新しい人を見つけるのが簡単になります。 あなたがフレームワークの唯一の作成者であり、辞めることにした状況では、おそらく新しいチームがすべてをゼロから書き直します。 さらに、ビジネスロジックの作業中にバグを編集し、新しい機能を追加します。 プレゼンテーションからデータを分離する強力な武器が必要な場合-たとえばExtJSを使用する場合、独自のフレームワークを作成する理由!? 依存関係を動的に読み込む必要があります-YepNopeに注目してください。 domと連携し、jQueryまたはその他のよく知られているフレームワークを提供します。 結果に注目してください。 ほとんどのプログラマーはゼロからすべてを書くのが大好きだと理解していますが、これは彼が学び、開発したいからではありません...それは怠fromからです...はい、それは怠からです。 他の人のコードを勉強し、ドキュメントを読むことは、すべてをゼロから開発するよりもはるかに複雑です。 すべてを「ゼロから」書くと、多くは学ばず、人々は主に他の人から学び、他の人の仕事を研究している間、あなたは経験から学び
2か月の期間を与えられたERPを開発する代わりに、独自のフレームワークを作成する場合は、OS ...またはプロセッサアーキテクチャから始めましょう...
多くの病気の治療法としてのモジュール性
モジュール性は、複雑なシステムを別々の部分、つまりモジュールに分割する原則です。 メリット-システムの開発、テスト、メンテナンスを簡素化し、システムの異なる部分間の接続数を最小限に抑えます。
カーネルとモジュールの開発は、チーム内の異なる人々が、互いに干渉することなく実行できます。 カーネルまたはモジュールのリファクタリングは相互に影響を与えることはなく、並行して独立して実行できます。
コアはすべての頭です
アプリケーションコアはシステムパーツマネージャーです。 スーパーバイザーとして機能する会社のトップマネージャー。 リソースへのアクセスと企業施設間の通信を制御します。 しかし、倉庫への商品の積み込み、規定の発行などを制御する方法はありません。 タスクを委任するユーティリティとライブラリにこれを実行させます。
中核的な責任は次のとおりです。
- ロードモジュールの委任とライブラリ
部門への必要な依存関係(この場合、YepNopeを選択しました)。 - モジュールインターフェイスのキャンバスを作成する委任。
- モジュール間の情報転送。
- システムイベントの通知(アプリケーションの終了、新しいモジュールのアクティブ化、ウィンドウのサイズ変更、サーバーとの接続の切断など)。
- モジュールリクエストの実行(例:別のモジュールのロード)
カーネルの簡易バージョン:
/*=== core.js ===*/ !function () { var listOfLibraries = {}; $(window).resize(function() { $.each(listOfLibraries, function(){ this.body.onResize($(window).width(), $(window).height()); }); }); $("script[id=core]").bind('request', function (data) { switch (data.header) { case "attach": var library = { name: data.body.name, body: new data.body.module() }; listOfLibraries[library.name] = library; $('<div id="'+library.name+'"></div>').appendTo('body'); var moduleContext = $('#'+library.name); library.body.main(moduleContext); break; } }); }();
ロード後、カーネルは要求メッセージチャネルをリッスンし、新しいモジュールが接続されると、それをlistOfLibrariesコレクションに追加します。 このコレクションには、ロードされたすべてのモジュールが格納されます。
モジュールに独立性を与えてください!
モジュールの例:
/*=== HelloWorld.js ===*/ !function () { var Lib = function () { var context; this.main = function (moduleContext) { context = moduleContext; context.html('Hello World'); } this.onResize = function(width, height){ context.width(width); context.height(height); } } $("script[id=core]").trigger({ type: "request", header: "attach", body: { module: Lib, name: "HelloWorld" } }); } ();
この例からわかるように、カーネルはイベント、または1つのイベント「要求」、つまりメッセージプールによって外部コンポーネントと通信します。
メッセージの本文は、 ヘッダーと本文で構成されます。 この場合、モジュールは「HelloWorld」という名前でシステムに登録することをカーネルに伝え、モジュール本体へのリンクを報告します。
各モジュールは、動作する必要があるカーネルからコンテキストを受け取ります。 カーネル、他のモジュール、またはページ要素との通信は、メッセージを介して行う必要があります。
モジュール内にコンテキストを簡単に作成して操作できるのに、なぜカーネルが必要なのですか?
答えは、マルチウィンドウインターフェイスを実装し、モジュールをオンデマンドでロードし、モジュールの依存関係をロードできるようにし、モジュール間に単一の通信システムを作成し、コードを単純に維持するなどです。
その結果、カーネルロジックが完全に変更されても、モジュールのコードが変更されない軽量のモジュールソリューションが得られました。
すべての変更は、新しいイベントの追加のみに関係します。 カーネルとモジュール間の通信用のインターフェースを統一するには、基本的なルーチン実装を持つ抽象クラスを強調表示し、そこからモジュールのすべてのLibクラスを継承することをお勧めします。
window.Module = function () { this.context; } window.Module.prototype = { main: function (context) { this.context = context; }, onResize: function (width, height) { } }
モジュールをカーネルに接続する場合、プラグインが抽象クラスModuleの機能を継承することを確認するだけでよく、成功した場合は、システムに接続します。
GitHubで完全なプロジェクトコードを見る