大前端架構(gòu)思考與選擇

作者：老章888

原文：https://www.jianshu.com/p/bb8ac7db7e2d

問(wèn)題

• “一云多端”成為趨勢(shì)，終端類(lèi)型越來(lái)越多。比如，現(xiàn)在PC Web網(wǎng)站的產(chǎn)品已經(jīng)有了，現(xiàn)在想擴(kuò)展APP，小程序... ...怎么辦？一個(gè)直接能想到的方法就是在原來(lái)的基礎(chǔ)上，為APP等增加API接口，如下圖所示：

這樣做是可以的，然而一旦遇到修改，那么要同時(shí)修改幾個(gè)端的代碼，很麻煩，不是很完美。

• “前后端分離”成為趨勢(shì)。一開(kāi)始的PC Web網(wǎng)站，大多是采用服務(wù)端渲染的前后端一體化的模式。隨著技術(shù)的發(fā)展，前后端分離，前端渲染逐漸成為趨勢(shì)。相應(yīng)地，前端開(kāi)發(fā)人員也從后端團(tuán)隊(duì)中獨(dú)立出來(lái)。

最近興起的APP，小程序等，天生就是前后端分離的。
前端，APP，小程序等各自獨(dú)立成專(zhuān)門(mén)的團(tuán)隊(duì)，當(dāng)然可以滿(mǎn)足這種趨勢(shì)。
相應(yīng)地服務(wù)端需要為每一個(gè)前端部門(mén)提供服務(wù)，在實(shí)踐中常常發(fā)現(xiàn)，重復(fù)的內(nèi)容很多，有沒(méi)有辦法增加復(fù)用？或者說(shuō)后端能否只對(duì)接一個(gè)“大前端”部門(mén)，剩下的“大前端”部門(mén)內(nèi)部自己解決？

• 
  

  

  
  

• 服務(wù)端設(shè)計(jì)的API接口，面向通用服務(wù)，還是面向UI？各個(gè)端對(duì)數(shù)據(jù)的顯示要求不同，給一個(gè)公共的API還是分別給不同的API？

比如，時(shí)間顯示，PC端可能要求“2018-6-11”的格式，而APP端可能要求“2018/6/11”的格式，接口怎么給？

再比如，相同功能的一個(gè)接口，PC Web端需要20個(gè)字段，已經(jīng)做好了?，F(xiàn)在APP端因?yàn)槠聊恍?，只?0個(gè)字段就夠了，是復(fù)用老的API，讓APP忍受垃圾信息，還是為APP額外新增一個(gè)接口？

前端和服務(wù)端人員可能會(huì)有不同意見(jiàn)，這就帶來(lái)了沖突。大家都有一定的道理，怎么協(xié)調(diào)？

• 產(chǎn)品經(jīng)理提出PRD-》UED設(shè)計(jì)交互稿-》UI設(shè)計(jì)界面-》后臺(tái)設(shè)計(jì)API接口-》后臺(tái)實(shí)現(xiàn)服務(wù)-》前后端聯(lián)調(diào)... ...

以上是一般的開(kāi)發(fā)流程，整個(gè)過(guò)程還是比較長(zhǎng)的。前端在開(kāi)發(fā)完靜態(tài)頁(yè)面之后，常常需要等后臺(tái)服務(wù)開(kāi)發(fā)好了，才能聯(lián)調(diào)，這里往往有等待時(shí)間的浪費(fèi)。等后臺(tái)服務(wù)好了，往往提測(cè)時(shí)間也臨近了，氣氛很緊張。整個(gè)開(kāi)發(fā)體驗(yàn)，往往就是“一半是海水，一半是火焰”。有沒(méi)有辦法縮短這個(gè)流程，并且能夠讓前端不依賴(lài)后臺(tái)服務(wù)的完成，獨(dú)自完成開(kāi)發(fā)？

架構(gòu)

