摘自玉伯的文章Web研發(fā)模式演變
一市咆、簡單明快的早期時(shí)代
可稱之為 Web 1.0 時(shí)代，非常適合創(chuàng)業(yè)型小項(xiàng)目核芽，不分前后端，經(jīng)常 3-5 人搞定所有開發(fā)惊完。頁面由 JSP猴伶、PHP 等工程師在服務(wù)端生成，瀏覽器負(fù)責(zé)展現(xiàn)霹俺。基本上是服務(wù)端給什么瀏覽器就展現(xiàn)什么毒费，展現(xiàn)的控制在 Web Server 層丙唧。
這種模式的好處是：簡單明快，本地起一個 Tomcat 或 Apache 就能開發(fā)觅玻，調(diào)試什么的都還好想际，只要業(yè)務(wù)不太復(fù)雜。
然而業(yè)務(wù)總會變復(fù)雜溪厘，這是好事情胡本，否則很可能就意味著創(chuàng)業(yè)失敗了。業(yè)務(wù)的復(fù)雜會讓 Service 越來越多畸悬，參與開發(fā)的人員也很可能從幾個人快速擴(kuò)招到幾十人侧甫。在這種情況下，會遇到一些典型問題：
1、Service 越來越多披粟，調(diào)用關(guān)系變復(fù)雜咒锻，前端搭建本地環(huán)境不再是一件簡單的事。考慮團(tuán)隊(duì)協(xié)作守屉，往往會考慮搭建集中式的開發(fā)服務(wù)器來解決惑艇。這種解決方案對編譯型的后端開發(fā)來說也許還好，但對前端開發(fā)來說并不友好胸梆。天哪敦捧，我只是想調(diào)整下按鈕樣式，卻要本地開發(fā)碰镜、代碼上傳、驗(yàn)證生效等好幾個步驟习瑰。也許習(xí)慣了也還好绪颖，但開發(fā)服務(wù)器總是不那么穩(wěn)定，出問題時(shí)往往需要依賴后端開發(fā)搞定甜奄∧幔看似僅僅是前端開發(fā)難以本地化，但這對研發(fā)效率的影響其實(shí)蠻大课兄。
2牍氛、JSP 等代碼的可維護(hù)性越來越差。JSP 非常強(qiáng)大烟阐，可以內(nèi)嵌 Java 代碼搬俊。這種強(qiáng)大使得前后端的職責(zé)不清晰，JSP 變成了一個灰色地帶蜒茄。經(jīng)常為了趕項(xiàng)目唉擂，為了各種緊急需求，會在 JSP 里揉雜大量業(yè)務(wù)代碼檀葛。積攢到一定階段時(shí)玩祟，往往會帶來大量維護(hù)成本。
這個時(shí)期屿聋，為了提高可維護(hù)性空扎，可以通過下面的方式實(shí)現(xiàn)前端的組件化：
理論上，如果大家都能按照最佳實(shí)踐去書寫代碼润讥，那么無論是 JSP 還是 PHP转锈，可維護(hù)性都不會差。但可維護(hù)性更多是工程含義象对，有時(shí)候需要通過限制帶來自由黑忱，需要某種約定，使得即便是新手也不會寫出太糟糕的代碼。
如何讓前后端分工更合理高效甫煞，如何提高代碼的可維護(hù)性菇曲，在 Web 開發(fā)中很重要。下面我們繼續(xù)來看抚吠，技術(shù)架構(gòu)的演變?nèi)绾谓鉀Q這兩個問題常潮。
二、后端為主的 MVC 時(shí)代
為了降低復(fù)雜度楷力，以后端為出發(fā)點(diǎn)喊式，有了 Web Server 層的架構(gòu)升級，比如 Structs萧朝、Spring MVC 等岔留，這是后端的 MVC 時(shí)代。
代碼可維護(hù)性得到明顯好轉(zhuǎn)检柬，MVC 是個非常好的協(xié)作模式献联，從架構(gòu)層面讓開發(fā)者懂得什么代碼應(yīng)該寫在什么地方。為了讓 View 層更簡單干脆何址，還可以選擇 Velocity里逆、Freemaker 等模板，使得模板里寫不了 Java 代碼用爪≡海看起來是功能變?nèi)趿耍沁@種限制使得前后端分工更清晰偎血。然而依舊并不是那么清晰诸衔，這個階段的典型問題是：
1、前端開發(fā)重度依賴開發(fā)環(huán)境烁巫。這種架構(gòu)下署隘，前后端協(xié)作有兩種模式：一種是前端寫 demo，寫好后亚隙，讓后端去套模板磁餐。淘寶早期包括現(xiàn)在依舊有大量業(yè)務(wù)線是這種模式。好處很明顯阿弃，demo 可以本地開發(fā)诊霹，很高效。不足是還需要后端套模板渣淳，有可能套錯脾还，套完后還需要前端確定，來回溝通調(diào)整的成本比較大入愧。另一種協(xié)作模式是前端負(fù)責(zé)瀏覽器端的所有開發(fā)和服務(wù)器端的 View 層模板開發(fā)鄙漏，支付寶是這種模式嗤谚。好處是 UI 相關(guān)的代碼都是前端去寫就好，后端不用太關(guān)注怔蚌，不足就是前端開發(fā)重度綁定后端環(huán)境巩步，環(huán)境成為影響前端開發(fā)效率的重要因素。
2桦踊、前后端職責(zé)依舊糾纏不清椅野。Velocity 模板還是蠻強(qiáng)大的，變量籍胯、邏輯竟闪、宏等特性，依舊可以通過拿到的上下文變量來實(shí)現(xiàn)各種業(yè)務(wù)邏輯杖狼。這樣炼蛤，只要前端弱勢一點(diǎn)，往往就會被后端要求在模板層寫出不少業(yè)務(wù)代碼蝶涩。還有一個很大的灰色地帶是 Controller鲸湃，頁面路由等功能本應(yīng)該是前端最關(guān)注的，但卻是由后端來實(shí)現(xiàn)子寓。Controller 本身與 Model 往往也會糾纏不清，看了讓人咬牙的代碼經(jīng)常會出現(xiàn)在 Controller 層笋除。這些問題不能全歸結(jié)于程序員的素養(yǎng)斜友，否則 JSP 就夠了。
經(jīng)常會有人吐槽 Java垃它，但 Java 在工程化開發(fā)方面真的做了大量思考和架構(gòu)嘗試鲜屏。Java 蠻符合馬云的一句話：讓平凡人做非凡事。
三国拇、Ajax 帶來的 SPA 時(shí)代
歷史滾滾往前洛史，2004 年 Gmail 像風(fēng)一樣的女子來到人間，很快 2005 年 Ajax 正式提出酱吝，加上 CDN 開始大量用于靜態(tài)資源存儲也殖，于是出現(xiàn)了 JavaScript 王者歸來的 SPA （Single Page Application 單頁面應(yīng)用）時(shí)代。
這種模式下务热，前后端的分工非常清晰忆嗜，前后端的關(guān)鍵協(xié)作點(diǎn)是 Ajax 接口∑槠瘢看起來是如此美妙捆毫，但回過頭來看看的話，這與 JSP 時(shí)代區(qū)別不大冲甘。復(fù)雜度從服務(wù)端的 JSP 里移到了瀏覽器的 JavaScript绩卤，瀏覽器端變得很復(fù)雜途样。類似 Spring MVC，這個時(shí)代開始出現(xiàn)瀏覽器端的分層架構(gòu)：
對于 SPA 應(yīng)用濒憋，有幾個很重要的挑戰(zhàn)：
1何暇、前后端接口的約定。如果后端的接口一塌糊涂跋炕，如果后端的業(yè)務(wù)模型不夠穩(wěn)定赖晶，那么前端開發(fā)會很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來約定和沉淀接口辐烂，在阿里遏插，不少團(tuán)隊(duì)也有類似嘗試，通過接口規(guī)則纠修、接口平臺等方式來做胳嘲。有了和后端一起沉淀的接口規(guī)則，還可以用來模擬數(shù)據(jù)扣草，使得前后端可以在約定接口后實(shí)現(xiàn)高效并行開發(fā)了牛。相信這一塊會越做越好。
2辰妙、前端開發(fā)的復(fù)雜度控制鹰祸。SPA 應(yīng)用大多以功能交互型為主，JavaScript 代碼過十萬行很正常密浑。大量 JS 代碼的組織蛙婴，與 View 層的綁定等，都不是容易的事情尔破。典型的解決方案是業(yè)界的 Backbone街图，但 Backbone 做的事還很有限，依舊存在大量空白區(qū)域需要挑戰(zhàn)懒构。
SPA 讓前端看到了一絲綠色餐济，但依舊是在荒漠中行走。
四胆剧、前端為主的 MV* 時(shí)代
為了降低前端開發(fā)復(fù)雜度絮姆，除了 Backbone，還有大量框架涌現(xiàn)赞赖，比如 EmberJS滚朵、KnockoutJS、AngularJS 等等前域。這些框架總的原則是先按類型分層辕近，比如 Templates、Controllers匿垄、Models移宅，然后再在層內(nèi)做切分归粉，如下圖：
好處很明顯：
1、前后端職責(zé)很清晰漏峰。前端工作在瀏覽器端糠悼，后端工作在服務(wù)端。清晰的分工浅乔，可以讓開發(fā)并行倔喂，測試數(shù)據(jù)的模擬不難，前端可以本地開發(fā)靖苇。后端則可以專注于業(yè)務(wù)邏輯的處理席噩，輸出 RESTful 等接口。
2贤壁、前端開發(fā)的復(fù)雜度可控悼枢。前端代碼很重，但合理的分層脾拆，讓前端代碼能各司其職馒索。這一塊蠻有意思的，簡單如模板特性的選擇名船，就有很多很多講究绰上。并非越強(qiáng)大越好，限制什么渠驼，留下哪些自由渔期，代碼應(yīng)該如何組織，所有這一切設(shè)計(jì)渴邦，得花一本的厚度去說明。
3拘哨、部署相對獨(dú)立谋梭，產(chǎn)品體驗(yàn)可以快速改進(jìn)。
但依舊有不足之處：
1倦青、代碼不能復(fù)用瓮床。比如后端依舊需要對數(shù)據(jù)做各種校驗(yàn)，校驗(yàn)邏輯無法復(fù)用瀏覽器端的代碼产镐。如果可以復(fù)用隘庄，那么后端的數(shù)據(jù)校驗(yàn)可以相對簡單化。
2癣亚、全異步丑掺，對 SEO 不利。往往還需要服務(wù)端做同步渲染的降級方案述雾。
3街州、性能并非最佳兼丰，特別是移動互聯(lián)網(wǎng)環(huán)境下。
4唆缴、SPA 不能滿足所有需求鳍征，依舊存在大量多頁面應(yīng)用。URL Design 需要后端配合面徽，前端無法完全掌控艳丛。
五、Node 帶來的全棧時(shí)代
前端為主的 MV* 模式解決了很多很多問題趟紊，但如上所述氮双，依舊存在不少不足之處。隨著 Node.js 的興起织阳，JavaScript 開始有能力運(yùn)行在服務(wù)端眶蕉。這意味著可以有一種新的研發(fā)模式：
在這種研發(fā)模式下，前后端的職責(zé)很清晰唧躲。對前端來說造挽，兩個 UI 層各司其職：
1、Front-end UI layer 處理瀏覽器層的展現(xiàn)邏輯弄痹。通過 CSS 渲染樣式饭入，通過 JavaScript 添加交互功能，HTML 的生成也可以放在這層肛真，具體看應(yīng)用場景谐丢。
2、Back-end UI layer 處理路由蚓让、模板乾忱、數(shù)據(jù)獲取、cookie 等历极。通過路由窄瘟，前端終于可以自主把控 URL Design，這樣無論是單頁面應(yīng)用還是多頁面應(yīng)用趟卸，前端都可以自由調(diào)控蹄葱。后端也終于可以擺脫對展現(xiàn)的強(qiáng)關(guān)注，轉(zhuǎn)而可以專心于業(yè)務(wù)邏輯層的開發(fā)锄列。
通過 Node图云，Web Server 層也是 JavaScript 代碼，這意味著部分代碼可前后復(fù)用邻邮，需要 SEO 的場景可以在服務(wù)端同步渲染竣况，由于異步請求太多導(dǎo)致的性能問題也可以通過服務(wù)端來緩解。前一種模式的不足筒严，通過這種模式幾乎都能完美解決掉帕翻。
與 JSP 模式相比鸠补，全棧模式看起來是一種回歸，也的確是一種向原始開發(fā)模式的回歸嘀掸，不過是一種螺旋上升式的回歸紫岩。
基于 Node 的全棧模式，依舊面臨很多挑戰(zhàn)：
1睬塌、需要前端對服務(wù)端編程有更進(jìn)一步的認(rèn)識泉蝌。比如 network/tcp、PE 等知識的掌握揩晴。
2勋陪、Node 層與 Java 層的高效通信。Node 模式下硫兰，都在服務(wù)器端诅愚，RESTful HTTP 通信未必高效，通過 SOAP 等方式通信更高效劫映。一切需要在驗(yàn)證中前行违孝。
3、對部署泳赋、運(yùn)維層面的熟練了解雌桑，需要更多知識點(diǎn)和實(shí)操經(jīng)驗(yàn)。
4祖今、大量歷史遺留問題如何過渡校坑。這可能是最大最大的阻力。
總結(jié)：
雖然自身經(jīng)歷過前端的幾個時(shí)代千诬，但一直隨波逐流耍目，希望自己也可以發(fā)現(xiàn)問題的本質(zhì)，然后解決問題徐绑。
