前端重構之路01

在 codeinsight 開發告一段落之後，cto 大人找到我說要想乙個把 coding.net 的前端拆分重構的方案，於是我從乙個歡脫的開發狀態開始切換到要面對一句魔咒的考驗。

動態語言一時爽，**重構火葬場。

不管怎麼樣，先從梳理現狀開始。

coding 前端使用 angular 構建，前端工程化還是使用合併檔案打包的方式，並沒有引入 commonjs 之類的模組化開發方式，作為乙個 spa **，隨著**規模的增大，前端**開始越來越臃腫，開發體驗也直線下降，這是我們考慮重構的原因。

所以首先我們要想清楚重構要解決的問題

要做到最後一點尤其困難，但這也是我們能否順利重構的關鍵，重構不是重寫，所以如何在現有**基礎上重構，並且還要和當前的開發進度無縫銜接起來就是我們所要面臨的乙個挑戰。

好訊息是我們使用了 angular 保證了我們的**分 module 有了一層封裝，不至於太過散亂。作為乙個 spa **，前端路由已經很好的分離出了各個功能模組。我們用到了 grunt，雖然有點過時，task 寫得有點複雜，但是提供了乙個工程化的切入口。

經過小夥伴們幾輪討論之後，最終確定了一套比較靠譜的方案：

後一點是我們這套重構思路的核心，在這之前我們有考慮把每個功能模組拆分出獨立的單元來跑，但是為了保證「邊開車邊換輪子」，重構必須是乙個快速迭代的過程，不能說等到某乙個完整的功能模組單元重構完了再去整合到現有的**，這種重構方式將是乙個漫長耗時的過程，並且風險也很大。

保持 spa，引入懶載入，我們可以快速將這種架構調整整合到現有**中去，驗證是否可行，之後的重構過程就可以細化到每乙個 controller，做到「邊開車邊換輪子」。

這一步很簡單，coding **的功能模組已經比較清晰了，比如冒泡，任務，搜尋等等，我們只需要確立一套統一的目錄結構和命名空間規範來重新整理**，得益於 angular 的依賴注入機制，之前的**邏輯完全可以保持不變，對於那些獨立的模組，這個重構過程基本上沒有什麼引入 regression bugs 的風險，重構乙個模組只是修改命名空間而已。

我們約定：

比如重構後的冒泡可能是類似這樣的結構：

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 一併實現了對 commonjs 的支援以及 lazy load。

現有的 angular 路由已經很好的分離出了功能模組入口，所以我們只要把這個路由檔案當做乙個切入點，作為 webpack 的打包入口檔案，由這個入口檔案引入的所有依賴就都可以使用 commonjs 的模組化方式了，也就是說我們所有重構的**自然而然就可以遷移到使用 commonjs，在這裡 webpack 將作為乙個完美的粘合劑，銜接現有的**和重構後的**，這裡通過乙個簡單的路由來看一下是如何做到的。

./tweet/tweet.routes.js

$routeprovider.when('/pp/:region?', );
defer.resolve(module);
});return defer.promise;}}
});

angular 的路由支援非同步載入，require.ensure 是 webpack 用來非同步載入**函式內部指定的 tweet.module.js，這個 module 注入了 tweet 這個功能模組的所有依賴，比如tweetlistcontroller

'use strict';
var angular = require('angular');
module.exports = angular
.module('tweet', [
require('./tweet-list.controller').name,
require('./tweet-topic.controller').name,
]);

最後我們用到了 oclazyload 來注入這個非同步載入的 module。

新引入的 webpack 可以很容易的整合到我們現有的開發流程裡面去，使用 grunt-webpack 就可以把 webpack 作為乙個新的任務給 grunt 呼叫，所以我們可以獨立 webpack 的打包編譯流程，並且作為乙個子任務插入原來的編譯流程，而不影響原來的開發／發布方式。

gruntfile.js

...
webpack: ,
...},
prod: 
}grunt.registertask('server', [..., 'webpack:dev', ...]);
grunt.registertask('build', [..., 'webpack:prod', ...]);
...

對於獨立的，不被其他地方依賴的 module，重構可以很方便，但是對於公用的模組，雖然可以重構這個模組，但是要更改所有針對這個模組的引用，牽涉到的**就有點不受控制了。

所以我們才要約定所有重構的模組都會有自己的命名空間，對於那些公用的模組，遷移到新的命名空間，同時會保留之前的**，直到我們重構其他功能模組到某個時間點，可以確定沒有模組依賴這些被保留的公用模組，再去清理，這樣在前期會有一部分**冗餘，但是保證了我們重構的質量和進度。

至此，coding 前端開啟了重構之路，相信

將會逐步帶來更好的體驗。

前端重構之路01

動態重構 01

重構構建的平凡之路

重構之路開始配置webpack

前端重構之路01

動態重構 01

重構構建的平凡之路

重構之路 開始配置webpack

相關推薦

重構之路開始配置webpack