摘要：滬江網?，F在的架構是怎么樣的基于以上原則，在搭建架構的時候，經過討論和嘗試，我們最終確定出個方向，模塊化，組件化，工程化，規范化。

作者: 未來
本文轉自互聯網技術聯盟（ITA1024）技術分享實錄

起初前端是沒有架構的，大家只是在完成一個一個的頁面。我們來看看會發生什么。

A同事是一個非常有意思的人，他喜歡把跟這個頁面相關的所有的JS都寫在同一個文件里面。嗯，傳說中2000行代碼的JS文件就是這么出來的。

B同事是一個對技術比較有追求的人。他覺得模塊化不錯，所以他在自己做的頁面里選用了requireJS。看上去不錯哦，巧的是C同事也是一個對技術有追求的人，但是他不喜歡AMD的規范，所以他支持國貨seaJS，哦，他還在里面使用了他喜歡的模版引擎Jade。

嗯，同一個網站，每個頁面的技術選擇完全不一樣的。別忘了，網站是需要維護的，修Bug阿，改需求啊。有一天B同事跑去負責C同事做的那個頁面的需求改動，當他看到那些他不熟悉的技術時，內心是極度崩潰的。

D同事玩的就比較高級了，他喜歡寫es6，也用sass。這就要求無論在開發的時候還是發布的時候代碼都要先編譯，而且顯然你是不可能每次都是手動去做這個事情的。這就是他對工程化有需求了。

這個時候他很可能選擇放棄，或者妥協（只使用少部分構建工具很好支持的功能），畢竟要實現一套完整的工程化是很花時間的事情（即使只是支持他自己的頁面），而程序員的時間往往會被業務需求所淹沒。畢竟以單個人和單個頁面的單位來看，工程化這個東西是得不償失的，如果以團隊和整個系統去看那就不一樣了。

其實到這里就可以看出來，個人所使用的技術的天花板往往會被整個團隊的現狀所制約。

上面描述的是沒有架構的時候發生的情況，這些情況看上去當然都不太好，但是如果跳出前端這個角色，我們怎么去描述說這些問題會造成的影響，反過來的意思就是，如果有一個統一架構能夠帶來的好處。

回答出這個問題，可以解決兩方面的困擾。

第一是說服大團隊里的其它角色前端架構這件事情的重要性（在現在的大環境下，這個其實很重要）；

第二是自己要時刻記住架構的目的，能夠不忘初心，不沉迷于形式和概念。

現在回過頭來看看，

答案是提升質量和效率。

沒有架構的情況下，新技術無法得到引入，技術無法統一，使得團隊的整體技術能力無法得到提升，也無法提供技術上的通用解決方案，從團隊的角度來考量的話，效率是非常低下的。

同時，因為技術過于陳舊，再加上代碼沒有統一規范，導致碰到頁面業務邏輯比較復雜，或者對老頁面進行維護的時候，產生Bug的概率非常高，產品質量堪憂。

上面講到，架構的目的是提升質量和效率。那我們看看架構應該做到哪些方面才能實現這個目的。

架構是一個抽象的過程，它是架構師根據自己的經驗對大量具體的業務項目進行分析，發現其中的規律，抽象出具體的規范，最終又應用于具體的業務項目中去。比如常說的MVVM就是一種規范。

要把跟業務無關的問題都在架構層面處理掉。比如代碼壓縮，打包這種工程化的問題都要在架構層面統一解決的。要做到業務的歸業務，架構的歸架構。

架構要考慮到可以方便團隊成員提供和使用通用技術解決方案。比如分頁組件這種。

架構設計的時候要綜合考慮當前的主流技術跟自己業務系統的實際情況。因為前端正處在高速發展，各種新技術，工具，插件，框架層出不窮，這個時候要特別謹慎，有時候一個坑跳下去，就呵呵了。

