【本文系ITA1024原創首發，轉載或節選內容前需獲授權（授權后一周以后可以轉載），并在文章開篇注明：本文轉載自ITA1024前端技術專題月分享實錄，微信公眾號ita1024k】

2016年3月19日，由互聯網技術聯盟（ITA）舉辦的1024前端技術峰會，在中關村WEPAC盛大舉辦！

400+位經驗豐富的前端工程師共同參與，是一場業內最頂級講師陣容的前端技術峰會，而且，這是一場不落幕的峰會，因為3月開始的每一周，都有線上的分會場如期分享著各個一線互聯網公司在前端技術方面的最佳實踐。

58同城資深前端架構師劉浩源分享話題：前后端分離開發模式實踐。

如下是1024前端技術峰會上，劉浩源的分享實錄。

大家好！我是劉浩源，在58同城做了將近五年的FE，現在在技術委員會負責FE技術支線。

我 今天分享的主題是前后端分離開發模式。這個概念是三四年前出現，可能大公司出現的會更早一些，就是所謂大前端的開發模式。現在有不少公司已經在做，特別是 大型公司已經在做了。58——當時在我來58，是在2012年——那邊開發模式還不是大型公司的開發模式，所以我們一直在推進這個事，去年有一些成果，接 下來的時間，我會把技術相關東西摘出來，給大家介紹一下這個事情怎么推進的。

大家看一下流程圖——模版開發現狀——大部分FE工作狀態就是這樣。

首 先FE是一條工作線，那邊RD是另外一條；一開始交給UI做設計圖出來，然后是FE人進入，同時RD做數據庫設計和代碼；等到RD需要做模塊的時候會把 FE的開發結果，HTML拿過去，做頁面組裝；組裝好之后那邊跟自己的后端進行聯調，這個過程當中會出現很多問題，因為HTML是我們做的，FE做的不太 關注頁面邏輯什么樣，數據什么樣，我們不會關注到實際數據庫里到底是5位還是6位，還是更多。這時聯調就有很多BUG，就從RD聯調又回來，找到FE幫他 們調HTML，甚至于如果我們隨便調又會跟UI出的結果還不太一樣，還得往上倒騰讓UI重新給出設計等等。等RD自測聯調完了，提測，所有輸出的結果有問 題都會找到FE幫助處理這些問題，甚至對測試人員來說是如何確認RD失誤還是FE失誤，測試很難做到。測試完了發現作為FE，我們上線的時候，我們不會上 模版，我們FE上線上JS、CSS，要等到等模版上線之后服務端重啟完成才能上，提前上就可能引起舊代碼出現問題。

整個開發過程中FE雖然是一條工作線，但是這條工作線絕大部分工作是附屬到RD工作線上，并不是真正獨立的開發人員。這樣的開發現狀就是有一些地方是大家都不爽的，并不只是FE覺得不爽的。

首 先第一點人員項目多，周期長，成本大。哪怕頁面上很簡單文案的修改，都不會涉及到數據結構，邏輯結構的東西，都得UI出圖，FE切圖，之后給RD，RD給 完整開發流程，FE這邊相對開發流程會比RD簡單很多，快捷性好很多。但是即使是一個文字的修改，現在也必須RD來，由原本FE+測試就搞定的項目，還一 定要RD也進來，還把RD相關所有的管理流程都加進來才能完成。這樣的話，特別是產品和運營相關的人員就覺得非常不可理解了。

第 二點專業性錯配，成就感歸零。FE是專業的，我做HTML是專業的，但是我工作結果并不是由我最終放在線上，對于RD來說，他們可能對HTML并不算專 業，只是附屬技能，好的一點可能對HTML了解，做的好模版結構，了解模版里的標簽涵義；但是大部分RD都不在乎這個東西。對于RD來說就是模版上改一個 文字要耗費開發測試上線流程走一遍，對他來說也是沒有任何成就感的，他很不愿意的。

