淘寶玉伯引起Web先後端研發模式討論

淘寶玉伯是是前端基礎類庫 Arale 的創始人，Arale 基於 SeaJS 和 jQuery。不久前，淘寶玉伯在 Github 的 Arale 討論頁面上拋出了本身對於 Web 先後端研發模式的思考。

        他首先指出了前端的產品形態：

前端涉及的產品形態在業界可分爲兩大類：Web Pages 和 Web Apps 。

Web Pages 是瀏覽類的，用戶主要是來看的：之內容展示爲主，輔有少許交互。前端提供基礎類庫，開發工具化、外包化。典型：首頁、營銷活動、頻道等等。

Web Apps 則以交互爲主，用戶主要是來用的。可分爲兩種：

• 體驗類：包含大量交互，同時用戶體驗很重要。好比 GMail, 支付寶收銀臺、淘寶購物車等等。
• 功能類：包含大量交互，以功能爲主，體驗不是第一位的。好比後臺系統、認證流程等。

        接下來又指出了目前遇到的問題：

1. Web Apps 的開發，前端投入了大量人力，但前端資源依舊存在潛在的瓶頸（好比新增長一條業務線時，極可能無前端去支持）。現有先後端配合的開發模式，溝通協做成本偏 高，可維護性不夠方便。在現有的研發模式下，前端自身的價值點也很難體現出來（花了大量時間在業務上，但獲得的承認很少）。
2. 最核心的問題，依舊是先後端的解耦：如何讓先後端的工做彼此更獨立，如何讓更合適的人作更合適的事，把事情作得更好。
3. 對於體驗類，目前業界有不少新興的解決方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。這些解決方案，都但願後端專一於提供 REST 接口，其餘的都交給前端來搞定。
4. 對於功能類的，目前業界解決方案依舊是比較老的一套，好比 GWT 等，包括 ExtJS 也是但願能讓後端搞定一切。

        他還提到了一些現有的解決方式：

要達成第 3 點，前端須要瞭解數據，以及深刻把控住數據以外的業務邏輯，而後利用前端技術，完成開發。

要達成第 4 點，後端依舊須要有必定的前端技能，不然容易出性能、可維護性等問題而玩不下去。

        玉伯提到他期待的方式：

• 讓前端專一於 UI 層面、體驗層面的開發。
• 讓後端專一於數據、業務邏輯的開發。
• 第 1 點和第 2 點最好能並行。能有一種很便捷的方式，
• 將第 1 點和第 2 點的工做無縫銜接起來。

核心是：解耦，讓更合適的人作更合適的事。

        pigcan 在評論中指出：

特別贊成關於在 web app 方向作爲前端對於數據須要有很是好的瞭解 ！正如「咱們該怎麼作」中說起的 backbone，其 model、以及依託 model 在對數據進行數據 change 監聽的時候，都須要對數據自己須要有很好的瞭解。 而這就會是一個比較大的問題，當 model 數量足夠多，且依賴關係足夠深的時候，如何梳理數據關係以及多人協同開發就會是一個很大的問題 。有時候不得不涉及組件與組件的數據共享與通訊，以及 view 層更多細節性的問題 。

        玉伯接下來貼出了本身和小凡的討論記錄，結論是：

組件和接口是個好的方向，對公司總體效率提高確定有很大幫助。經歷推廣和培訓以後，詳細能大規模實施的，只是前期阻力可能比較大。

        itsoso 根據本身的經驗提出：

後端按照 REST 方式的約定開發接口，前端開發足夠多的組件給後端用，對公司研發效率的提高會有很大幫助；後端也願意組裝各個組件，跟本身的接口結合起來，完成功能的開 發。讓這個流程走通，開始的阻力應該出在後端須要作一些前端積累上，在遇到腳本、樣式錯誤的時候可以完成 debug 的工做，這個過程當中仍然須要前端的幫助，須要前端投入，完成這個積累以後，前端就能夠解放出來了。

        semious 的經驗是：