從現(xiàn)狀來(lái)看，前后端分離之后，服務(wù)端直接給各種端提供服務(wù)是很自然能夠想到的一種方式。這種方式的優(yōu)點(diǎn)是簡(jiǎn)單直接，缺點(diǎn)是不夠靈活。因此，考慮在前端和后端之間插入一個(gè)中間層，作為前后端之間的橋梁，增加靈活性。

對(duì)于這個(gè)中間層的稱(chēng)呼，一種是“網(wǎng)關(guān)層或者接入層”，這個(gè)可能會(huì)和后臺(tái)現(xiàn)有的網(wǎng)關(guān)和接入層造成混淆。另一種叫法叫做BFF(Backend for Frontends，為前端而存在的后端)，這種稱(chēng)呼相對(duì)比較準(zhǔn)確，不會(huì)帶來(lái)混淆。

• 網(wǎng)關(guān)層或者接入層

• BFF(Backend for Frontends，為前端而存在的后端)

解決方法

• 針對(duì)“一云多端”，可以在BFF層做適配。可以考慮MVVM的模式，從服務(wù)器來(lái)的數(shù)據(jù)當(dāng)做Model，在BFF中針對(duì)各種端，提供不同的ViewModel。如果數(shù)據(jù)變了，只要修改Model就可以了。如果要增加一種端，只要增加一個(gè)ViewModel就可以了。在這里集中修改，就可以解放各個(gè)終端的格式轉(zhuǎn)化工作。

• “前后端分離”之后，各種端可以融合為一個(gè)“大前端”，跟后端對(duì)話(huà)的窗口就是BFF。對(duì)于后端來(lái)說(shuō)，只要滿(mǎn)足BFF的數(shù)據(jù)需求就可以了，剩下的事情，就讓“大前端”內(nèi)部自己解決。

• 服務(wù)端設(shè)計(jì)的API接口，面向通用服務(wù)，不需要面向UI。各種端的UI差異，由BFF層負(fù)責(zé)適配。這樣的話(huà)，可以讓后端更加專(zhuān)注于業(yè)務(wù)邏輯和數(shù)據(jù)服務(wù)，不需要操心各種端的差異。

• 整個(gè)開(kāi)發(fā)流程太長(zhǎng)，導(dǎo)致相互等待，造成浪費(fèi)。針對(duì)這個(gè)問(wèn)題，可以考慮在BFF層將開(kāi)發(fā)流程分為兩部分?！按笄岸恕弊鳛橐粋€(gè)獨(dú)立開(kāi)發(fā)部門(mén)，領(lǐng)先后端一個(gè)版本發(fā)布周期。

具體做法是，對(duì)于新業(yè)務(wù)，將Mock數(shù)據(jù)生成在BFF層，對(duì)于各種端來(lái)說(shuō)，相當(dāng)于后端服務(wù)已經(jīng)好了，可以直接進(jìn)行聯(lián)調(diào)，不需要等待。這樣就把前端對(duì)后端的數(shù)據(jù)依賴(lài)去除了，更加靈活。

組織結(jié)構(gòu)

針對(duì)上面提到的“大前端”技術(shù)架構(gòu)，需要相應(yīng)的“大前端”組織結(jié)構(gòu)相對(duì)應(yīng)。

分類(lèi)思路

• “大前端”是針對(duì)整個(gè)后端來(lái)說(shuō)的，所以這一層是按照職能來(lái)分的

• 在“大前端”下面，是否仍然按照職能來(lái)分呢？比如iOS開(kāi)發(fā)，Android開(kāi)發(fā)，H5開(kāi)發(fā)等等。這種分法是可行的，然而收益不是很大。這只是將一個(gè)個(gè)小部門(mén)“組合成”一個(gè)相對(duì)大的部門(mén)，融合度不是很高。
  另外一種融合度更高的劃分方法是在“大前端”下劃分為“基礎(chǔ)服務(wù)”，“業(yè)務(wù)開(kāi)發(fā)”兩個(gè)子部門(mén)。

