一怯疤、簡(jiǎn)單明快的早期時(shí)代
可稱之為 Web 1.0 時(shí)代浆洗，非常適合創(chuàng)業(yè)型小項(xiàng)目，不分前后端集峦，經(jīng)常 3-5 人搞定所有開(kāi)發(fā)伏社。頁(yè)面由 JSP、PHP 等工程師在服務(wù)端生成塔淤，瀏覽器負(fù)責(zé)展現(xiàn)摘昌。基本上是服務(wù)端給什么瀏覽器就展現(xiàn)什么高蜂，展現(xiàn)的控制在 Web Server 層聪黎。
這種模式的好處是：簡(jiǎn)單明快，本地起一個(gè) Tomcat 或 Apache 就能開(kāi)發(fā)备恤，調(diào)試什么的都還好稿饰，只要業(yè)務(wù)不太復(fù)雜。
然而業(yè)務(wù)總會(huì)變復(fù)雜露泊，這是好事情喉镰，否則很可能就意味著創(chuàng)業(yè)失敗了。業(yè)務(wù)的復(fù)雜會(huì)讓 Service 越來(lái)越多惭笑，參與開(kāi)發(fā)的人員也很可能從幾個(gè)人快速擴(kuò)招到幾十人侣姆。在這種情況下，會(huì)遇到一些典型問(wèn)題：
- 1沉噩、Service 越來(lái)越多捺宗，調(diào)用關(guān)系變復(fù)雜，前端搭建本地環(huán)境不再是一件簡(jiǎn)單的事屁擅。考慮團(tuán)隊(duì)協(xié)作偿凭，往往會(huì)考慮搭建集中式的開(kāi)發(fā)服務(wù)器來(lái)解決。這種解決方案對(duì)編譯型的后端開(kāi)發(fā)來(lái)說(shuō)也許還好派歌，但對(duì)前端開(kāi)發(fā)來(lái)說(shuō)并不友好弯囊。天哪痰哨，我只是想調(diào)整下按鈕樣式，卻要本地開(kāi)發(fā)匾嘱、代碼上傳斤斧、驗(yàn)證生效等好幾個(gè)步驟。也許習(xí)慣了也還好霎烙，但開(kāi)發(fā)服務(wù)器總是不那么穩(wěn)定撬讽，出問(wèn)題時(shí)往往需要依賴后端開(kāi)發(fā)搞定⌒看似僅僅是前端開(kāi)發(fā)難以本地化游昼，但這對(duì)研發(fā)效率的影響其實(shí)蠻大。
- 2尝蠕、JSP 等代碼的可維護(hù)性越來(lái)越差烘豌。JSP 非常強(qiáng)大，可以內(nèi)嵌 Java 代碼看彼。這種強(qiáng)大使得前后端的職責(zé)不清晰廊佩，JSP 變成了一個(gè)灰色地帶。經(jīng)常為了趕項(xiàng)目靖榕，為了各種緊急需求标锄，會(huì)在 JSP 里揉雜大量業(yè)務(wù)代碼。積攢到一定階段時(shí)茁计，往往會(huì)帶來(lái)大量維護(hù)成本料皇。
這個(gè)時(shí)期，為了提高可維護(hù)性簸淀，可以通過(guò)下面的方式實(shí)現(xiàn)前端的組件化：
2
理論上瓶蝴，如果大家都能按照最佳實(shí)踐去書寫代碼，那么無(wú)論是 JSP 還是 PHP租幕，可維護(hù)性都不會(huì)差舷手。但可維護(hù)性更多是工程含義，有時(shí)候需要通過(guò)限制帶來(lái)自由劲绪，需要某種約定男窟，使得即便是新手也不會(huì)寫出太糟糕的代碼。
如何讓前后端分工更合理高效贾富，如何提高代碼的可維護(hù)性歉眷，在 Web 開(kāi)發(fā)中很重要。下面我們繼續(xù)來(lái)看颤枪，技術(shù)架構(gòu)的演變?nèi)绾谓鉀Q這兩個(gè)問(wèn)題汗捡。
二、后端為主的 MVC 時(shí)代
為了降低復(fù)雜度畏纲，以后端為出發(fā)點(diǎn)扇住，有了 Web Server 層的架構(gòu)升級(jí)春缕，比如 Structs、Spring MVC 等艘蹋，這是后端的 MVC 時(shí)代锄贼。
代碼可維護(hù)性得到明顯好轉(zhuǎn)，MVC 是個(gè)非常好的協(xié)作模式女阀，從架構(gòu)層面讓開(kāi)發(fā)者懂得什么代碼應(yīng)該寫在什么地方宅荤。為了讓 View 層更簡(jiǎn)單干脆，還可以選擇 Velocity浸策、Freemaker 等模板冯键，使得模板里寫不了 Java 代碼〉拈唬看起來(lái)是功能變?nèi)趿饲砹耍沁@種限制使得前后端分工更清晰。然而依舊并不是那么清晰夫晌，這個(gè)階段的典型問(wèn)題是：
- 1、前端開(kāi)發(fā)重度依賴開(kāi)發(fā)環(huán)境昧诱。這種架構(gòu)下晓淀，前后端協(xié)作有兩種模式：一種是前端寫 demo，寫好后盏档，讓后端去套模板凶掰。淘寶早期包括現(xiàn)在依舊有大量業(yè)務(wù)線是這種模式。好處很明顯蜈亩，demo 可以本地開(kāi)發(fā)懦窘，很高效。不足是還需要后端套模板稚配，有可能套錯(cuò)畅涂，套完后還需要前端確定，來(lái)回溝通調(diào)整的成本比較大道川。另一種協(xié)作模式是前端負(fù)責(zé)瀏覽器端的所有開(kāi)發(fā)和服務(wù)器端的 View 層模板開(kāi)發(fā)午衰，支付寶是這種模式。好處是 UI 相關(guān)的代碼都是前端去寫就好冒萄，后端不用太關(guān)注臊岸，不足就是前端開(kāi)發(fā)重度綁定后端環(huán)境，環(huán)境成為影響前端開(kāi)發(fā)效率的重要因素尊流。
- 2帅戒、前后端職責(zé)依舊糾纏不清。Velocity 模板還是蠻強(qiáng)大的崖技，變量逻住、邏輯钟哥、宏等特性，依舊可以通過(guò)拿到的上下文變量來(lái)實(shí)現(xiàn)各種業(yè)務(wù)邏輯鄙信。這樣瞪醋，只要前端弱勢(shì)一點(diǎn)，往往就會(huì)被后端要求在模板層寫出不少業(yè)務(wù)代碼装诡。還有一個(gè)很大的灰色地帶是 Controller银受，頁(yè)面路由等功能本應(yīng)該是前端最關(guān)注的，但卻是由后端來(lái)實(shí)現(xiàn)鸦采。Controller 本身與 Model 往往也會(huì)糾纏不清宾巍，看了讓人咬牙的代碼經(jīng)常會(huì)出現(xiàn)在 Controller 層。這些問(wèn)題不能全歸結(jié)于程序員的素養(yǎng)渔伯，否則 JSP 就夠了顶霞。
經(jīng)常會(huì)有人吐槽 Java，但 Java 在工程化開(kāi)發(fā)方面真的做了大量思考和架構(gòu)嘗試锣吼。Java 蠻符合馬云的一句話：讓平凡人做非凡事选浑。
三、Ajax 帶來(lái)的 SPA 時(shí)代
歷史滾滾往前玄叠，2004 年 Gmail 像風(fēng)一樣的女子來(lái)到人間古徒，很快 2005 年 Ajax 正式提出，加上 CDN 開(kāi)始大量用于靜態(tài)資源存儲(chǔ)读恃，于是出現(xiàn)了 JavaScript 王者歸來(lái)的 SPA （Single Page Application 單頁(yè)面應(yīng)用）時(shí)代隧膘。
這種模式下，前后端的分工非常清晰寺惫，前后端的關(guān)鍵協(xié)作點(diǎn)是 Ajax 接口疹吃。看起來(lái)是如此美妙西雀，但回過(guò)頭來(lái)看看的話萨驶，這與 JSP 時(shí)代區(qū)別不大。復(fù)雜度從服務(wù)端的 JSP 里移到了瀏覽器的 JavaScript蒋搜，瀏覽器端變得很復(fù)雜篡撵。類似 Spring MVC，這個(gè)時(shí)代開(kāi)始出現(xiàn)瀏覽器端的分層架構(gòu)：
5
對(duì)于 SPA 應(yīng)用豆挽，有幾個(gè)很重要的挑戰(zhàn)：
- 1育谬、前后端接口的約定。如果后端的接口一塌糊涂帮哈，如果后端的業(yè)務(wù)模型不夠穩(wěn)定膛檀，那么前端開(kāi)發(fā)會(huì)很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來(lái)約定和沉淀接口，在阿里咖刃，不少團(tuán)隊(duì)也有類似嘗試泳炉，通過(guò)接口規(guī)則、接口平臺(tái)等方式來(lái)做嚎杨。有了和后端一起沉淀的接口規(guī)則花鹅，還可以用來(lái)模擬數(shù)據(jù)，使得前后端可以在約定接口后實(shí)現(xiàn)高效并行開(kāi)發(fā)枫浙。相信這一塊會(huì)越做越好刨肃。
- 2、前端開(kāi)發(fā)的復(fù)雜度控制箩帚。SPA 應(yīng)用大多以功能交互型為主真友，JavaScript 代碼過(guò)十萬(wàn)行很正常。大量 JS 代碼的組織紧帕，與 View 層的綁定等盔然，都不是容易的事情。典型的解決方案是業(yè)界的 Backbone是嗜，但 Backbone 做的事還很有限愈案，依舊存在大量空白區(qū)域需要挑戰(zhàn)。
SPA 讓前端看到了一絲綠色鹅搪，但依舊是在荒漠中行走刻帚。
四、前端為主的 MV* 時(shí)代
為了降低前端開(kāi)發(fā)復(fù)雜度涩嚣，除了 Backbone，還有大量框架涌現(xiàn)掂僵，比如 EmberJS航厚、KnockoutJS、AngularJS 等等锰蓬。這些框架總的原則是先按類型分層幔睬，比如 Templates、Controllers芹扭、Models麻顶，然后再在層內(nèi)做切分，如下圖：
好處很明顯：
- 1舱卡、前后端職責(zé)很清晰辅肾。前端工作在瀏覽器端，后端工作在服務(wù)端轮锥。清晰的分工矫钓，可以讓開(kāi)發(fā)并行，測(cè)試數(shù)據(jù)的模擬不難，前端可以本地開(kāi)發(fā)新娜。后端則可以專注于業(yè)務(wù)邏輯的處理赵辕，輸出 RESTful 等接口。
- 2概龄、前端開(kāi)發(fā)的復(fù)雜度可控还惠。前端代碼很重，但合理的分層私杜，讓前端代碼能各司其職蚕键。這一塊蠻有意思的，簡(jiǎn)單如模板特性的選擇歪今，就有很多很多講究嚎幸。并非越強(qiáng)大越好，限制什么寄猩，留下哪些自由嫉晶，代碼應(yīng)該如何組織，所有這一切設(shè)計(jì)田篇，得花一本的厚度去說(shuō)明替废。
- 3、部署相對(duì)獨(dú)立泊柬，產(chǎn)品體驗(yàn)可以快速改進(jìn)椎镣。
但依舊有不足之處：
- 1、代碼不能復(fù)用兽赁。比如后端依舊需要對(duì)數(shù)據(jù)做各種校驗(yàn)状答，校驗(yàn)邏輯無(wú)法復(fù)用瀏覽器端的代碼。如果可以復(fù)用刀崖，那么后端的數(shù)據(jù)校驗(yàn)可以相對(duì)簡(jiǎn)單化惊科。2、全異步亮钦，對(duì) SEO 不利馆截。往往還需要服務(wù)端做同步渲染的降級(jí)方案。3蜂莉、性能并非最佳蜡娶，特別是移動(dòng)互聯(lián)網(wǎng)環(huán)境下。4映穗、SPA 不能滿足所有需求窖张，依舊存在大量多頁(yè)面應(yīng)用。URL Design 需要后端配合男公，前端無(wú)法完全掌控荤堪。
五合陵、Node 帶來(lái)的全棧時(shí)代(前后端分離)
前端為主的 MV* 模式解決了很多很多問(wèn)題，但如上所述澄阳，依舊存在不少不足之處拥知。隨著 Node.js 的興起，JavaScript 開(kāi)始有能力運(yùn)行在服務(wù)端碎赢。這意味著可以有一種新的研發(fā)模式：
在這種研發(fā)模式下低剔，前后端的職責(zé)很清晰。對(duì)前端來(lái)說(shuō)肮塞，兩個(gè) UI 層各司其職：
- 1襟齿、Front-end UI layer 處理瀏覽器層的展現(xiàn)邏輯。通過(guò) CSS 渲染樣式枕赵，通過(guò) JavaScript 添加交互功能猜欺，HTML 的生成也可以放在這層，具體看應(yīng)用場(chǎng)景拷窜。
- 2开皿、Back-end UI layer 處理路由、模板篮昧、數(shù)據(jù)獲取赋荆、cookie 等。通過(guò)路由懊昨，前端終于可以自主把控 URL Design窄潭，這樣無(wú)論是單頁(yè)面應(yīng)用還是多頁(yè)面應(yīng)用，前端都可以自由調(diào)控酵颁。后端也終于可以擺脫對(duì)展現(xiàn)的強(qiáng)關(guān)注嫉你，轉(zhuǎn)而可以專心于業(yè)務(wù)邏輯層的開(kāi)發(fā)。
通過(guò) Node躏惋，Web Server 層也是 JavaScript 代碼均抽，這意味著部分代碼可前后復(fù)用，需要 SEO 的場(chǎng)景可以在服務(wù)端同步渲染其掂，由于異步請(qǐng)求太多導(dǎo)致的性能問(wèn)題也可以通過(guò)服務(wù)端來(lái)緩解。前一種模式的不足潦蝇，通過(guò)這種模式幾乎都能完美解決掉款熬。
與 JSP 模式相比，全棧模式看起來(lái)是一種回歸攘乒，也的確是一種向原始開(kāi)發(fā)模式的回歸贤牛，不過(guò)是一種螺旋上升式的回歸。
基于 Node 的全棧模式则酝，依舊面臨很多挑戰(zhàn)：
- 1殉簸、需要前端對(duì)服務(wù)端編程有更進(jìn)一步的認(rèn)識(shí)闰集。比如 network/tcp、PE 等知識(shí)的掌握般卑。
- 2武鲁、Node 層與 Java 層的高效通信。Node 模式下蝠检，都在服務(wù)器端沐鼠，RESTful HTTP 通信未必高效，通過(guò) SOAP 等方式通信更高效叹谁。一切需要在驗(yàn)證中前行饲梭。- 3、對(duì)部署焰檩、運(yùn)維層面的熟練了解憔涉，需要更多知識(shí)點(diǎn)和實(shí)操經(jīng)驗(yàn)。4析苫、大量歷史遺留問(wèn)題如何過(guò)渡兜叨。這可能是最大最大的阻力。
