で CodeInsight 開発が終了した後に、CTOの大人は私が入れたい見つける Coding.netに 前分割再建プログラムをので、私は呪文のテストに直面してオフにする喜びを開発する状態からの切り替えを開始しました。
一つの時のクールな動的言語、リファクタリングの火葬場。
いずれにせよ、現状で始めるには、櫛を始めました。
角度ビルドフロントエンドコーディング、フロントエンドエンジニアリングやパッケージ化の方法を使用してファイルをマージし、サイトのサイズの増加に伴って、フロントエンドのコードはますます肥大化している、などSPAのウェブサイトなどのモジュラー開発アプローチのCommonJSを導入しません開発の経験はまた、我々は理由の再構築を検討している、急落しました。
復興の問題を解決するために、我々が知りたいすべてのだから、最初の
- コードパッキング分割は、単一のパッケージファイルにすべての機能モジュールを避けます
- モジュラーCommonJSの導入は、より明確な達成します
- 運転中にホイールを変更
最後の点は行うことは特に困難であるが、それはまた、首尾よく再構築する当社の能力の鍵となり、再構成が書き換えられていないので、既存のコードベース、およびまた、現在の開発の進捗状況を再構築する方法と、それがシームレスです課題は、我々が直面しなければなりません。
良いニュースは、我々は、包装の層と角度符号分割モジュールの私達の使用は、あまりにも散乱されないことを保証することです。フロントエンドルートとしてSPAのウェブサイトでは、さまざまな機能モジュールの非常に良好な分離されています。私たちは、日付のうちビットは、タスクが少し複雑に書かれたものの、うなり声を使用しますが、設計のエントリポイントを提供します。
議論の小さなパートナーのいくつかのラウンド後、より信頼性の高いソリューションを確定します。
- その機能リフレッシュ/解像度コードによると、
- SPAは、ルーティング機能モジュール遅延ロードによると、ウェブサイトとして残りました
この後者の点は、私たちは、各機能モジュールを実行するために別々のユニットを分割されて考慮しなければならない前に、私たちのリフォームアイデアの中核であるが、ことを確実にするために、「運転しながらホイールを変更、」高速反復再構成でなければなりませんもちろん、一つは、これは長い時間のかかるプロセスとなり、リスクも高く、既存のコードに統合され、完全な機能モジュールユニットの再構築まで何度も繰り返していることリファクタリング方法を言うことができません。
「運転中にホイールを変更します。」となるよう、遅延読み込みの導入をSPAをしてください、我々はすぐに、それは各コントローラに洗練することができた後、再構成プロセスの実現可能性を検証するために、既存のコードに、このアーキテクチャの調整を統合することができます。
Split関数モジュール
このステップは、ウェブサイトの機能モジュールは、このような泡立ち、タスク、検索、およびので、我々は唯一のコードを再配置するために統一されたディレクトリ構造と名前空間の仕様を確立する必要があり、感謝の角度依存性として、比較的明らかにされているコーディング、非常に簡単ですコードのロジックは、これらの独立したモジュールのために変わらないことができます前に、注入機構は、この再構成プロセスは、再構成モジュールの名前空間はそれを修正し、本質的に任意の導入回帰バグの心配はありません。
我々は、合意されました:
- 各コントローラ、サービスの復興などは、自分の名前空間(仕様)を持っています
- 各機能モジュールは、独自のルートを定義するには
- 各モジュールは、すべての依存注入ユニークな機能モジュールを持っています
再構成された構造をバブリングなどはこのようにしてもよいです。
tweet/
├── tweet-list.controller.js
├── tweet-list.html
├── tweet-topic.controller.js
├── tweet-topic.html
├── tweet.module.js
└── tweet.routes.js
tweet.routes.jsは遅延ロードtweet.module.jsを指定します。
WebPACKの遅延ロード
唯一のナビゲーション機能モジュールが一緒のWebPACKのCommonJSのサポートや遅延ロードを達成するための導入により、コードをロードするために、対応する機能モジュールに対応する際の包装コードの解決を行うために、我々は、遅延ロードを使用します。
すべてはCommonJSを使用することができ、入口モジュール上の文書の導入に依存している、角度の既存のルートはよく分離された機能モジュールの入口となっているので、我々は、単にファイルのエントリのWebPACKパッケージとして、ルートエントリポイントとしてファイルを置きます道の、そしてそれは、我々は、コードを再構築することができ、すべてがシンプルなここで、自動的に、収束コードをWebPACKのは完璧なバインダーとなるCommonJSを、使用に移行し、既存のコードをリファクタリングされていますルーティングがどのように行われるかを見てみましょう。
./tweet/tweet.routes.js
$routeProvider.when('/pp/:region?', {
templateUrl: require('./tweet-list.html'),
controller: 'TweetListController',
title: '冒泡',
resolve: {
lazyLoader: function($q, $ocLazyLoad) {
var defer = $q.defer();
require.ensure([], function() {
var module = require('./tweet.module');
$ocLazyLoad.load({ name: module.name });
defer.resolve(module);
});
return defer.promise;
}
}
});
角度ルーティングサポート非同期ローディングは、require.ensureのWebPACKのは、TweetListControllerとして、この機能モジュール噴射モジュールツイートに依存するすべて、内部コールバック関数に非同期指定tweet.module.jsロードされます
'use strict';
var angular = require('angular');
module.exports = angular
.module('tweet', [
require('./tweet-list.controller').name,
require('./tweet-topic.controller').name,
]);
最後に、我々は使用 ocLazyLoadを 非同期にロードされ、このモジュールを注入します。
作男-のWebPACK
新たに導入されたのWebPACKは簡単に使用し、内側に行くために私達の既存の開発プロセスに統合することができ 作男-のWebPACKを うなり声コールに新しいタスクとしてのWebPACKを置くことができますので、私たちは、ビルドプロセスの独立のWebPACKをパッケージ化することができ、そして子としてオリジナルの開発/パブリッシュに影響を与えることなく、ビルドプロセスに元のタスク、。
gruntfile.js
...
webpack: {
dev: {
entry: {
'routes': ['./src/routes.js'],
},
...
},
prod: { ... }
}
grunt.registerTask('server', [..., 'webpack:dev', ...]);
grunt.registerTask('build', [..., 'webpack:prod', ...]);
...
共通モジュール
独立のために、モジュールの残りの部分に依存しない、改造は、あなたがこのモジュールを再構築することができますが、非常に便利な、しかし、一般的なモジュールにすることができますが、このモジュールのすべての参照を変更するには、コードが制御不能ビットを必要としますA。
だから我々はすべてのモジュールの再構築に合意し、独自の名前空間を持つことになり、それらの共通モジュールのために、新しい名前空間への移行、そして我々が時点に他の機能モジュールを再構築するまでには、前のコードを保持します、これらのモジュールに依存しないコードの初めの部分が冗長になりますが、私たちの復興の品質や進捗状況を確認するためにでて、クリーンアップ行き、共通のモジュールが保持されているかを決定することができます。
これまでのところ、道路の前面開口部の再建をコーディング、私は信じている HTTPを:// Coding.netは 徐々に、より良い経験をもたらすでしょう。