• “基礎(chǔ)服務(wù)”的主要職責(zé)是為整個(gè)“大前端”部門(mén)提供公共服務(wù)，公共組件，周邊設(shè)施等等。根據(jù)需要和實(shí)際情況可以分為“架構(gòu)”、“工具”、“組件”等小組

• “業(yè)務(wù)開(kāi)發(fā)”的主要職責(zé)完成業(yè)務(wù)部門(mén)的需求。根據(jù)業(yè)務(wù)發(fā)展情況，按照具體業(yè)務(wù)劃分小組。

人員組成

人員還是按照專(zhuān)業(yè)分工的角度去找，按照每個(gè)角色最少2人，防止單點(diǎn)風(fēng)險(xiǎn)的思路，

人員需求如下：

iOS開(kāi)發(fā)：2人
Android開(kāi)發(fā)：2人
H5開(kāi)發(fā)：4人
Node或者Java開(kāi)發(fā)（BFF）：2人

管理

管理方式跟組織結(jié)構(gòu)相適應(yīng)，采用職能管理和敏捷管理相結(jié)合的方式。

職能管理

“大前端”是按照職能分的，跟后端相對(duì)應(yīng)，是技術(shù)部下面的一個(gè)子部門(mén)，按照職能管理方式進(jìn)行統(tǒng)一管理。

敏捷管理

• “大前端”內(nèi)部，主要還是按照業(yè)務(wù)分組的，并且由于BFF的引入，“大前端”內(nèi)部可以形成開(kāi)發(fā)的閉環(huán)，可以考慮引入敏捷管理。

• 要實(shí)行敏捷管理，需要產(chǎn)品和測(cè)試的支持。根據(jù)業(yè)務(wù)，將相關(guān)的產(chǎn)品、設(shè)計(jì)、測(cè)試、開(kāi)發(fā)（“大前端”）組成虛擬團(tuán)隊(duì)。

流程

和管理模式相對(duì)應(yīng)，采用瀑布模型和敏捷模型相結(jié)合的方式。

瀑布模型

職能型組織，采用瀑布模型的開(kāi)發(fā)流程是合適的。產(chǎn)品部，技術(shù)部，測(cè)試部一般跟產(chǎn)品開(kāi)發(fā)相關(guān)度比較大，按照瀑布模型聯(lián)系起來(lái)。這里考慮前后端分離的開(kāi)發(fā)模式，“大前端”可以獨(dú)立完成開(kāi)發(fā)閉環(huán)，雖然BFF層的數(shù)據(jù)是Mock的。
另外，大前端版本的開(kāi)發(fā)要求領(lǐng)先后端一個(gè)版本以上，這樣也方便對(duì)于后端服務(wù)的測(cè)試。簡(jiǎn)單講，就是將通常的“后端功能推動(dòng)型”改為“大前端產(chǎn)品拉動(dòng)型”

• 產(chǎn)品PRD -》交互/UI設(shè)計(jì) -》大前端開(kāi)發(fā) -》大前端測(cè)試 -》大前端內(nèi)部發(fā)布

• 后端服務(wù)開(kāi)發(fā) -》后端測(cè)試 -》對(duì)接大前端合適版本（主要是BFF的工作，Mock數(shù)據(jù)改為從后端服務(wù)取數(shù)據(jù)） -》預(yù)發(fā)環(huán)境驗(yàn)證 -》產(chǎn)品上線(xiàn)

敏捷模型

產(chǎn)品，測(cè)試，大前端可以考慮合作，按照敏捷模型進(jìn)行開(kāi)發(fā)。目的是打破部門(mén)墻，加強(qiáng)溝通；以業(yè)務(wù)開(kāi)發(fā)為共同目標(biāo)，形成合力。

• 開(kāi)發(fā)周期為4周，按照1周預(yù)研、2周開(kāi)發(fā)測(cè)試、1周重構(gòu)的比例進(jìn)行分配。