基于以上原則，在搭建架構的時候，經過討論和嘗試，我們最終確定出4個方向，模塊化，組件化，工程化，規范化。（你也看出來了，大方向是跟主流走的，太陽底下沒有新鮮事啊。）

說了這么多虛的^_^，下面來點干貨。

構建工具用的是webpack，發布系統用的是jekins。

構建這里是分開發環境和生產環境。開發環境需要提供jsmap, css map，livereload等開發時候需要的功能，而生產環境需要壓縮，打包，靜態資源文件名添加hash等功能的。這里插一句，如果要啟動開發環境，只需要 npm start。

現在都是commonJS當道了，所以選擇es6+ babel。這里順便提下我們使用的框架，PC端knockout(為了支持IE7)， 觸屏端和hybrid端redux+react。

這一塊我們是做的挺徹底的，也思考了很多。

我們的頁面是由一顆組件樹組成的?？聪聢D，invitationActivity代表了一個頁面，components下面的每一個文件夾都代表一個組件。每個組件包含自己需要的js，css，image等資源。

保證組件的封閉性。因為JS方面是模塊化的，在css方面我們也引入了cssmodule來做到這點。

組件的功能界限問題。也就是什么是應該在組件內部實現，什么是應該由組件的調用者來實現的。看下圖，下面這個界面會封裝成一個業務組件，因為很多頁面上都會有這個組件，所以在我們的系統里面，它是被當作一個公用組件的。順便提下，這個組件本身是由多個子組件組成的。

為了顯示熱門詞匯有哪些熱詞，需要調接口從后臺獲取。那在哪里去調用接口呢，是組件本身去調用，還是由使用者傳進來。

現在點擊搜索按鈕，需要跳轉到搜索結果頁（還有可能要打點）。那完成這些操作的代碼寫在哪里呢？是直接寫在組件里面還是由調用者傳入，由組件在相應的時機調用傳入的函數。

這就是組件的功能界限問題。我們的做法是組件只負責跟UI顯示相關的部分，所有業務邏輯都不屬于組件本身的功能。

根據這個原則，我們來回答上面的問題。

組件只負責顯示熱詞，至于具體有哪些熱詞，由它的調用者傳入。

組件只知道搜索按鈕被點擊了，至于按鈕被點擊具體要做些什么，它是不知道的，它能做的就是調用傳給它的回調函數。

備注：關于組件的功能界限問題我們也思考了很長時間，并且做過不同的嘗試。比如把 點擊搜索按鈕要做的事情放在組件里面自己做怎么樣呢，后來發現不同的頁面上點擊搜索按鈕需要打點的關鍵字是不一樣的，這時候你如果把組件寫死了就沒法重用 這個組件了。其中關于接口調用是不是要寫在組件內部的問題更是一度相持不下，似乎兩邊都有點道理。后來碰到一個真實的事情就是因為接口調用都寫在組件里 面，導致同一個接口在某個頁面上被調用了兩次。當這件事情發生之后，天平似乎往另外一邊傾斜了點。

一般組件化開發之后，我們會碰到兩個方面的問題。

第一個問題是我們去看別人的代碼的時候，沒辦法方便的知道這個頁面的組件樹是怎么組成的，以及每個組件需要哪些數據。

第二個問題是當組件樹的層次很深的時候，父子組件間參數的傳遞會非常繁瑣。而且一旦需要增加或刪減掉某個參數的時候，整個父組件到根組件路徑上所有組件參數的傳遞都要修改。

關于第二個問題，也就是父子組件之間參數傳遞的問題，我舉個例子來詳細說明。假設現在組件樹的結構是這樣的。

A組件所有子組件加起來需要的參數是9個，那么調用A組件的寫法是

然后在A組件內部，A組件本身只需要參數a1，其它的八個參數是被它的子組件B1，B2消費的。那么A組件內部的寫法大概是這樣的。

，

B1組件本身不需要參數，四個參數都是被子組件C1，C2消費。那么B1組件內部的寫法大概是這樣的。

