淘寶玉伯引發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 表現
• 用戶界面交互邏輯
• 數據交互
• 前端業務邏輯

1、對于 UI 表現這個我覺得可以通過 html 模板框架將 UI 的表現方式交給 html、css 工程師負責

2、對于用戶交互邏輯可以通過組件的方式，大多數的用戶界面交互邏輯都可以組件加上 data-*配置的方式來完成，對于絕大多數的用戶交互都是類似的，并且可分裝的，對于復雜的交互邏輯，組件可以開放足夠的 api 結果，以供調用。這部分開發我覺得可以交給初級前端工程師就可以輕易實現。

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

4、對于前端業務邏輯的開發，我覺得可以讓后端開發來參與，因為據我了解，對于絕大后端工程師最痛苦的不是 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 前端開發重要性的不斷增加，前后端開發人員之間如何協調成為了大家關注的焦點。我們的讀者，不知道您所了解的前后端研發模式有哪些？歡迎分享！