• 1周預(yù)研：這周的主要任務(wù)是產(chǎn)品、測(cè)試、開(kāi)發(fā)進(jìn)行充分溝通，對(duì)這一期的業(yè)務(wù)目標(biāo)達(dá)成共識(shí)。
  產(chǎn)品的主要工作是講解需求、原型、設(shè)計(jì)，進(jìn)行場(chǎng)景化的描述，定出優(yōu)先級(jí)，確保團(tuán)隊(duì)成員對(duì)本期業(yè)務(wù)有正確的理解。
  測(cè)試的主要工作是進(jìn)行測(cè)試用例編寫(xiě)，用例評(píng)審，最終通過(guò)相應(yīng)工具，將測(cè)試用例數(shù)據(jù)在BFF層形成可執(zhí)行的Mock數(shù)據(jù)。
  開(kāi)發(fā)的主要工作是根據(jù)業(yè)務(wù)需求進(jìn)行技術(shù)預(yù)研，技術(shù)選型，技術(shù)設(shè)計(jì)，任務(wù)劃分，工作評(píng)估等等。完成“計(jì)劃會(huì)議”所要求的內(nèi)容，將開(kāi)發(fā)任務(wù)分配到人。

• 2周開(kāi)發(fā)：按照敏捷的模式進(jìn)行開(kāi)發(fā)，將業(yè)務(wù)落地。“每日站會(huì)”要堅(jiān)持開(kāi)，及時(shí)溝通。開(kāi)發(fā)每完成一項(xiàng)，測(cè)試就可以直接驗(yàn)證，注重效率。Mock數(shù)據(jù)由測(cè)試統(tǒng)一負(fù)責(zé)，開(kāi)發(fā)測(cè)試用同一套數(shù)據(jù)，減少誤會(huì)。這期的結(jié)束標(biāo)志是2周之后的“評(píng)審會(huì)議”，開(kāi)發(fā)測(cè)試向產(chǎn)品演示完成的業(yè)務(wù)場(chǎng)景。

• 1周重構(gòu)：這周對(duì)應(yīng)的是敏捷開(kāi)發(fā)里面的“回顧會(huì)議”，也是產(chǎn)品、測(cè)試、開(kāi)發(fā)進(jìn)行充分溝通的一周。產(chǎn)品在公司內(nèi)部試運(yùn)行一周，進(jìn)行驗(yàn)收，收集反饋，為下一期的產(chǎn)品設(shè)計(jì)提供數(shù)據(jù)支持。開(kāi)發(fā)一方面可以修改bug，更重要的是根據(jù)“回顧會(huì)議”的內(nèi)容，進(jìn)行流程改進(jìn)，對(duì)“技術(shù)債”及時(shí)進(jìn)行重構(gòu)。也可以進(jìn)行組件開(kāi)發(fā)，提高今后代碼的復(fù)用度。

特殊之處

Mock數(shù)據(jù)

• 以前的Mock數(shù)據(jù)由開(kāi)發(fā)自己負(fù)責(zé)，要么直接代碼寫(xiě)死，要么借助Charles等工具?，F(xiàn)在，將Mock數(shù)據(jù)由測(cè)試統(tǒng)一負(fù)責(zé)，直接生成在BFF層。

• 以前開(kāi)發(fā)要寫(xiě)自測(cè)代碼，單元測(cè)試代碼；測(cè)試設(shè)計(jì)出用例數(shù)據(jù)之后，一般通過(guò)流程工具，比如JIRA，要求開(kāi)發(fā)自測(cè)?，F(xiàn)在的模式是測(cè)試專(zhuān)職維護(hù)BFF上的Mock數(shù)據(jù)，將設(shè)計(jì)的用例轉(zhuǎn)化為實(shí)際可用的Mock數(shù)據(jù)，開(kāi)發(fā)測(cè)試用同一套標(biāo)準(zhǔn)，減少流程和溝通上的損耗。

內(nèi)部版本