第三點FE的項目歸屬感 過低。我們經常出現一個什么問題？就是兩周前或者三周前把一個運營的頁面切完了，RD在排期中，等他們兩三周后開始拿這個頁面套模塊時出問題了，甚至更惡 劣一點產品跟RD說要改什么，改完之后不通知FE，上線前四五個小時說這地兒不對，幫我改一下，FE兩三周前做的東西，中間有變化我們不知道，拿過來直接 蒙了，沒法做。因為對于RD來說在剛才那個流程圖里，RD是核心流程，管控項目的絕對進度，對產品來說就會催著RD，跟RD說有沒有時間，有沒有開始做， 是不是有問題，但是他不會跟FE說這個事，FE是被邊緣化的，我們很難說管控一些事情。

最后一點前面這些東 西結果就是FE在團隊里，特別是小公司，在一個公司切三年頁面，換一家公司再切三年頁面，我們不會了解這個頁面上這個區域放的是什么，這個價格和某一個產 品幾種價格，這互相之間的關系是什么。產品也不會告訴你，他只是告訴UI告訴你我放三個價格，交給FE切，切了給RD，RD清楚某個產品會有6個價格，但 是有可能會有復雜的地方，比方說進價是一個，賣價是一個，產品業務員可能又會很多個價格，但對FE來說不了解這些，我們對業務流程合理不合理沒有發言權 的。

整個結果是這樣的，那怎么辦呢？——前后端重新分工。

現 在的這樣分工，背景是什么？我剛到58的時候，前端工作組里邊大概20個人，只有三個做FE的，剩下全部是java，我去了這個部門也是一段時間之后，發 現這個所謂前端跟服務的區分，是RD內的前端，前端工作就是做數據組裝，后端就是提供數據服務，搜索服務，提供數據庫的服務，這是后端。而它的前端是RD 前端。我進去之后FE人員非常少，對于這樣的業務工程流程勉強可以認可的，FE人員不足，當時那批RD人員相對素質高一點，因為一直在做這些事，所以他們 的HTML和業務流程都比較熟。

但是現在58趕集集團已經大不一樣了，現在RD人員是幾百的概念，三四百了，現在業 務線好幾條，前端業務組已經不是一個了，按產品線分5個大業務線，里面還有各種各樣的分支業務，FE人員也大不一樣，FE光是我們這邊UBU事業部已經 70個人。在這個階段下，剛才那個業務工作流程就完全沒有什么合理性了，14年底我們對這個問題重新進行了考量，最后決定——重新分工。

我 們把傳統三層結構View層拿過來，再好好的觀察一下，對于FE來說，FE本身也可以分這三層，但是這里列得更多是后端，因為我們部門是從后端部門派生出 來的。RD負責Controller，Model是專門的數據服務，FE對HTML的控制是很弱的，所以我們想把View接過來。

這 是經過實際調研之后改進出來的一個新的工作流程，再往前是產品，產品在這步會分兩邊傳達需求，這邊給UI做圖片設計，給到FE之后，靜態開發之前需要跟 RD進行數據格式約定。FE現在不僅要知道頁面的區域放一個價格，還要知道這個價格哪來的。這個數據格式的設計會出現一個問題，就是怎么約定才能讓雙方認 可？

我們后邊會講，數據格式完了之后FE做靜態開發，樣子渲染出來，之后模塊開發又要涉及到環境搭建，這是這邊的工 作路線。那邊RD數據設計之后有自己的代碼結構設計，業務邏輯開發。兩邊工作之后進行數據聯調，FE做自己的模塊提測，debug和上線，然后RD做他們 的測試和上線。

FE和RD只有兩個地方是必須一起工作的，一個是數據格式約定，另外一個是聯調，但是這是一個比較大 的或者比較常規的日常需求才需要的工作路徑。而如果是一個偏向于運營的項目的話，這個工作路徑可能所有RD相關的東西就被過濾掉了，我們就是靜態頁面，不 需要RD幫我們上線，我們文案修改，圖片修改，路徑修改，版本變更不需要RD，FE直接走我們這邊就可以了。

調研之后，我們討論了一下，包括跟RD人員進行討論，最后決定試一下，這個事情在58也是一個比較大的業務開發模式的變化。

這 樣做有什么好處呢？RD和FE專業性都可以了，RD就負責把后面數據服務提供的數據拼裝成需要的內容就行了，FE把HTML模塊拿過來，我們負責HTML 格式。個人成就感上升，對于FE需要新掌握一門技能，而且需要我們掌控到到一部分服務器端的知識，RD就更多會把他們的注意力和溝通內容放到數據結構拼裝 上面。現在FE項目參與度真的提高了，現在所有的產品或者運營做一個項目的時候不會先找RD，而是先找FE。個人發展就有了新的可能，對于RD來說，每天 應付產品和運營的文字性工作肯定是不愿意的，對FE來說，現在真正開始做一個程序員了，這樣才有自己提升的空間。

