小項目需要前后端分離嗎？
有網(wǎng)友提問： 聽說前后端分離是為了讓前端人員專注前端，后端人員專注后端，但如果項目比較簡單，并且總共也就幾個人在開發(fā)，前后端分離還有意義嗎？
今天我們邀請了 4 名淘系技術(shù)的前端以及后端工程師，結(jié)合他們自身在項目操作中的感受，給大家分享一些 他們對于小項目前后端實際體驗的總結(jié) ，希望能夠?qū)δ阌袔椭?/p>
01
淘系技術(shù)部 逆葵
小項目是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當(dāng)前的業(yè)務(wù)需求』。
脫離實際場景談這個問題是沒有意義的，畢竟技術(shù)架構(gòu)的選擇需要服務(wù)于業(yè)務(wù)。
小項目有多小？它的生命周期有多久？是一個只會存在極短時間的臨時系統(tǒng)，還是在可預(yù)見的未來有擴展成大型項目的可能？維護這個小項目的技術(shù)人員有幾個？他們分別是什么技術(shù)工種？這些都是需要考慮在內(nèi)的點。 小項目是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當(dāng)前的業(yè)務(wù)需求』。
我們都知道前后端分離是為了讓技術(shù)人員各司其職，提高效率，在成熟的互聯(lián)網(wǎng)公司也都是這種運作方式。在人手充裕且技術(shù)人員職責(zé)清晰的情況下，無論是考慮開發(fā)效率、系統(tǒng)可維護度還是系統(tǒng)可擴展性，前后端分離顯然都是最合適的選擇。畢竟互聯(lián)網(wǎng)技術(shù)發(fā)展到今天，前后端已經(jīng)不是早期那樣可以一個人一把梭搞定的了，兩種技術(shù)已經(jīng)產(chǎn)生了明顯的鴻溝，前端更關(guān)注交互和體驗，后端更關(guān)注數(shù)據(jù)和并發(fā)。
當(dāng)然，回到背景設(shè)定上來，怎么選擇依然要取決于你的團隊開發(fā)人員的實際情況。比如說，如果開發(fā)人員只有一個 PHP 工程師，而他剛好對現(xiàn)代的前端框架不太熟悉，平時都是開發(fā) PHP 頁面，HTML/PHP/JS 一通雜糅，這個時候強行要求前后端分離顯然并不合理。
不過從上面的舉例描述來看也能發(fā)現(xiàn)，前后端不分離的情況已經(jīng)是比較落后的生產(chǎn)方式了。今天，以筆者的經(jīng)歷來看，哪怕是學(xué)校里的工作室創(chuàng)業(yè)，也都是盡量通過多個技術(shù)工種協(xié)作完成項目。即使一個人身兼數(shù)職開發(fā)，代碼組織方式也基本都是前后端分離的。雖說過度設(shè)計是架構(gòu)中比較忌諱的地方，但是在前后端分離這一點上，已經(jīng)有充足的實踐證明它的優(yōu)越性。
筆者作為前端，接觸到的 Node.js Web 框架都是以前后端分離作為設(shè)計原則之一，甚至前后端不分離的經(jīng)典語言 —— PHP 中最流行的 Web 框架之一 Laravel 也都是推薦使用現(xiàn)代前端框架 Vue.js 來完成頁面開發(fā)的。究其原因，現(xiàn)代前端技術(shù)的復(fù)雜度，從開發(fā)階段的工程架構(gòu)到提升頁面性能的種種優(yōu)化措施，都不太適合再和后端耦合在一起。
所以，我們的結(jié)論依然不變：是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當(dāng)前的業(yè)務(wù)需求』。當(dāng)然，考慮實際情況，前后端分離是更加普適、先進且合理的方式。
多說一句，時下比較流行的云端一體的應(yīng)用開發(fā)方式，看似是和前后端分離背道而馳，實際上核心原則是一致的。借助 Serverless，前端工程師能夠在專注前端 UI 的基礎(chǔ)上，更深入地拿到數(shù)據(jù)的處理權(quán)限，某種程度上來說是更為高效的開發(fā)方式。至于更偏后端的并發(fā)、擴容、服務(wù)器運維等，則交給 Serverless 容器來解決。這也是一種前后端分離的實踐。筆者認(rèn)為，在小項目中，可以大膽嘗試云端一體開發(fā)。
02
淘系技術(shù)部 千滅
可以從用戶 體驗、開發(fā)效率和運維效率三方面來看待前后端是否分離。
我認(rèn)為在絕大部分 場景下，前后端分離優(yōu)于不分離。
接下來我會從三個主要的場景來分 析前后端分離與否：用戶體驗、開發(fā)效率和運維效率。
用戶體驗
如果你正在做一個門店點餐系統(tǒng)，那么用戶對該系統(tǒng)最基本的要求就是界面美觀、加載速度快。對于這種側(cè)重于前端效果的項目，如果使用傳統(tǒng)的前后端一體項目，界面交互方面，除非有專業(yè)的前端程序員，一般的服務(wù)端程序員是無法通過JSP來實現(xiàn)如果復(fù)雜的前端交互邏輯，并且在其中加上豐富的主題和動效的，極大的可能性就是UI畫的是保時捷，開發(fā)出來是夏利。大家可以回憶下10年前的網(wǎng)站風(fēng)格就可以想象了。加載速度方面，因為資源全部放在服務(wù)端，首次加載沒有瀏覽器緩存，需要加載大量的js、css以及靜態(tài)資源，這在今天幾乎是不可接受的，即使將資源放在Ngnix服務(wù)器，也沒辦法做到極致加速。如果使用的前后端分離的開發(fā)模式，前端由前端項目負(fù)責(zé)，界面交互方面，可以直接使用現(xiàn)有的前端腳手架來實現(xiàn)，業(yè)內(nèi)已經(jīng)有專門設(shè)計師設(shè)計的UI框架供選擇，均實現(xiàn)了豐富的動效和復(fù)雜交互，一鍵引入即可。加載速度方面，前端資源單獨發(fā)布部署，可以通過cdn預(yù)熱和極致加速。
如果你正在做一個僅用戶服務(wù)端接口調(diào)用的工具類項目，那用戶對該系統(tǒng)的基本要求就是能看懂、能操作成功即可，對于這種側(cè)重于服務(wù)端結(jié)果的項目，如果功能變化概率較低，完全可以使用前后端一體開發(fā)模式，光速開發(fā)上線！一套系統(tǒng)解決所有問題。
如果項目是側(cè)重前端交互的，那么最好使用前后端分離，如果項目側(cè)重服務(wù)端功能，無復(fù)雜交互，前后端一體速度更快。它的服務(wù)端就是下單支付這種基本邏輯，很明顯，基于傳統(tǒng)前后端一體的JSP模式來實現(xiàn)需要有復(fù)雜交互的前端頁面是很難的，難度一在于頁面開發(fā)，首先開發(fā)html然后由服務(wù)端轉(zhuǎn)化為jsp，實現(xiàn)功能的復(fù)雜度已經(jīng)很高了，美觀程度更無法保證，這對前端有很高的技術(shù)要求。難度二在于流暢性，前后端一體項目加載頁面需要經(jīng)過Nginx打到服務(wù)端，如果首次訪問沒有流量器緩存可能需要多次下載靜態(tài)資源，頁面加載非常的慢，并且服務(wù)端沒辦法解決這個問題。如果選擇前后端分離，前端頁面可以直接使用現(xiàn)有的前端腳手架來實現(xiàn)，各種優(yōu)秀的前端框架已經(jīng)支持了絕大部分的UI組件，集成了動效、樣式和交互，綁定服務(wù)端數(shù)據(jù)集即可。加載速度方面前端的資源可以通過cdn加速，實現(xiàn)急速加載。 當(dāng)然如果你開發(fā)的是內(nèi)部使用的工具類項目，前端邏輯簡單并且變化很少，使用前后端一體效率可能更高。
對于側(cè)重前端效果的項目，建議前后端分離。
-
開發(fā)效率
前后端一體的項目，僅在前端界面交互簡單且變更頻次低的服務(wù)型項目上占有微小優(yōu)勢，因為此類項目核心是服務(wù)，前端僅僅是服務(wù)調(diào)用入口，只是比postman調(diào)用接口稍微產(chǎn)品化一點點的界面而已，不需要投入前端人力，服務(wù)端可以順手開發(fā)，這種場景下使用jsp成本最低，效率最高。
而對于任意一個對前端界面以及交互又要求，并且會長期迭代的項目，不管項目大小，使用前后端分離的效率都要比前后端一體要高，前后端分離可以通過定義服務(wù)接口并行開發(fā)，互不影響，實現(xiàn)雙倍提效。專業(yè)的人做專業(yè)的事，并且專業(yè)的領(lǐng)域有更多專業(yè)的工具，可以達到事半功倍的效果。
前后端一體的適用場景非常有限，任何一個對前端交互有要求的項目，都應(yīng)該采用前后端分離的方式去開發(fā)。
-
運維效率
前后端一體的項目，前后端完全耦合，一次部署可實現(xiàn)前后端同時上線，但是一旦服務(wù)端宕機，前端頁面無法展示，影響全部用戶，而且不管是服務(wù)端還是前端的迭代都需要重新發(fā)布，無法保證前后端互不影響，增大了迭代風(fēng)險。
對于前后端分離項目，前后端由不同的應(yīng)用承載，迭代和發(fā)布都可以獨立進行，實現(xiàn)完全解耦，幾乎沒有依賴，服務(wù)端宕機可以由前端兜底頁面交互降低影響面，單獨運維極大降低迭代風(fēng)險，在前端發(fā)展到如今，運維工具非常完善，成本很低，相對于諸多風(fēng)險，單獨運維帶來的成本增加可以忽略不計。前后端分離在絕大部分場景下的運維效率高于前后端一體。
綜上所述，前后端分離在當(dāng)前的技術(shù)環(huán)境下已經(jīng)是大勢所趨，其在用戶體驗、開發(fā)效率以及運維效率上均領(lǐng)先于前后端一體的方案，在互聯(lián)網(wǎng)技術(shù)深度發(fā)展的今天，行業(yè)對技術(shù)人員的要求從技術(shù)廣度轉(zhuǎn)變?yōu)榧夹g(shù)深度，專業(yè)人做專業(yè)事，所以，即使小項目也依然推薦前后端分離！
03
淘系技術(shù)部 三半
其實真正實踐下 來，分離也很快的，嘗試一下就知道了。
先說 結(jié)論：
基于現(xiàn)有的前后端技術(shù)和運維能力 ，即使是小項目，也建議前后端分離；當(dāng)然 如果說10年前技術(shù)還不成熟，前后端不分離也是項目快速上線的一個比較 好的 手段。
先談下何為小項目
-
開發(fā)周期短的項目（兩天內(nèi)要上線）？
-
維護時間短的項目（這個項目用這次緊急用一下，下次就不用了）？
-
功能簡單的項目（就一個簡單的數(shù)據(jù)庫查詢，未來不會有需求變更）？
核心問題就是小項目的成本對比？
我的觀點：無論項目有多大或者多小，要實現(xiàn)的產(chǎn)品功能肯定是不會變少的，基本的開發(fā)工作量差異并不大，那么就是前后端分離的運維成本對比了，這個如果有運維現(xiàn)身說法更好，按照我的工作經(jīng)驗來看，運維成本也沒太大的差別。
接下來就要談?wù)劮蛛x的優(yōu)點了
-
必須要說到的就是耦合問題；前后端分離天然地把雙方的交互/開發(fā)邊界厘清了，面向json的數(shù)據(jù)對接
-
大大節(jié)省了聯(lián)調(diào)成本，前后端可以并行開發(fā)，問題定位更加快速清晰
-
可維護性更高，也更加方便后期的重構(gòu)
-
可讀性更強等等
這個問題其實挺簡單的，會有人覺得小項目怎么簡單怎么來，而且先入為主的覺得不分離會更快，其實真正實踐下來，分離也很快的，嘗試一下就知道了。
04
淘系技術(shù)部 饕饗
持續(xù)交付且周期越長的項目 ，前后端分離效果越到后期優(yōu)勢越明顯
這個問題往往更多的是看這個項目是否有需要持續(xù)交付目的和開發(fā)周期長短來確定的。持續(xù)交付且周期越長的項目，前后端分離效果越到后期優(yōu)勢越明顯。
通常前端和后端所關(guān)注和解決的問題是不同的，前端關(guān)注的是交互和體驗，輕業(yè)務(wù)關(guān)系，需要有隨時的調(diào)整的交付能力；而后端關(guān)注的是數(shù)據(jù)邏輯，重業(yè)務(wù)邏輯，相對來說穩(wěn)定確定一切。
那么是否需要分離，就要看項目交付要求及頻次，對項目的影響程度來決定。
一般真實的業(yè)務(wù)場景來看，前后端分離開發(fā)通常是屬于較優(yōu)的選擇：
-
可同步開發(fā)，降低交付延期風(fēng)險
-
完全接口化文檔化，減少雙方的理解和溝通成本
-
提前了解到項目的風(fēng)險和難度，有更明確的心理預(yù)期
-
維護，維護，還是維護
對于第一點，在超過1人以上項目，協(xié)助能獲得更多開發(fā)時間，絕對是降低延期風(fēng)險最有效的手段。其二，前后端分離能較好地解決依賴?yán)Ь郑ㄟ^各種工具或者文檔執(zhí)行各自的開發(fā)進度，最重要的是，前后端分離后，采用的技術(shù)在實現(xiàn)和選擇時不被束縛。為后期的維護帶來方便。
結(jié)語
大多數(shù)情況下，前后端分離是更加普適、先進且合理的方式。
分享到微信 
分享到微博