體驗類開發通常能夠分爲幾個方面：

• UI 表現
• 用戶界面交互邏輯
• 數據交互
• 前端業務邏輯

一、對於 UI 表現這個我以爲能夠經過 html 模板框架將 UI 的表現方式交給 html、css 工程師負責

二、對於用戶交互邏輯能夠經過組件的方式，大多數的用戶界面交互邏輯均可以組件加上 data-*配置的方式來完成，對於絕大多數的用戶交互都是相似的，而且可分裝的，對於複雜的交互邏輯，組件能夠開放足夠的 api 結果，以供調用。這部分開發我以爲能夠交給初級前端工程師就能夠輕易實現。

三、對於數據交互這塊我建議使用數據和 html 結構解耦的方式，將數據結構定義和所綁定的 html 結構解耦，html、css 工程師負責指定調用模板的數據源，後端開發人員定義數據格式，二者經過數據解析框架實現，數據的調用源（本地或者遠程）由數據解析框架實現

四、對於前端業務邏輯的開發，我以爲可讓後端開發來參與，由於據我瞭解，對於絕大後端工程師最痛苦的不是 js 編程，而是頁面組件的樣式調整、定位之類。現有的模式，基本實現了表現和邏輯分離，後端開發人員在 js 編程中應該碰不到樣式的調整。不過咱們須要一套框架，已規範後端開發工程師對 js 的編碼方式，以避免形成 js 代碼結構性混亂。

        根據你們的討論，玉伯總結出瞭解決問題的初步思路：

1. 前端組件化，包括兩部分：
   • 基礎組件：通用的 Utilities + Widgets，好比 Cookie, Calendar, TabView 等等
   • 業務組件：針對具體的業務，由該業務線的前端，抽取出業務線的通用組件
2. 後端接口化，將數據抽象化、模型化，可輸出爲 REST 接口
3. 耦合框架化：
   • 將後端提供的 REST 接口封裝成 Model 層（或者直接在模板層同步輸出數據，將數據輸出標準化）。
   • 將設計師提供的視覺產出轉換成 Template 和 Style 。
   • 使用前端組件實現展示層的通用交互。可經過 data-attribute api 或 handlebars helper 在 template 配置完成。
   • 非標準化 View 層的開發，包括 Actions 等行爲腳本的開發，含展示層的業務邏輯。

        他還點明瞭開發人員在其中的職責：

• 前端組件化由前端開發工程師完成，輸出爲前端通用類庫和業務線的組件庫。
• 後端接口化由後端開發工程師完成，輸出爲數據模型，可同步或 REST 調用。
• 耦合框架化，早期由前端工程師負責，後端工程師參與 Model 和 Action 層的部分開發，等該模式成熟到必定階段時，可交由後端工程師獨立負責，同時前端工程師由具體項目的開發，退回到該業務線的前端技術支撐。

        接下來，他還就如何實現「耦合框架化」提出兩種思路：

1. 漸進加強派。保持現有的研發模式不變，只調整人員的職責。好比支付寶，如今前端負責模板層的開發，接下來會逐步把模板層交會給後端開發。前端將退回到 UI 組件和樣式開發的工做，後端在這過程當中，要逐步學會使用前端組件，獨立完成開發。
2. 引入前端框架。將後端的 VC 層前置到瀏覽器端，引入前端的 MVX. 代碼按照前端框架的方式從新規範和組織，後端須要學會這一套，特別是 M 層和 Biz 行爲層。從協同前端開發，到逐步能徹底勝任，獨立開發。

        玉伯所在的團隊選擇使用第一種方式，並指出了流程的變化：

保持現有研發模式不變 --》但調整人員職責，將更多工做交給後端獨立承擔 --》 在這過程當中，甄別出通用問題，沉澱到前端通用類庫或工具規範裏 --》 進一步推動前行直到達成理想狀況

        固然這對前端和後端的人員都提出了要求：

這種方式下，前端須要作到：