我們跟RD那邊相關人員溝通之后就要推進這個事，第一個難點就是RD改開發模式。

舊的開發模式是這樣，因為我們是java框架，后端有純后端的代碼，這些代碼會訪問后端的數據庫服務，訪問緩存的東西，訪問完之后通過這邊代碼把數據結構拼 裝出來，放到context里，這是java的關鍵詞（其他的php或者。Net也有類似東西），從程序到模版這段要推送數據過來到模版。

模 版再對數據對象進行渲染，同時調用傳過來的工具方法，它還可以做一些其它的事情。但是這個開發模式肯定是有問題的，第一雖然context有數據內容傳過 來，但是并不太關注數據模型，根據頁面迭代部署新的頁面。當一個小型項目，比如一個一次性或者很短時間要做完的項目沒有長時間維護需求的項目這樣可能還 好，但是像58一個列表頁維護了四五年，RD換了好幾撥，模版改了好幾版，會發現一個問題——后做的人不知道前面的人有沒有把對象推送到頁面上，為了快速 進行功能迭代就會重新把對象推送一下，數據結構就會越來越混亂，模塊這曾代碼結構會越來越雜亂。我們FE幫他們整理過模版，幾乎30%都是無用的。

那 怎么辦呢？這時FE對RD開發有規范要求，要求你這樣做，logic這點我們FE不關注，但context給我們的第一要有完整的數據結構樹，不再是根據 產品今天提一個需求，明天提一個需求，可以隨便變，隨便放到這上面，需要根據頁面的功能提供什么內容，規則格式化的結構樹出來，而且這個結構樹如果我們通 過URL訪問傳特定參數，就可以不通過模塊渲染呈現HTML頁面，還可以直接渲染出一個JSON數據結構，可以直觀的看到拼裝的數據是不是正確。

第 二，在實際應用當中發現可能還是有一些特殊的方法還是需要RD幫我們封裝，但是這個封裝不太希望用對象的方法，最常見的，字符串的處理方法，不太希望直接 調用字符串類型的方法，更多希望是一個單獨的過程方法。這樣做之后FE和RD通過數據結構樹就可以完成了解到數據結構是什么樣的，有沒有重復，有沒有變化 是一目了然，而且現在很明確跟RD區分出功能，模版上面只負責數據顯示和只會有數據顯示相關的代碼、相關的判斷，不能再給我頁面上寫調用一個對象方法，再 調后端的服務拿數據回來，這是不允許的，一定要拼裝好一個完整的context數據結構過來給我好做渲染。

這個為什 么是難點？這種開發模式對RD來說工作量非常大的，它要完整把后端代碼整理一遍，而之前開發模式RD是不太需要關注context里面已經有的，只需要關 注當前需求過來，我需要取什么數據，模塊需要顯示什么數據，只要這兩邊能對上就可以了，不會關注有沒有重復獲取，有沒有效率問題。之前很多RD不會關注這 個，現在他們是一定要保證數據結構的合理性，如果發現別人已經訪問過某個服務，你不能再做重復訪問，這樣他們做這個事一開始很痛苦，但這個事只要做完一遍 他們就非常輕松了，而我們接下來的事情剛剛開始。

難點二、FE開發模版。

第 一就是模版新的知識，對于FE來說這些模版的語法本身是全新的知識，可能會有愿意學習的同學會做這方面的學習，但是對大部分FE來說模版語法是全新的知 識，需要重新學習。我當年學的時候是我一個前輩給我一個3頁的WORD文檔，但是因為我是后端出身，對我還是可以理解的。但是對FE，特別沒有接觸過很多 后端知識的FE來說，還是需要一點時間來學習的，花點精力才能進入狀態的。

第二點才是真正阻礙FE進入模版 的工作，就是開發環境的搭建。我不知道別的公司，大家用PHP很好，現在全智能化很好，但是在58的java環境搭建，對于FE來說我工作的時候如果要搭 建一個java開發環境，做了模版解析，我的機器上面就會跑不動。因為我一般情況下會開一個ps切頁面的工具，再開一個eclipse、再開一個HTML 的編輯器，一般的工作的電腦就肯定扛不住了。