• “大前端”開(kāi)發(fā)測(cè)試完成的內(nèi)部版本是半成品，是缺乏后臺(tái)實(shí)際支撐的。內(nèi)部發(fā)版之后，在內(nèi)部的測(cè)試服務(wù)器上試運(yùn)行。（開(kāi)發(fā)版本運(yùn)行在開(kāi)發(fā)服務(wù)器上）。運(yùn)行需要的數(shù)據(jù)由測(cè)試負(fù)責(zé)Mock。

• 這個(gè)內(nèi)部版本不能交給實(shí)際的用戶(hù)使用，但是內(nèi)部的產(chǎn)品，開(kāi)發(fā)，測(cè)試可以使用，用來(lái)體驗(yàn)，查找bug等等。

• 對(duì)于后端開(kāi)發(fā)來(lái)說(shuō)，也很便利，服務(wù)開(kāi)發(fā)好之后，有現(xiàn)成的產(chǎn)品用來(lái)測(cè)試，能省很多事。

• 向老板匯報(bào)，或者向客戶(hù)展示，也很方便，有實(shí)際可用的產(chǎn)品可以體驗(yàn)，雖然數(shù)據(jù)是Mock的。這個(gè)跟看word文檔，ppt，原型設(shè)計(jì)，或者UI圖，感覺(jué)是完全兩樣的。

• 修改成本小，一般來(lái)說(shuō)，70%的工作在后臺(tái)開(kāi)發(fā)，30%的工作在“大前端”頁(yè)面。在內(nèi)部試用的那一周中，發(fā)現(xiàn)的問(wèn)題，或者需求變更，可以非常容易的在下一個(gè)版本迭代完成。這個(gè)時(shí)候，后臺(tái)服務(wù)的開(kāi)發(fā)還沒(méi)開(kāi)始，或者剛剛開(kāi)始，變更成本很小。

需求拉動(dòng)

• 以前，想開(kāi)發(fā)一個(gè)功能，首先考慮的是后端邏輯是怎么樣的。很多時(shí)候，要根據(jù)后端現(xiàn)有的邏輯，修改頁(yè)面的展示，交互的順序等等。是一種“后端功能推動(dòng)的模式”

• 現(xiàn)在，產(chǎn)品和“大前端”一起，領(lǐng)先后端至少一個(gè)迭代以上。遇到需求變更強(qiáng)烈的點(diǎn)，或者爭(zhēng)論較大的點(diǎn)，可以考慮讓內(nèi)部版本運(yùn)行時(shí)間長(zhǎng)一點(diǎn)，比如領(lǐng)先兩三個(gè)版本。等產(chǎn)品想清楚了，基本穩(wěn)定了，后端再上。這樣，產(chǎn)品思考問(wèn)題的重點(diǎn)，就從后端現(xiàn)有的功能轉(zhuǎn)移到客戶(hù)現(xiàn)實(shí)需求上來(lái)。“需求拉動(dòng)型開(kāi)發(fā)模式”，解放了產(chǎn)品的思維，更容易設(shè)計(jì)出符合客戶(hù)期望的產(chǎn)品。

• 原來(lái)的模式是由后端推著前端走，現(xiàn)在的模式是產(chǎn)品和前端拉著后端走，思維模式是完全不一樣的。

• “大前端需求拉動(dòng)型開(kāi)發(fā)模式”：先有個(gè)可用的產(chǎn)品，搞清楚用戶(hù)喜歡什么，再接上后端實(shí)現(xiàn)。

• “后端功能推動(dòng)型開(kāi)發(fā)模式”：先做需求分析，評(píng)估現(xiàn)有后端功能，然后想辦法滿(mǎn)足客戶(hù)需求。

• 問(wèn)題是：“客戶(hù)或者用戶(hù)知道自己想要什么嗎？需求分析能有效嗎？”。相對(duì)來(lái)講，如果有個(gè)可用的東西，真正用起來(lái)了，用戶(hù)更加容易知道自己想要什么。比如“這個(gè)顏色最好改一下”，“這里的按鈕礙眼，最好去掉”，“這里我想看更多的信息，最好能加上”。諸如此類(lèi)

