問題
- “一云多端”成為趨勢，終端類型越來越多呛讲。比如，現(xiàn)在PC Web網(wǎng)站的產品已經(jīng)有了返奉，現(xiàn)在想擴展APP圣蝎，小
程序... ...怎么辦？一個直接能想到的方法就是在原來的基礎上衡瓶，為APP等增加API接口徘公，如下圖所示：
這樣做是可以的，然而一旦遇到修改哮针，那么要同時修改幾個端的代碼关面，很麻煩，不是很完美十厢。
-
“前后端分離”成為趨勢等太。一開始的PC Web網(wǎng)站，大多是采用服務端渲染的前后端一體化的模式蛮放。隨著技術的發(fā)展缩抡，前后端分離，前端渲染逐漸成為趨勢包颁。相應地瞻想，前端開發(fā)人員也從后端團隊中獨立出來。
最近興起的APP娩嚼，小程序等蘑险，天生就是前后端分離的。
前端岳悟，APP佃迄，小程序等各自獨立成專門的團隊，當然可以滿足這種趨勢贵少。
相應地服務端需要為每一個前端部門提供服務呵俏，在實踐中常常發(fā)現(xiàn)，重復的內容很多滔灶，有沒有辦法增加復用普碎？或者說后端能否只對接一個“大前端”部門，剩下的“大前端”部門內部自己解決宽气？
image.png 服務端設計的API接口随常，面向通用服務，還是面向UI萄涯？各個端對數(shù)據(jù)的顯示要求不同绪氛，給一個公共的API還是分別給不同的API？
比如涝影，時間顯示枣察，PC端可能要求“2018-6-11”的格式，而APP端可能要求“2018/6/11”的格式燃逻，接口怎么給序目？
再比如，相同功能的一個接口伯襟，PC Web端需要20個字段猿涨，已經(jīng)做好了。現(xiàn)在APP端因為屏幕小姆怪，只要10個字段就夠了叛赚，是復用老的API，讓APP忍受垃圾信息稽揭，還是為APP額外新增一個接口俺附？
前端和服務端人員可能會有不同意見，這就帶來了沖突溪掀。大家都有一定的道理事镣，怎么協(xié)調？產品經(jīng)理提出PRD-》UED設計交互稿-》UI設計界面-》后臺設計API接口-》后臺實現(xiàn)服務-》前后端聯(lián)調... ...
以上是一般的開發(fā)流程揪胃，整個過程還是比較長的璃哟。前端在開發(fā)完靜態(tài)頁面之后，常常需要等后臺服務開發(fā)好了喊递，才能聯(lián)調沮稚，這里往往有等待時間的浪費。等后臺服務好了册舞，往往提測時間也臨近了蕴掏，氣氛很緊張。整個開發(fā)體驗调鲸，往往就是“一半是海水盛杰，一半是火焰”。有沒有辦法縮短這個流程藐石，并且能夠讓前端不依賴后臺服務的完成即供，獨自完成開發(fā)？
架構
從現(xiàn)狀來看于微，前后端分離之后逗嫡，服務端直接給各種端提供服務是很自然能夠想到的一種方式青自。這種方式的優(yōu)點是簡單直接，缺點是不夠靈活驱证。因此延窜，考慮在前端和后端之間插入一個中間層，作為前后端之間的橋梁抹锄，增加靈活性逆瑞。
對于這個中間層的稱呼，一種是“網(wǎng)關層或者接入層”伙单，這個可能會和后臺現(xiàn)有的網(wǎng)關和接入層造成混淆获高。另一種叫法叫做BFF(Backend for Frontends，為前端而存在的后端)吻育，這種稱呼相對比較準確念秧，不會帶來混淆。
- 網(wǎng)關層或者接入層
- BFF(Backend for Frontends布疼，為前端而存在的后端)
解決方法
針對“一云多端”出爹，可以在BFF層做適配《谐可以考慮MVVM的模式严就，從服務器來的數(shù)據(jù)當做Model，在BFF中針對各種端器罐，提供不同的ViewModel梢为。如果數(shù)據(jù)變了，只要修改Model就可以了轰坊。如果要增加一種端铸董，只要增加一個ViewModel就可以了。在這里集中修改肴沫，就可以解放各個終端的格式轉化工作粟害。
“前后端分離”之后，各種端可以融合為一個“大前端”颤芬，跟后端對話的窗口就是BFF悲幅。對于后端來說，只要滿足BFF的數(shù)據(jù)需求就可以了站蝠，剩下的事情汰具，就讓“大前端”內部自己解決。
服務端設計的API接口菱魔，面向通用服務留荔，不需要面向UI。各種端的UI差異澜倦，由BFF層負責適配聚蝶。這樣的話杰妓，可以讓后端更加專注于業(yè)務邏輯和數(shù)據(jù)服務，不需要操心各種端的差異碘勉。
整個開發(fā)流程太長巷挥，導致相互等待，造成浪費恰聘。針對這個問題句各，可以考慮在BFF層將開發(fā)流程分為兩部分吸占∏邕叮“大前端”作為一個獨立開發(fā)部門，領先后端一個版本發(fā)布周期矾屯。
具體做法是兼蕊，對于新業(yè)務，將Mock數(shù)據(jù)生成在BFF層件蚕，對于各種端來說孙技，相當于后端服務已經(jīng)好了，可以直接進行聯(lián)調排作，不需要等待牵啦。這樣就把前端對后端的數(shù)據(jù)依賴去除了，更加靈活妄痪。
組織結構
針對上面提到的“大前端”技術架構哈雏，需要相應的“大前端”組織結構相對應。
分類思路
“大前端”是針對整個后端來說的衫生，所以這一層是按照職能來分的
在“大前端”下面裳瘪，是否仍然按照職能來分呢？比如iOS開發(fā)罪针，Android開發(fā)彭羹，H5開發(fā)等等。這種分法是可行的泪酱，然而收益不是很大派殷。這只是將一個個小部門“組合成”一個相對大的部門，融合度不是很高墓阀。
另外一種融合度更高的劃分方法是在“大前端”下劃分為“基礎服務”愈腾，“業(yè)務開發(fā)”兩個子部門。
“基礎服務”的主要職責是為整個“大前端”部門提供公共服務岂津，公共組件虱黄，周邊設施等等。根據(jù)需要和實際情況可以分為“架構”吮成、“工具”橱乱、“組件”等小組
“業(yè)務開發(fā)”的主要職責完成業(yè)務部門的需求辜梳。根據(jù)業(yè)務發(fā)展情況，按照具體業(yè)務劃分小組泳叠。
人員組成
人員還是按照專業(yè)分工的角度去找作瞄，按照每個角色最少2人，防止單點風險的思路危纫，人員需求如下：
iOS開發(fā)：2人
Android開發(fā)：2人
H5開發(fā)：4人
Node或者Java開發(fā)（BFF）：2人
管理
管理方式跟組織結構相適應宗挥，采用職能管理和敏捷管理相結合的方式。
職能管理
“大前端”是按照職能分的种蝶，跟后端相對應契耿，是技術部下面的一個子部門，按照職能管理方式進行統(tǒng)一管理螃征。
敏捷管理
- “大前端”內部搪桂，主要還是按照業(yè)務分組的，并且由于BFF的引入盯滚，“大前端”內部可以形成開發(fā)的閉環(huán)踢械，可以考慮引入敏捷管理。
- 要實行敏捷管理魄藕，需要產品和測試的支持内列。根據(jù)業(yè)務，將相關的產品背率、設計话瞧、測試、開發(fā)（“大前端”）組成虛擬團隊退渗。
流程
和管理模式相對應移稳，采用瀑布模型和敏捷模型相結合的方式。
瀑布模型
職能型組織会油，采用瀑布模型的開發(fā)流程是合適的个粱。產品部，技術部翻翩，測試部一般跟產品開發(fā)相關度比較大都许，按照瀑布模型聯(lián)系起來。這里考慮前后端分離的開發(fā)模式嫂冻，“大前端”可以獨立完成開發(fā)閉環(huán)胶征，雖然BFF層的數(shù)據(jù)是Mock的。
另外桨仿，大前端版本的開發(fā)要求領先后端一個版本以上睛低，這樣也方便對于后端服務的測試。簡單講，就是將通常的“后端功能推動型”改為“大前端產品拉動型”
產品PRD -》交互/UI設計 -》大前端開發(fā) -》大前端測試 -》大前端內部發(fā)布
后端服務開發(fā) -》后端測試 -》對接大前端合適版本（主要是BFF的工作钱雷，Mock數(shù)據(jù)改為從后端服務取數(shù)據(jù)） -》預發(fā)環(huán)境驗證 -》產品上線
敏捷模型
產品骂铁，測試，大前端可以考慮合作罩抗，按照敏捷模型進行開發(fā)拉庵。目的是打破部門墻，加強溝通套蒂；以業(yè)務開發(fā)為共同目標钞支，形成合力。
開發(fā)周期為4周操刀，按照1周預研烁挟、2周開發(fā)測試、1周重構的比例進行分配馍刮。
1周預研：這周的主要任務是產品信夫、測試窃蹋、開發(fā)進行充分溝通卡啰，對這一期的業(yè)務目標達成共識。
產品的主要工作是講解需求警没、原型匈辱、設計，進行場景化的描述杀迹，定出優(yōu)先級亡脸，確保團隊成員對本期業(yè)務有正確的理解。
測試的主要工作是進行測試用例編寫树酪，用例評審浅碾，最終通過相應工具，將測試用例數(shù)據(jù)在BFF層形成可執(zhí)行的Mock數(shù)據(jù)续语。
開發(fā)的主要工作是根據(jù)業(yè)務需求進行技術預研垂谢，技術選型，技術設計疮茄，任務劃分滥朱，工作評估等等。完成“計劃會議”所要求的內容力试，將開發(fā)任務分配到人徙邻。2周開發(fā)：按照敏捷的模式進行開發(fā)，將業(yè)務落地畸裳＄掷纾“每日站會”要堅持開，及時溝通。開發(fā)每完成一項帅容，測試就可以直接驗證薇芝，注重效率。Mock數(shù)據(jù)由測試統(tǒng)一負責丰嘉，開發(fā)測試用同一套數(shù)據(jù)夯到，減少誤會。這期的結束標志是2周之后的“評審會議”饮亏，開發(fā)測試向產品演示完成的業(yè)務場景耍贾。
1周重構：這周對應的是敏捷開發(fā)里面的“回顧會議”，也是產品路幸、測試荐开、開發(fā)進行充分溝通的一周。產品在公司內部試運行一周简肴，進行驗收晃听，收集反饋，為下一期的產品設計提供數(shù)據(jù)支持砰识。開發(fā)一方面可以修改bug能扒，更重要的是根據(jù)“回顧會議”的內容，進行流程改進辫狼，對“技術債”及時進行重構初斑。也可以進行組件開發(fā)，提高今后代碼的復用度膨处。
特殊之處
Mock數(shù)據(jù)
以前的Mock數(shù)據(jù)由開發(fā)自己負責见秤，要么直接代碼寫死，要么借助Charles等工具≌娲唬現(xiàn)在鹃答，將Mock數(shù)據(jù)由測試統(tǒng)一負責，直接生成在BFF層突硝。
以前開發(fā)要寫自測代碼测摔，單元測試代碼；測試設計出用例數(shù)據(jù)之后狞换，一般通過流程工具避咆，比如JIRA，要求開發(fā)自測⌒拊耄現(xiàn)在的模式是測試專職維護BFF上的Mock數(shù)據(jù)查库，將設計的用例轉化為實際可用的Mock數(shù)據(jù)，開發(fā)測試用同一套標準黄琼，減少流程和溝通上的損耗樊销。
內部版本
“大前端”開發(fā)測試完成的內部版本是半成品整慎，是缺乏后臺實際支撐的。內部發(fā)版之后围苫，在內部的測試服務器上試運行裤园。（開發(fā)版本運行在開發(fā)服務器上）。運行需要的數(shù)據(jù)由測試負責Mock剂府。
這個內部版本不能交給實際的用戶使用拧揽，但是內部的產品，開發(fā)腺占，測試可以使用淤袜，用來體驗，查找bug等等衰伯。
對于后端開發(fā)來說铡羡，也很便利，服務開發(fā)好之后意鲸，有現(xiàn)成的產品用來測試烦周，能省很多事。
向老板匯報怎顾，或者向客戶展示读慎，也很方便，有實際可用的產品可以體驗杆勇，雖然數(shù)據(jù)是Mock的贪壳。這個跟看word文檔饱亿，ppt蚜退，原型設計第租，或者UI圖赋秀，感覺是完全兩樣的。
修改成本小统锤，一般來說配猫，70%的工作在后臺開發(fā)幅恋，30%的工作在“大前端”頁面。在內部試用的那一周中泵肄，發(fā)現(xiàn)的問題捆交，或者需求變更，可以非常容易的在下一個版本迭代完成腐巢。這個時候品追，后臺服務的開發(fā)還沒開始，或者剛剛開始冯丙，變更成本很小肉瓦。
需求拉動
以前，想開發(fā)一個功能，首先考慮的是后端邏輯是怎么樣的泞莉。很多時候哪雕，要根據(jù)后端現(xiàn)有的邏輯，修改頁面的展示鲫趁，交互的順序等等斯嚎。是一種“后端功能推動的模式”
現(xiàn)在，產品和“大前端”一起挨厚，領先后端至少一個迭代以上孝扛。遇到需求變更強烈的點，或者爭論較大的點幽崩，可以考慮讓內部版本運行時間長一點苦始，比如領先兩三個版本。等產品想清楚了慌申，基本穩(wěn)定了陌选，后端再上。這樣蹄溉，產品思考問題的重點咨油，就從后端現(xiàn)有的功能轉移到客戶現(xiàn)實需求上來∑饩簦“需求拉動型開發(fā)模式”役电，解放了產品的思維，更容易設計出符合客戶期望的產品棉胀。
原來的模式是由后端推著前端走法瑟，現(xiàn)在的模式是產品和前端拉著后端走，思維模式是完全不一樣的唁奢。
“大前端需求拉動型開發(fā)模式”：先有個可用的產品霎挟，搞清楚用戶喜歡什么，再接上后端實現(xiàn)麻掸。
“后端功能推動型開發(fā)模式”：先做需求分析酥夭，評估現(xiàn)有后端功能，然后想辦法滿足客戶需求脊奋。
問題是：“客戶或者用戶知道自己想要什么嗎熬北？需求分析能有效嗎？”诚隙。相對來講讶隐，如果有個可用的東西，真正用起來了最楷，用戶更加容易知道自己想要什么整份。比如“這個顏色最好改一下”待错，“這里的按鈕礙眼，最好去掉”烈评，“這里我想看更多的信息火俄，最好能加上”。諸如此類
平穩(wěn)的節(jié)奏
職能型組織讲冠，瀑布式開發(fā)模型瓜客，有利于控制風險，缺點是時間過長竿开，一般項目至少1個月以上谱仪，面對需求變更能力較弱。是一種偏重計劃的模式否彩。
敏捷開發(fā)模式疯攒，有利于團隊溝通，時間一般較短列荔，一般是2~4周敬尺。至于風險，考慮較少贴浙，一般是先用了再說砂吞，發(fā)現(xiàn)問題，下個周期再改崎溃。是一種偏重經(jīng)驗的模式蜻直。
將這兩者結合，是希望達到風險和速度的平衡袁串，形成平穩(wěn)的節(jié)奏概而。將敏捷模型中原本只有4小時的計劃會議和回顧會議擴展為一周，是為了讓跨部門溝通更充分般婆，讓產品驗收更全面到腥，降低風險。
集中資源做“重要而不緊急的事情”蔚袍。客戶需求很重要配名，但從想法到落地啤咽，并沒有那么快。所以發(fā)揮“大前端”靈活的優(yōu)勢渠脉，讓客戶早一點看到想法落地宇整，可以超越客戶期望。
“需求變更”本身芋膘，也是一種潛在的客戶需求鳞青。在用上實際可用的產品前霸饲，很多時候，客戶也不知道自己想要什么臂拓。所以厚脉，采用兩階段交付的方式，用總開發(fā)成本30%左右的“大前端”半成品胶惰，挖掘客戶的潛在需求傻工，可以提高客戶的滿意度。
“可用的產品勝過完備的文檔”孵滞，雖然是個半成品中捆，站在客戶的角度，比word文檔坊饶，原型設計等更實在泄伪，更靠譜。
重視重構
技術債怎么辦匿级？是立即處理還是等累積到一定程度臂容，再集中處理？
讓業(yè)務停下根蟹，專門做重構脓杉，這種機會只能說可遇而不可求。
將原來敏捷中不超過4小時的回顧會議简逮，擴展為1個星期的重構階段球散，正是為了解決技術債不斷累積的問題。達到“一邊飛行散庶，一邊換引擎”的效果蕉堰。
這個階段，產品和業(yè)務也沒有停悲龟，在試用屋讶，在體驗，在驗證一開始的設計理念是否符合實際须教。這樣就促成了產品和技術的雙贏局面皿渗。
重視預研
這里將敏捷開發(fā)中原本4小時的“計劃會議”擴展為1周。
敏捷模型在介紹時有個假設轻腺，那就是需求確定乐疆，原型設計，UI資源贬养，前后端接口設計等各種資源都準備好了挤土，相關的可行性，也就是預研都完成了误算，再開“計劃會議”
實際情況是仰美，上面提的那些條件往往都沒準備好迷殿，或者有缺失。開發(fā)在進行到一半的時候咖杂，經(jīng)常發(fā)現(xiàn)交互邏輯不落地庆寺，要改原型『采唬或者發(fā)現(xiàn)UI資源缺少止邮，接口定義不合理等等。
特別是職能型組織奏窑，跨部門溝通导披，這種信息缺失的事情更容易發(fā)生。
在正式開發(fā)之前埃唯，花1周時間撩匕，集中進行溝通，進行技術預研墨叛，做好充分準備止毕，將問題發(fā)現(xiàn)在工程開始之前，對減少不必要的返工是很有意義的漠趁。
面向BFF編程
BFF成了“大前端”和后端之間的抽象接口
BFF需要做好兩邊的適配
可以考慮將一些公共業(yè)務也接過來扁凛，實現(xiàn)“輕客戶端”的目標
自然而然的“熱更新”，BFF采用了后端的技術闯传，做的是“大前端”的工作谨朝。有修改，更新服務甥绿，就生效了字币，天然的熱更新。
天生的“跨平臺”共缕，BFF這一個地方修改洗出，各種端都能起作用。
增加掌控力图谷。BFF由企業(yè)維護翩活，而各種端掌握在用戶手里。將業(yè)務由各種端移到BFF蜓萄，可以顯著提供企業(yè)的掌控力隅茎。
這里的邊界是：“能服務端（BFF）實現(xiàn)的，就不要放到客戶端去嫉沽，除非遇到嚴重的性能問題”。注意性能瓶頸俏竞，這是關鍵節(jié)點绸硕，是前后端的對接點堂竟。并且還要注意，對接之后玻佩，Mock數(shù)據(jù)要清除干凈出嘹，保證生產版本的數(shù)據(jù)是來自真正的后端。
效率和安全并重
“大前端”注重效率咬崔，快速響應用戶的需求變更税稼。
后端注重安全，按照瀑布模型或者迭代模型垮斯，注重風險管控郎仆。
通過BFF解耦，讓前后端各自獨立運行兜蠕。
思考
“大前端”是最近起來的概念扰肌。和傳統(tǒng)的前端相比，“大前端”有兩個方面的擴展熊杨。一個是端的多樣性曙旭，比如新增了iOS，Android晶府，小程序桂躏，公眾號等等。另外一個是往后端擴展川陆，比如Node.js的興起剂习，或許寫后端服務沒有Java成熟，寫B(tài)FF還是可以勝任的书劝。
“大前端”是相對于傳統(tǒng)的前端进倍，iOS，Android购对，H5等獨立小團隊而言的猾昆。從基礎服務+業(yè)務支持兩個方面，促進團隊的融合骡苞。在架構垂蜗，工具鏈，組件化等幾個方面提高復用解幽，提升效率贴见。
“大前端”是隨著前后端分離的趨勢逐步提出來的，是相對于后端來講的躲株，因此片部，要達到和后端既相互獨立、減少依賴霜定，又相互合作档悠、溝通清晰的目標廊鸥。
“大前端”概念最初是從阿里傳出來的，后來餓了么發(fā)展最出名辖所，現(xiàn)在很多公司在用惰说，和微服務一起，接受度也在增加缘回，成為一種趨勢... ...
“大前端”在具體落地的時候吆视，還沒有固定的模式，各家的方案也不盡相同酥宴。有可供參考的成功案例啦吧，沒有可供復制的成熟模式。需要根據(jù)自身的具體情況幅虑，摸索前進丰滑。
參考文章
微服務下使用GraphQL構建BFF
前后端分離演進：不能微服務，那就使用 BFF 隔離
一個可供創(chuàng)業(yè)公司參考的移動APP服務端架構演進方案
螞蟻財富的BFF實踐
了解BFF架構
大前端技術大會
當我們在談大前端的時候倒庵，我們談的是什么
如何落地和管理一個“大前端”團隊?餓了么大前端團隊解密
我理解中的“大前端”/“大無線”
漫極客 CTO 李焱：大前端之路 - 如何用Web技術一統(tǒng)三端（Web褒墨、Desktop、Mobile）開發(fā)