此外，對58來說大部分的數據存儲都不是簡單的數據庫，而是后端大量的 服務，配置環境就非常非常復雜。對于58成熟的RD來說，招的java開發人員大概需要兩到三天進行環境部署，而且很多情況下java環境下現在對模版開 發并不算太友好。當時為了推行我們這個想法，開發環境搭建花了很多時間，想了很多辦法，最后怎么辦呢？我們發現一個好東西node.js，當時找到了淘寶 開源的項目Velocityjs，我們搭建了本地的開發環境，主要做什么事呢？

第一點最基礎可以模擬數據環境，把 RD給我們實現的數據結構和方法可以拿node.js重新實現一遍，這樣子在開發過程當中可以不做數據聯調，只需要按照一開始跟RD規定好的數據結構就可 以做我們的模版開發。此外，我們還通過某個參數變化可以把RD輸出的HTML變成純JSON數據結構的輸出，我們就可以拿node.js直接連那個頁面， 這時候就可以做到使用線上數據的開發，看模版是不是正常的。我也挺推薦這個東西的，我知道有一些公司沒有辦法就跟淘寶一樣寫自己的node下的模塊解析， 需要注意一點，各種各樣的模版規則是脫離語言的，極端情況下可以在java實現一個模版開發模式，也可以在PHP下模版解析，我們能夠找到開源就用開源， 開源找不到自己寫一套，這是有點難度的。

最后一個難點，對于FE來說是測試。

有 的公司好一點會提供比對工具，管理工具，只要保證能順利放到線上去就可以了。我們很少直接跟測試人員做溝通。但是現在需要深入介入到測試流程，需要有單元 測試，保證最后代碼開發出來之后，測試那邊bug率比較低。但我們之前模版開發是交給RD的，我們不太關心這個，我們更多幫助RD改bug。我們做推進項 目的時候，這個地方也是遇到了一些坑，主要是人員素質方面，FE之前很少有這樣的機會跟測試人員一步一步跟進測試，甚至有人測試工具看不懂，或者跟測試人 員要描述清情況，這個測試環境的情況，怎么去部署都描述不清楚。

這是一個解耦前后的效果。

我 們去年花了大半年在M站嘗試進行了開發模式的推進，開發效率整體提升了30%，整個排期開始一看就很明顯，大的項目提升40%。M房產業務線解耦前改一次 版花24個工作日，14年之前的一次改版，之后解耦后新工作方式13.5工作日，整個效率提升43.75%，幾乎是腰斬。小項目，M招聘紅包，開發效率提 升30%。日常運營和產品維護就不再需要RD介入了，所有跟數據結構，數據變化不相關的需求就不要RD了，沒他們事——RD其實也很高興，58的RD有很 多人都有個人理想，技術理想，他們也不想整天在HTML浪費自己的時間，現在他們絕大部分不用他們幫助了，FE全都做了。實際上FE上線跟RD上線，從時 間效率上講，FE還是要占優勢的，這是毋庸置疑的。

我們把這個項目做的過程當中和做完之后還發現了一些附加的效果。

首 先方案選擇更加合理，以前如果有一個運營項目RD實在排不開，我們要給FE做，產品運營說FE把這事全部搞定行不行，現在純的HTML頁面要實現一些純運 營商的需求應該是沒有任何問題的，這點是肯定的。但是之前因為RD時間沒有辦法保證，所以我們做的時候只能通過JS跟API服務器進行數據交互，這樣頁面 要發很多需求，有一些特殊的功能沒有辦法實現的，比如seo，只能靜態處理。現在不一樣了，現在模版在我們手里，數據只要是之前有的我就可以用，seo數 據想要什么用我就可以直接改，跟著類詳情頁運營頁seo信息可以跟當前產品的分類、地域有很高的相關性。

第二點可以在模塊上按需執行。早先的時候如果純粹FE做的話，這些東西所有狀態值這邊都需要考慮到，即使是通過前面判斷完全不會存在的dom，這邊模版也需要隱藏存在。現在就不需要了，我已經能知道這個模塊上會顯示哪些，輸出的時候就可以按需執行了。