平穩(wěn)的節(jié)奏

• 職能型組織，瀑布式開(kāi)發(fā)模型，有利于控制風(fēng)險(xiǎn)，缺點(diǎn)是時(shí)間過(guò)長(zhǎng)，一般項(xiàng)目至少1個(gè)月以上，面對(duì)需求變更能力較弱。是一種偏重計(jì)劃的模式。

• 敏捷開(kāi)發(fā)模式，有利于團(tuán)隊(duì)溝通，時(shí)間一般較短，一般是2~4周。至于風(fēng)險(xiǎn)，考慮較少，一般是先用了再說(shuō)，發(fā)現(xiàn)問(wèn)題，下個(gè)周期再改。是一種偏重經(jīng)驗(yàn)的模式。

• 將這兩者結(jié)合，是希望達(dá)到風(fēng)險(xiǎn)和速度的平衡，形成平穩(wěn)的節(jié)奏。將敏捷模型中原本只有4小時(shí)的計(jì)劃會(huì)議和回顧會(huì)議擴(kuò)展為一周，是為了讓跨部門(mén)溝通更充分，讓產(chǎn)品驗(yàn)收更全面，降低風(fēng)險(xiǎn)。

• 集中資源做“重要而不緊急的事情”?？蛻?hù)需求很重要，但從想法到落地，并沒(méi)有那么快。所以發(fā)揮“大前端”靈活的優(yōu)勢(shì)，讓客戶(hù)早一點(diǎn)看到想法落地，可以超越客戶(hù)期望。

• “需求變更”本身，也是一種潛在的客戶(hù)需求。在用上實(shí)際可用的產(chǎn)品前，很多時(shí)候，客戶(hù)也不知道自己想要什么。所以，采用兩階段交付的方式，用總開(kāi)發(fā)成本30%左右的“大前端”半成品，挖掘客戶(hù)的潛在需求，可以提高客戶(hù)的滿(mǎn)意度。

• “可用的產(chǎn)品勝過(guò)完備的文檔”，雖然是個(gè)半成品，站在客戶(hù)的角度，比word文檔，原型設(shè)計(jì)等更實(shí)在，更靠譜。

重視重構(gòu)

• 技術(shù)債怎么辦？是立即處理還是等累積到一定程度，再集中處理？

• 讓業(yè)務(wù)停下，專(zhuān)門(mén)做重構(gòu)，這種機(jī)會(huì)只能說(shuō)可遇而不可求。

• 將原來(lái)敏捷中不超過(guò)4小時(shí)的回顧會(huì)議，擴(kuò)展為1個(gè)星期的重構(gòu)階段，正是為了解決技術(shù)債不斷累積的問(wèn)題。達(dá)到“一邊飛行，一邊換引擎”的效果。

• 這個(gè)階段，產(chǎn)品和業(yè)務(wù)也沒(méi)有停，在試用，在體驗(yàn)，在驗(yàn)證一開(kāi)始的設(shè)計(jì)理念是否符合實(shí)際。這樣就促成了產(chǎn)品和技術(shù)的雙贏局面。

重視預(yù)研

• 這里將敏捷開(kāi)發(fā)中原本4小時(shí)的“計(jì)劃會(huì)議”擴(kuò)展為1周。

• 敏捷模型在介紹時(shí)有個(gè)假設(shè)，那就是需求確定，原型設(shè)計(jì)，UI資源，前后端接口設(shè)計(jì)等各種資源都準(zhǔn)備好了，相關(guān)的可行性，也就是預(yù)研都完成了，再開(kāi)“計(jì)劃會(huì)議”

