作者：玉伯
前不久徐飛寫了一篇很好的文章：web 應用的元件化開發。本文嘗試從曆史發展角度，說說各種研發模式的優劣。
可稱之為 web 1.0 時代，非常适合創業型小項目，不分前後端，經常 3-5 人搞定所有開發。頁面由 jsp、php 等工程師在服務端生成，浏覽器負責展現。基本上是服務端給什麼浏覽器就展現什麼，展現的控制在 web server 層。
這種模式的好處是：簡單明快，本地起一個 tomcat 或 apache 就能開發，調試什麼的都還好，隻要業務不太複雜。
然而業務總會變複雜，這是好事情，否則很可能就意味着創業失敗了。業務的複雜會讓 service 越來越多，參與開發的人員也很可能從幾個人快速擴招到幾十人。在這種情況下，會遇到一些典型問題：
1、service 越來越多，調用關系變複雜，前端搭建本地環境不再是一件簡單的事。考慮團隊協作，往往會考慮搭建集中式的開發伺服器來解決。這種解決方案對編譯型的後端開發來說也許還好，但對前端開發來說并不友好。天哪，我隻是想調整下按鈕樣式，卻要本地開發、代碼上傳、驗證生效等好幾個步驟。也許習慣了也還好，但開發伺服器總是不那麼穩定，出問題時往往需要依賴後端開發搞定。看似僅僅是前端開發難以本地化，但這對研發效率的影響其實蠻大。
2、**jsp 等代碼的可維護性越來越差。**jsp 非常強大，可以内嵌 java 代碼。這種強大使得前後端的職責不清晰，jsp 變成了一個灰色地帶。經常為了趕項目，為了各種緊急需求，會在 jsp 裡揉雜大量業務代碼。積攢到一定階段時，往往會帶來大量維護成本。
這個時期，為了提高可維護性，可以通過下面的方式實作前端的元件化：
理論上，如果大家都能按照最佳實踐去書寫代碼，那麼無論是 jsp 還是 php，可維護性都不會差。但可維護性更多是工程含義，有時候需要通過限制帶來自由，需要某種約定，使得即便是新手也不會寫出太糟糕的代碼。
如何讓前後端分工更合理高效，如何提高代碼的可維護性，在 web 開發中很重要。下面我們繼續來看，技術架構的演變如何解決這兩個問題。
二、後端為主的 mvc 時代
為了降低複雜度，以後端為出發點，有了 web server 層的架構更新，比如 structs、spring mvc 等，這是後端的 mvc 時代。
代碼可維護性得到明顯好轉，mvc 是個非常好的協作模式，從架構層面讓開發者懂得什麼代碼應該寫在什麼地方。為了讓 view 層更簡單幹脆，還可以選擇 velocity、freemaker 等模闆，使得模闆裡寫不了 java 代碼。看起來是功能變弱了，但正是這種限制使得前後端分工更清晰。然而依舊并不是那麼清晰，這個階段的典型問題是：
1、前端開發重度依賴開發環境。這種架構下，前後端協作有兩種模式：一種是前端寫 demo，寫好後，讓後端去套模闆。淘寶早期包括現在依舊有大量業務線是這種模式。好處很明顯，demo 可以本地開發，很高效。不足是還需要後端套模闆，有可能套錯，套完後還需要前端确定，來回溝通調整的成本比較大。另一種協作模式是前端負責浏覽器端的所有開發和伺服器端的 view 層模闆開發，支付寶是這種模式。好處是 ui 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成為影響前端開發效率的重要因素。
2、**前後端職責依舊糾纏不清。**velocity 模闆還是蠻強大的，變量、邏輯、宏等特性，依舊可以通過拿到的上下文變量來實作各種業務邏輯。這樣，隻要前端弱勢一點，往往就會被後端要求在模闆層寫出不少業務代碼。還有一個很大的灰色地帶是 controller，頁面路由等功能本應該是前端最關注的，但卻是由後端來實作。controller 本身與 model 往往也會糾纏不清，看了讓人咬牙的代碼經常會出現在 controller 層。這些問題不能全歸結于程式員的素養，否則 jsp 就夠了。
經常會有人吐槽 java，但 java 在工程化開發方面真的做了大量思考和架構嘗試。java 蠻符合馬雲的一句話：讓平凡人做非凡事。
三、ajax 帶來的 spa 時代
曆史滾滾往前，2004 年 gmail 像風一樣的女子來到人間，很快 2005 年 ajax 正式提出，加上 cdn 開始大量用于靜态資源存儲，于是出現了 javascript 王者歸來的 spa （single page application 單頁面應用）時代。
這種模式下，前後端的分工非常清晰，前後端的關鍵協作點是 ajax 接口。看起來是如此美妙，但回過頭來看看的話，這與 jsp 時代差別不大。複雜度從服務端的 jsp 裡移到了浏覽器的 javascript，浏覽器端變得很複雜。類似 spring mvc，這個時代開始出現浏覽器端的分層架構：
對于 spa 應用，有幾個很重要的挑戰：
1、前後端接口的約定。如果後端的接口一塌糊塗，如果後端的業務模型不夠穩定，那麼前端開發會很痛苦。這一塊在業界有 api blueprint 等方案來約定和沉澱接口，在阿裡，不少團隊也有類似嘗試，通過接口規則、接口平台等方式來做。有了和後端一起沉澱的接口規則，還可以用來模拟資料，使得前後端可以在約定接口後實作高效并行開發。相信這一塊會越做越好。
2、**前端開發的複雜度控制。**spa 應用大多以功能互動型為主，javascript 代碼過十萬行很正常。大量 js 代碼的組織，與 view 層的綁定等，都不是容易的事情。典型的解決方案是業界的 backbone，但 backbone 做的事還很有限，依舊存在大量空白區域需要挑戰。
spa 讓前端看到了一絲綠色，但依舊是在荒漠中行走。
四、前端為主的 mv* 時代
為了降低前端開發複雜度，除了 backbone，還有大量架構湧現，比如 emberjs、knockoutjs、angularjs 等等。這些架構總的原則是先按類型分層，比如 templates、controllers、models，然後再在層内做切分，如下圖：
好處很明顯：
1、前後端職責很清晰。前端工作在浏覽器端，後端工作在服務端。清晰的分工，可以讓開發并行，測試資料的模拟不難，前端可以本地開發。後端則可以專注于業務邏輯的處理，輸出 restful 等接口。
2、前端開發的複雜度可控。前端代碼很重，但合理的分層，讓前端代碼能各司其職。這一塊蠻有意思的，簡單如模闆特性的選擇，就有很多很多講究。并非越強大越好，限制什麼，留下哪些自由，代碼應該如何組織，所有這一切設計，得花一本的厚度去說明。
3、部署相對獨立，産品體驗可以快速改進。
但依舊有不足之處：
1、代碼不能複用。比如後端依舊需要對資料做各種校驗，校驗邏輯無法複用浏覽器端的代碼。如果可以複用，那麼後端的資料校驗可以相對簡單化。
2、全異步，對 seo 不利。往往還需要服務端做同步渲染的降級方案。
3、性能并非最佳，特别是移動網際網路環境下。
4、spa 不能滿足所有需求，依舊存在大量多頁面應用。url design 需要後端配合，前端無法完全掌控。
五、node 帶來的全棧時代
前端為主的 mv* 模式解決了很多很多問題，但如上所述，依舊存在不少不足之處。随着 node.js 的興起，javascript 開始有能力運作在服務端。這意味着可以有一種新的研發模式：
在這種研發模式下，前後端的職責很清晰。對前端來說，兩個 ui 層各司其職：
1、front-end ui layer 處理浏覽器層的展現邏輯。通過 css 渲染樣式，通過 javascript 添加互動功能，html 的生成也可以放在這層，具體看應用場景。
2、back-end ui layer 處理路由、模闆、資料擷取、cookie 等。通過路由，前端終于可以自主把控 url design，這樣無論是單頁面應用還是多頁面應用，前端都可以自由調控。後端也終于可以擺脫對展現的強關注，轉而可以專心于業務邏輯層的開發。
通過 node，web server 層也是 javascript 代碼，這意味着部分代碼可前後複用，需要 seo 的場景可以在服務端同步渲染，由于異步請求太多導緻的性能問題也可以通過服務端來緩解。前一種模式的不足，通過這種模式幾乎都能完美解決掉。
與 jsp 模式相比，全棧模式看起來是一種回歸，也的确是一種向原始開發模式的回歸，不過是一種螺旋上升式的回歸。
基于 node 的全棧模式，依舊面臨很多挑戰：
1、需要前端對服務端程式設計有更進一步的認識。比如 network/tcp、pe 等知識的掌握。
2、node 層與 java 層的高效通信。node 模式下，都在伺服器端，restful http 通信未必高效，通過 soap 等方式通信更高效。一切需要在驗證中前行。
3、對部署、運維層面的熟練了解，需要更多知識點和實操經驗。
4、大量曆史遺留問題如何過渡。這可能是最大最大的阻力。
六、小結
回顧曆史總是讓人感慨，展望未來則讓人興奮。上面講到的研發模式，除了最後一種還在探索期，其他各種在各大公司都已有大量實踐。幾點小結：
1、模式沒有好壞高下之分，隻有合不合适。
2、ajax 給前端開發帶來了一次質的飛躍，node 很可能是第二次。
3、soc（關注度分離） 是一條偉大的原則。上面種種模式，都是讓前後端的職責更清晰，分工更合理高效。
4、還有個原則，讓合适的人做合适的事。比如 web server 層的 ui layer 開發，前端是更合适的人選。
曆史有時候會打轉，咋一看以為是回去了，實際上是螺旋轉了一圈，站在了一個新的起點。