• 提供簡單易用的前端組件庫，包括特定業務的前端組件庫。後端能夠基於這些組件庫，快速完成頁面的搭建。
• 前端組件庫裏，包括 Alice 等樣式庫，並以相似 Bootstrap 的方式產出，須要比 Bootstrap 更易用。
• 一套前端編碼規範，須要工具化爲 IDE 的插件等，保障後端的基本編碼質量。
• 一套可衡量的有效的最佳實踐，可以讓後端比較容易遵照。以保障後續前端的性能優化和可維護性。

後端開發須要作到：

• 熟悉 JavaScript 語言。
• 瞭解基本的 DOM 和 CSS 知識。
• 無需瞭解兼容性問題。

經過上面的方式，達成後端開發往全能的 Web Developer 的轉變。

        sundayu 在評論中指出他們相似的工做以失敗了結：

前端的難點在於通用庫龐大以後的維護和升級（各個業務線都會有本身的版本），主要看功力。

最主要的是後端的問題：

• 清晰的熟悉 js 的特性。
• 讓他們按你的邏輯幹活。
• 調試。

一直祈求後端聽話、愛學、人員穩定。足夠長的時間和耐性來培訓培訓培訓。。。

        jayli 認爲 sundayu 說的有道理：

互聯網開發的基本特色是「變化」，若是你的架構無足夠強的「應變」能力，在 web 開發領域難於持久。因此，結構和解耦不是解決問題的關鍵，而是基礎，關鍵是 JS 超強的靈活性可否在框架中有更極致更放鬆的表現。如今咱們的思路過於糾結各類「約束」，這和快速變化的 web 開發有時是相背的，約束太多，反倒增長執行難度～

        iwege 指出：

其實研發模式自己應該是切合人員配置，你的新研發模式是由於前端是瓶頸，因此讓後端的救火。假若一個公司後端爲瓶頸，那前端須要切合到後端去協助。 這種相輔相成纔是真正的理想狀態。除非大家以爲大家公司的後端都很悠閒無聊，想讓他們提升下工做效率，不然我認爲最好的方式仍是招聘。

對於轉變方面，設置一個討論前提，在無資源缺少的狀況下：

對於後端來講，Java 也好，PHP 也好，至少都是同步的，可是你要求後端直接掌握 js 知識（雖然很好掌握）卻其實是兩種思惟方式的轉變了，相反前端一直都在同步異步之間鍛鍊，對內存方面也很計較，轉後端是相對簡單的。所以我我的的見解 是，讓後端知道前端知識，不如讓前端熟悉後端的基本數據調用。

對於接口約定方面，固然是 REST 的最好了，最好的是前端約定好 json 格式，而後讓後端嘗試輸出就行了。前端給測試用框架。無需後端熟悉 js。

        semious 繼續提到：

我的認爲，就程序的發展歷程來看，前端是從後端分離出來的，由於前端變得愈來愈複雜，須要專門的人手去處理，本人就是一個例子。因此我的認爲讓後端 的開發人員寫前端代碼不會是一件很難的事情，如今 JavaScript 通過那麼多年的發展，其編碼規範、設計模式愈來愈有章可循，讓後端開發人員學會 js 語言自己，我的認爲難度不會很高，不事後端和前端有一些比較大的不一樣在於：

• 代碼結構的不一樣，從標準的 OO 變成 js 特有 OO 方式，面向對象式編程到面向混合式編程（有對象，有函數）
• 面向請求式編程方式（主要指 web 後端開發人員，不包括純後端業務級的開發人員）變化到面向事件和麪向文檔式的編程方式
• 標記性語言方面的編程特性
• JavaScript 腳本語言的特性
• 運行時環境不一樣，從服務器環境轉向瀏覽器環境的變化等等

若是能在培訓中，重點說明這些不一樣的話，後端人員應該能很快上手。

        隨着 Web 前端開發重要性的不斷增長，先後端開發人員之間如何協調成爲了你們關注的焦點。咱們的讀者，不知道您所瞭解的先後端研發模式有哪些？歡迎分享！