第 三種各種優化不求人。我的jS和CSS要做升級，CSS結構和jS結構要升級必須找RD，一些圖片一但通過了cdn服務器，很難保證所有用戶看到最新圖 片，如果模版在我這邊，我就能保證這些。另外RD維護的HTML中寫的一些代碼是很不專業的，比如說簡單的標簽閉合，空白字符的處理，甚至能找到一些大部 分編輯器看不著的字符，RD一查兩三天查不出來，但是現在是我們自己負責，處理這些問題我們也不用等RD的排期。

最 后一點，為更完整模塊化開發做準備。之前，FE雖然會負責輸出HTML，但是一旦上線管的模塊就只包含JS和CSS，HTML上線之后跟我開發內容不一樣 了，里面加一些判斷，循環之后，DOM結構跟我們一開始做的不太一樣了，所以很難把這三塊真正做到一起處理，現在可以了，我說一個模塊，包含的DOM結構 是這樣的，包含的JS和CSS是那樣子的。

回過頭再看一下解耦之后新的工作流程。解耦這個事是不是就完成了，差不多年前年后推差的不多了，那是不是就徹底完成了？其實我們公司推的這個開發流程僅僅是開始。

FE還可以負責哪些事情？

首先，路由還是在RD手里，現在改變一個、新增一個路由配置還是要RD，還是要java上去解析的。

其次，邏輯層返回的數據是一個整體，數據結構樹對雙方是進步，但是這個結構樹是整體，假設還是一個商品詳情頁，除了當前商品信息具體內容之外，可能還會有推薦信息、關聯信息、廣告位等等，我們如果想在某一個運營的情況下，只讀取商品信息的具體內容，我還是得找RD幫忙。

第三點公共的工具類也還依賴RD，還是模塊。

第四個最核心的這個項目還是java項目，只要是java項目就很難說更深入做一些想做的開發和架構調整的事情。

怎么辦？我們目前的工作設想——一個理想的大前端開發模式。

我 知道在淘寶、美團，其它的一些友商已經有一些項目在這么做了，而且在現階段的開發里面，用這種方式還可能有特殊的收益。先說這個開發模式是什么樣的，就是 希望FE能夠用node/php服務器搭建一個中間層，這里四個功能，第一點是路由，希望有FE能控制的路由配置器或者使用路由配置功能，這樣可以控制一 些東西，比如說摩托車和自行車是共同的模版，當要把這兩個模版拆開的時候就可以把這兩個路由到不同的模版解析。

第二 是參數解析，現在這個東西完全是java做的，我們還是希望FE能夠介入到這個參數解析上面去，當然這個參數處理有可能是全自動化的。接下來是數據請求與 拼裝，現在有一些公司在推服務端的異步化，服務端開發絕大部分是同步的，比如說這個頁面對后端服務器發8個請求，它是按順序一個個發的，不是同時發起的， 時間長度是疊加的。

但是現在有一些公司在推異步，按照需求先發四個，根據回來的情況，再發后面的，這樣節省很大的時 間等待。但是我希望這種事情最后也是由FE做，數據請求也是FE來做的。最后模版渲染，不管是哪種模版渲染效益都不算高，我們還是希望FE能夠有權限管理 HTML的渲染，能選擇一種比較高的方式渲染，不管是node.js還是其它的方式，我們希望FE有自己權限做這樣的事。

這 樣做（搭建中間層）還有一個好處，如果我們把中間層抹掉換APP，發現這個結構完全可以用的。這個中間層跟我們手機端APP是同樣的一層，后端服務是可以 共用的，對一個大型公司來說這樣做現在可能有風險，（對于小公司來說）如果為M端、PC端搭建這樣的服務器，IOS、安卓開發的時候，后端服務器就可以共 同用的。而傳統的RD的工作，后退在這個下面，做復雜的業務服務，一些頁面可能很復雜，比如一個發布頁信息提交過來之后要保存，保存之前會有大量的校驗等 等的，這些服務是RD需要做的事情。而對于RD來說，這樣難度，這樣復雜程度工作才會是有意義的工作。

一個完整的模塊結構。

