Web 研發模式演變

前不久徐飛寫了一篇很是好的文章:Web 應用的組件化開發。本文嘗試從歷史發展角度,說說各類研發模式的優劣。前端

1、簡單明快的早期時代

1

可稱之爲 Web 1.0 時代,很適合創業型小項目。不分先後端,經常 3-5 人搞定所有開發。頁面由 JSP、PHP 等project師在服務端生成,瀏覽器負責展示。基本上是服務端給什麼瀏覽器就展示什麼,展示的控制在 Web Server 層。git

這樣的模式的優勢是:簡單明快,本地起一個 Tomcat 或 Apache 就能開發,調試什麼的都還好,僅僅要業務不太複雜。github

然而業務總會變複雜。這是好事情。不然很是可能就意味着創業失敗了。業務的複雜會讓 Service 愈來愈多。參與開發的人員也很是可能從幾我的高速擴招到幾十人。在這樣的狀況下,會遇到一些典型問題:編程

一、Service 愈來愈多,調用關係變複雜,前端搭建本地環境再也不是一件簡單的事。後端

考慮團隊協做,每每會考慮搭建集中式的開發server來解決。這樣的解決方式對編譯型的後端開發來講或許還好,但對前端開發來講並不友好。天哪,我不過想調整下button樣式,卻要本地開發、代碼上傳、驗證生效等好幾個步驟。瀏覽器

或許習慣了也還好,但開發server老是不那麼穩定,出問題時每每需要依賴後端開發搞定。cookie

看似不過前端開發難以本地化,但這對研發效率的影響事實上蠻大。架構

二、JSP 等代碼的可維護性愈來愈差。JSP 很強大。可以內嵌 Java 代碼。框架

這樣的強大使得先後端的職責不清晰,JSP 變成了一個灰色地帶。運維

經常爲了趕項目,爲了各類緊急需求,會在 JSP 裏揉雜大量業務代碼。

積攢到必定階段時,每每會帶來大量維護成本。

這個時期,爲了提升可維護性,可以經過如下的方式實現前端的組件化:

2

理論上。假設你們都能依照最佳實踐去書寫代碼,那麼不論是 JSP 仍是 PHP,可維護性都不會差。但可維護性不少其它是project含義。有時候需要經過限制帶來自由,需要某種約定,使得即使是新手也不會寫出太糟糕的代碼。

怎樣讓先後端分工更合理高效,怎樣提升代碼的可維護性,在 Web 開發中很是重要。如下咱們繼續來看,技術架構的演變怎樣解決這兩個問題。

2、後端爲主的 MVC 時代

爲了減小複雜度。之後端爲出發點,有了 Web Server 層的架構升級。比方 Structs、Spring MVC 等,這是後端的 MVC 時代。

3

代碼可維護性獲得明顯好轉,MVC 是個很好的協做模式。從架構層面讓開發人員懂得什麼代碼應該寫在什麼地方。

爲了讓 View 層更簡單幹脆。還可以選擇 Velocity、Freemaker 等模板,使得模板裏寫不了 Java 代碼。看起來是功能變弱了,但正是這樣的限制使得先後端分工更清晰。然而依然並不是那麼清晰,這個階段的典型問題是:

一、前端開發重度依賴開發環境。這樣的架構下,先後端協做有兩種模式:一種是前端寫 demo。寫好後。讓後端去套模板。淘寶早期包含現在依然有大量業務線是這樣的模式。優勢很是明顯。demo 可以本地開發,很是高效。

不足是還需要後端套模板,有可能套錯,套完後還需要前端肯定,來回溝通調整的成本比較大。還有一種協做模式是前端負責瀏覽器端的所有開發和server端的 View 層模板開發,支付寶是這樣的模式。

優勢是 UI 相關的代碼都是前端去寫就好,後端不用太關注,不足就是前端開發重度綁定後端環境。環境成爲影響前端開發效率的重要因素。

二、先後端職責依然糾纏不清。Velocity 模板仍是蠻強大的。變量、邏輯、宏等特性。依然可以經過拿到的上下文變量來實現各類業務邏輯。這樣,僅僅要前端弱勢一點,每每就會被後端要求在模板層寫出很多業務代碼。

另外一個很是大的灰色地帶是 Controller,頁面路由等功能本應該是前端最關注的。但倒是由後端來實現。Controller 自己與 Model 每每也會糾纏不清,看了讓人咬牙的代碼經常會出現在 Controller 層。這些問題不能全歸結於程序猿的素質,不然 JSP 就夠了。

經常會有人吐槽 Java。但 Java 在project化開發方面真的作了大量思考和架構嘗試。Java 蠻符合馬雲的一句話:讓平庸人作非凡事。

3、Ajax 帶來的 SPA 時代

歷史滾滾往前,2004 年 Gmail 像風同樣的女子來到人間,很是快 2005 年 Ajax 正式提出,加上 CDN 開始大量用於靜態資源存儲,因而出現了 JavaScript 王者歸來的 SPA (Single Page Application 單頁面應用)時代。

4

這樣的模式下,先後端的分工很是清晰,先後端的關鍵協做點是 Ajax 接口。

看起來是如此美妙,但回過頭來看看的話,這與 JSP 時代差異不大。複雜度從服務端的 JSP 裏移到了瀏覽器的 JavaScript,瀏覽器端變得很是複雜。相似 Spring MVC,這個時代開始出現瀏覽器端的分層架構:

5

對於 SPA 應用。有幾個很是重要的挑戰:

一、先後端接口的約定。假設後端的接口一塌糊塗。假設後端的業務模型不夠穩定,那麼前端開發會很是痛苦。

這一塊在業界有 API Blueprint 等方案來約定和沉澱接口。在阿里。很多團隊也有相似嘗試。經過接口規則、接口平臺等方式來作。有了和後端一塊兒沉澱的接口規則,還可以用來模擬數據。使得先後端可以在約定接口後實現高效並行開發。

相信這一塊會越作越好。

二、前端開發的複雜度控制。SPA 應用大多以功能交互型爲主。JavaScript 代碼過十萬行很是正常。大量 JS 代碼的組織。與 View 層的綁定等。都不是easy的事情。

典型的解決方式是業界的 Backbone,但 Backbone 作的事還很是有限,依然存在大量空白區域需要挑戰。

SPA 讓前端看到了一絲綠色。但依然是在荒漠中行走。

4、前端爲主的 MV* 時代

爲了減小前端開發複雜度,除了 Backbone。還有大量框架涌現,比方 EmberJS、KnockoutJS、AngularJS 等等。這些框架總的原則是先按類型分層,比方 Templates、Controllers、Models,而後再在層內作切分。例如如下圖:

6

優勢很是明顯:

一、先後端職責很是清晰。前端工做在瀏覽器端,後端工做在服務端。清晰的分工,可以讓開發並行,測試數據的模擬不難,前端可以本地開發。後端則可以專一於業務邏輯的處理,輸出 RESTful 等接口。

二、前端開發的複雜度可控。前端代碼很是重,但合理的分層,讓前端代碼能各司其職。這一塊蠻有意思的,簡單如模板特性的選擇,就有很是多很是多講究。

並非越強大越好,限制什麼,留下哪些自由,代碼應該怎樣組織,所有這一切設計,得花一本的厚度去說明。

三、部署相對獨立,產品體驗可以高速改進。

但依然有不足之處:

一、代碼不能複用。比方後端依然需要對數據作各類校驗。校驗邏輯沒法複用瀏覽器端的代碼。

假設可以複用。那麼後端的數據校驗可以相對簡單化。
二、全異步,對 SEO 不利。每每還需要服務端作同步渲染的降級方案。


三、性能並非最佳。特別是移動互聯網環境下。
四、SPA 不能知足所有需求,依然存在大量多頁面應用。URL Design 需要後端配合,前端沒法全然掌控。

5、Node 帶來的全棧時代

前端爲主的 MV* 模式攻克了很是多很是多問題。但如上所述。依然存在很多不足之處。隨着 Node.js 的興起,JavaScript 開始有能力執行在服務端。

這意味着可以有一種新的研發模式:

7

在這樣的研發模式下,先後端的職責很是清晰。對前端來講,兩個 UI 層各司其職:

一、Front-end UI layer 處理瀏覽器層的展示邏輯。經過 CSS 渲染樣式,經過 JavaScript 加入交互功能,HTML 的生成也可以放在這層。詳細看應用場景。

二、Back-end UI layer 處理路由、模板、數據獲取、cookie 等。經過路由,前端最終可以自主把控 URL Design,這樣不論是單頁面應用仍是多頁面應用。前端都可以自由調控。後端也最終可以擺脫對展示的強關注,轉而可以專心於業務邏輯層的開發。

經過 Node,Web Server 層也是 JavaScript 代碼,這意味着部分代碼可先後複用,需要 SEO 的場景可以在服務端同步渲染。由於異步請求太多致使的性能問題也可以經過服務端來緩解。

前一種模式的不足,經過這樣的模式差點兒都能完美解決掉。

與 JSP 模式相比,全棧模式看起來是一種迴歸,也的確是一種向原始開發模式的迴歸,只是是一種螺旋上升式的迴歸。

基於 Node 的全棧模式,依然面臨很是多挑戰:

一、需要前端對服務端編程有更進一步的認識。

比方 network/tcp、PE 等知識的掌握。
二、Node 層與 Java 層的高效通訊。Node 模式下,都在server端,RESTful HTTP 通訊未必高效,經過 SOAP 等方式通訊更高效。

一切需要在驗證中前行。
三、對部署、運維層面的熟練了解。需要不少其它知識點和實操經驗。
四、大量歷史遺留問題怎樣過渡。這多是最大最大的阻力。

6、小結

回想歷史老是讓人感慨,展望將來則讓人興奮。上面講到的研發模式。除了最後一種還在探索期,其它各類在各大公司都已有大量實踐。幾點小結:

一、模式沒有好壞高下之分。僅僅有合不合適。
二、Ajax 給前端開發帶來了一次質的飛躍,Node 很是多是第二次。


三、SoC(關注度分離) 是一條偉大的原則。

上面種種模式。都是讓先後端的職責更清晰,分工更合理高效。
四、還有個原則,讓合適的人作合適的事。比方 Web Server 層的 UI Layer 開發,前端是更合適的人選。

歷史有時候會打轉。咋一看覺得是回去了,其實是螺旋轉了一圈。站在了一個新的起點。

題圖:演化真不easy呀。

相關文章
相關標籤/搜索