，

這個時候已經可以看出來，如果C1需要增加或者刪減一個參數，從組件本身C1到根組件A之間的所有組件都需要改動。想象一下當組件樹的橫向和縱向的層次都變的非常深的時候，這個時候每個組件的參數傳遞都會變的非常龐大而且混亂。

如果要把一個組件的位置換一下的話，要改變的地方之多，也是讓人非常頭疼的。我們想了一個方案來同時解決這兩個問題，看下圖，

我們每個頁面都有一個param.js文件，可以看到從param.js里面可以清晰的看到當前這顆組件樹的結構，以及每個組件自己需要的參數。而在組件內部，寫法也相當簡單，以A組件內部為例，組件內部的寫法是這樣的，

，

可以看到，這樣的話，無論是增減參數還是移動某個組件，都會變的非常簡單。

由于我們對組件功能界限的定義是只負責UI相關的功能，所有的業務邏輯都是從調用者傳遞過的。也即是寫在param.js。所以param.js文件是非常重要的一個文件，里面基本包涵了這個頁面所有業務處理邏輯。

很顯然，隨著頁面業務邏輯變的復雜，param.js將會變得越來越大。沒關系，把不同的組件參數分拆到不同的js文件里面去實現，然后建個params文件夾把它們組織起來。

JS語法檢查選用了eslint。

項目目錄結構非常清晰。當進行開發的時候，哪些代碼應該放到哪里都進行了明確的規定，并且每個文件的功能都盡量清晰并且單一。

頂層目錄結構如下圖：

src文件夾存放的是所有的的源代碼和其他靜態資源（比如圖片，iconfont)。

dist文件夾存放的是所有編譯后的代碼。

build文件夾存放的是所有工程化所需要的代碼。

document文件夾當然存放的文檔。

下面重點看下src目錄結構，如下圖：

app文件夾里的每一個子文件夾代表了一個頁面，每個頁面所用到的所有靜態資源都存放在這個子文件下面（除了引用的公共資源以外），構建的時候，每個子文件夾會生成自己的靜態資源供頁面引用。

common文件夾里面的所有代碼在構建的時候會多帶帶生成js文件和css文件供頁面引用。所以一個頁面會引用兩個js和兩個css.里面存放的是每個頁面都會用到的一些共用資源。比如觸屏端使用了react,那么跟react相關的那些包就會放在common里面。

components文件夾里面存放的是共用組件，每一個子文件夾代表了一個組件。有可能是通用的功能組件，比如分頁組件，Loading組件，ModalDialog組件。也有可能是一個通用的業務組件，比如站點通用頭部，通用footer，通用分享組件。注意，在其他地方引用這些組件時，是不需要寫相對路徑的，直接寫組件名字就可以了，比如import pager from ‘pager’。這樣對使用者更方便。

lib文件夾存放的是通用的js類庫。比如檢測瀏覽器用的browserDetect.js,處理日期用的dateUtil.js。同樣的，在其他地方需要引入這些JS時，也不需要寫相對路徑，直接寫JS的名字就可以了。比如import{isIE} from ‘browserDetect’。

style文件夾里面存放的一些公用的sass資源。比如function,mixing, variable。其他的sass文件需要引入這些資源的時候，使用方式跟使用通用js一樣，直接@import “base.scss"即可。

滬江網校的架構才剛剛有個雛形，后面還有更多的功能會加進來，比如腳手架（等到架構更成熟的時候在出一套完整的），NodeJS中間層（在大方向上已經達成統一），前端監控系統等。

架構是個不斷完善的過程，而把架構尤其是跟規范相關的部分落實到具體業務系統里面更是個團隊不斷磨合的過程。它最終考驗的，同時也是最終磨合出來的是團隊的成熟度。

謝謝大家。

iKcamp原創新書《移動Web前端高效開發實戰》已在亞馬遜、京東、當當開售。