因 為我做FE，專業FE到現在也沒多少年，以前做java。我對模塊化的概念很重視，很想在FE這邊能有比較完整的模塊化結構，那么我們真正FE前端模塊應 該是什么樣子的？當我把前面的事情都能夠做完的話，模塊化會發現一個新東西就是大前端下的模塊組成應該是什么樣的——一個完整前端模塊包括數據接口配置、 模版（HTML）、js、css，不管你通過什么方式，任何HTML模塊真的要跟業務邏輯綁在一起是應該包含數據接口配置，我這個模塊要做什么內容。

模 版的HTML，就是DOM結構是什么樣、js和css有一部分實現數據接口和顯示，有一部分實現DOM層變化，這樣才是比較完整的前端模塊，才能在大型公 司里面，比如房產某一個頁面寫了模塊，要在另外一個頁面分享模塊，就必須把所有東西做模塊告訴那邊，那邊才能夠直接用這個東西，否則只拿出來結構就有問 題。

這是更超前的想法，大型的模塊配置，我希望的是由路由規則，當發現一個請求符合路由規則的時候，后面模 塊是樹狀模塊結構，最后的結果這個請求幾乎是半自動化全部做完，RD和FE，RD那邊只需要做復雜業務重新實現，如果沒有的話就現有的這些。通過解析模塊 之后把模版拼裝出來。js和css也是，解析模塊就可以把js和css單獨拿出來再拼裝好去用。

謝謝大家！

————Q&A————

提問：FE和RD之間是有交互的，以模塊方式交互空間，把數據隔開，數據肯定就需要有解析的過程，現在交互量上去的話可能會是一個瓶頸，遇到這個問題，這個場景對所有模塊的場景是通用還是適用哪些？

劉 浩源：數據量壓力大小的問題，58訪問量真的很大的，數據的緩存層不是我們負責，服務端直接根據查詢條件或者ID就把之前放的緩存數據拿下來。前端搭建的 服務器的是不需要重新做保存的，只是數據層保存。其它的數據交互量其實沒有多大。在我們這邊主要是指的詳情頁、列表頁。

我講這個是開發模 式，整個過程中沒有太多涉及到瀏覽器，是服務端的東西。Angular更多是交互層的東西，你要做游戲，或者富交互的應用可以用，但是我這個是開發模式變 了。根據不同的路由規則，一個FE小組要負責80-120個模版，不同的分類，加上不同參數城市匹配過來到不同的模版，最后需要的模塊希望 是能夠更復雜，東西更多的模塊，這樣才能更滿足需求。

提問：公司內部對于這種問題，前端也是需要版本的控制，這個怎么突破的？

劉 浩源：解耦之后FE要把自己視為真正的RD，就要開始適應做純粹的程序員，要適應一些新的工作的規則。剛才說的這個開發模式有另外一個附帶的好處，這個是 有爭議的，在大部分情況下，用這個開發模式開發的內容可以分開上線的，RD和FE可以分開上線的，RD可以是舊的數據結構。全部轉成新的模式之后，我FE 要上模版了，如果產品這邊覺得有一個短時間不匹配就接受，那我可以直接上，如果產品不認可這種不匹配，我們也可以加一些判斷，判斷一下數據結構有沒有新的 對象，有的話我就加上去新的HTML結構。當然，版本控制也是需要的，FE是需要重新學習的，要真正把自己看成是程序員。

提問：您現在開發模式里面前后短聯調之后，前端跟后端單獨提測，前端是模版提測，這是什么意思？

劉浩源：開發環境調好的模塊部署到測試環境。

提問：這不是還是相當于得有后臺數據填充到模塊里，這不是跟之前開發模式是一樣的，發布上去之后，相當于模塊跟RD提供的數據在一起。

劉浩源：極端情況下雙方提測可以分離的。

提問：我理解您的提測應該還是在一條線，而不是單獨提測，您意思是測試在前后端聯調之后，只提測前端，只提測后端，兩者是分開。

劉 浩源：兩個原因，首先RD提測不是必須的，這個需求如果沒有涉及到數據結構的變化，我是不需要RD提測的，可以改。另外一個極端情況下RD如果時間安排或 者工期趕不上，這邊模版可以先上。這樣有個好處不會因為RD上線，因為java服務器上線相對要復雜一點，不會因為等他那邊東西上線很晚，我今天晚上也等 到兩三點。