• 實(shí)際情況是，上面提的那些條件往往都沒(méi)準(zhǔn)備好，或者有缺失。開(kāi)發(fā)在進(jìn)行到一半的時(shí)候，經(jīng)常發(fā)現(xiàn)交互邏輯不落地，要改原型?；蛘甙l(fā)現(xiàn)UI資源缺少，接口定義不合理等等。

• 特別是職能型組織，跨部門(mén)溝通，這種信息缺失的事情更容易發(fā)生。

• 在正式開(kāi)發(fā)之前，花1周時(shí)間，集中進(jìn)行溝通，進(jìn)行技術(shù)預(yù)研，做好充分準(zhǔn)備，將問(wèn)題發(fā)現(xiàn)在工程開(kāi)始之前，對(duì)減少不必要的返工是很有意義的。

面向BFF編程

• BFF成了“大前端”和后端之間的抽象接口

• BFF需要做好兩邊的適配

• 可以考慮將一些公共業(yè)務(wù)也接過(guò)來(lái)，實(shí)現(xiàn)“輕客戶(hù)端”的目標(biāo)

• 自然而然的“熱更新”，BFF采用了后端的技術(shù)，做的是“大前端”的工作。有修改，更新服務(wù)，就生效了，天然的熱更新。

• 天生的“跨平臺(tái)”，BFF這一個(gè)地方修改，各種端都能起作用。

• 增加掌控力。BFF由企業(yè)維護(hù)，而各種端掌握在用戶(hù)手里。將業(yè)務(wù)由各種端移到BFF，可以顯著提供企業(yè)的掌控力。
  這里的邊界是：“能服務(wù)端（BFF）實(shí)現(xiàn)的，就不要放到客戶(hù)端去，除非遇到嚴(yán)重的性能問(wèn)題”。

• 注意性能瓶頸，這是關(guān)鍵節(jié)點(diǎn)，是前后端的對(duì)接點(diǎn)。并且還要注意，對(duì)接之后，Mock數(shù)據(jù)要清除干凈，保證生產(chǎn)版本的數(shù)據(jù)是來(lái)自真正的后端。

效率和安全并重

• “大前端”注重效率，快速響應(yīng)用戶(hù)的需求變更。

• 后端注重安全，按照瀑布模型或者迭代模型，注重風(fēng)險(xiǎn)管控。

• 通過(guò)BFF解耦，讓前后端各自獨(dú)立運(yùn)行。

思考

• “大前端”是最近起來(lái)的概念。和傳統(tǒng)的前端相比，“大前端”有兩個(gè)方面的擴(kuò)展。一個(gè)是端的多樣性，比如新增了iOS，Android，小程序，公眾號(hào)等等。另外一個(gè)是往后端擴(kuò)展，比如Node.js的興起，或許寫(xiě)后端服務(wù)沒(méi)有Java成熟，寫(xiě)B(tài)FF還是可以勝任的。

• “大前端”是相對(duì)于傳統(tǒng)的前端，iOS，Android，H5等獨(dú)立小團(tuán)隊(duì)而言的。從基礎(chǔ)服務(wù)+業(yè)務(wù)支持兩個(gè)方面，促進(jìn)團(tuán)隊(duì)的融合。在架構(gòu)，工具鏈，組件化等幾個(gè)方面提高復(fù)用，提升效率。

• “大前端”是隨著前后端分離的趨勢(shì)逐步提出來(lái)的，是相對(duì)于后端來(lái)講的，因此，要達(dá)到和后端既相互獨(dú)立、減少依賴(lài)，又相互合作、溝通清晰的目標(biāo)。

• “大前端”概念最初是從阿里傳出來(lái)的，后來(lái)餓了么發(fā)展最出名，現(xiàn)在很多公司在用，和微服務(wù)一起，接受度也在增加，成為一種趨勢(shì)... ...

• “大前端”在具體落地的時(shí)候，還沒(méi)有固定的模式，各家的方案也不盡相同。有可供參考的成功案例，沒(méi)有可供復(fù)制的成熟模式。需要根據(jù)自身的具體情況，摸索前進(jìn)。