小專案需要前后端分離嗎？-有解無憂

有網友提問：聽說前后端分離是為了讓前端人員專注前端，后端人員專注后端，但如果專案比較簡單，并且總共也就幾個人在開發，前后端分離還有意義嗎？

今天我們邀請了 4 名淘系技術的前端以及后端工程師，結合他們自身在專案操作中的感受，給大家分享一些他們對于小專案前后端實際體驗的總結，希望能夠對你有幫助，

淘系技術部逆葵

小專案是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當前的業務需求』，

脫離實際場景談這個問題是沒有意義的，畢竟技術架構的選擇需要服務于業務，

小專案有多小？它的生命周期有多久？是一個只會存在極短時間的臨時系統，還是在可預見的未來有擴展成大型專案的可能？維護這個小專案的技術人員有幾個？他們分別是什么技術工種？這些都是需要考慮在內的點，小專案是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當前的業務需求』，

我們都知道前后端分離是為了讓技術人員各司其職，提高效率，在成熟的互聯網公司也都是這種運作方式，在人手充裕且技術人員職責清晰的情況下，無論是考慮開發效率、系統可維護度還是系統可擴展性，前后端分離顯然都是最合適的選擇，畢竟互聯網技術發展到今天，前后端已經不是早期那樣可以一個人一把梭搞定的了，兩種技術已經產生了明顯的鴻溝，前端更關注互動和體驗，后端更關注資料和并發，

當然，回到背景設定上來，怎么選擇依然要取決于你的團隊開發人員的實際情況，比如說，如果開發人員只有一個 PHP 工程師，而他剛好對現代的前端框架不太熟悉，平時都是開發 PHP 頁面，HTML/PHP/JS 一通雜糅，這個時候強行要求前后端分離顯然并不合理，

不過從上面的舉例描述來看也能發現，前后端不分離的情況已經是比較落后的生產方式了，今天，以筆者的經歷來看，哪怕是學校里的作業室創業，也都是盡量通過多個技術工種協作完成專案，即使一個人身兼數職開發，代碼組織方式也基本都是前后端分離的，雖說過度設計是架構中比較忌諱的地方，但是在前后端分離這一點上，已經有充足的實踐證明它的優越性，

筆者作為前端，接觸到的 Node.js Web 框架都是以前后端分離作為設計原則之一，甚至前后端不分離的經典語言 —— PHP 中最流行的 Web 框架之一 Laravel 也都是推薦使用現代前端框架 Vue.js 來完成頁面開發的，究其原因，現代前端技術的復雜度，從開發階段的工程架構到提升頁面性能的種種優化措施，都不太適合再和后端耦合在一起，

所以，我們的結論依然不變：是否需要前后端分離，取決于哪種方式能夠『時間最快、成本最小地完成當前的業務需求』，當然，考慮實際情況，前后端分離是更加普適、先進且合理的方式，

多說一句，時下比較流行的云端一體的應用開發方式，看似是和前后端分離背道而馳，實際上核心原則是一致的，借助 Serverless，前端工程師能夠在專注前端 UI 的基礎上，更深入地拿到資料的處理權限，某種程度上來說是更為高效的開發方式，至于更偏后端的并發、擴容、服務器運維等，則交給 Serverless 容器來解決，這也是一種前后端分離的實踐，筆者認為，在小專案中，可以大膽嘗試云端一體開發，

淘系技術部千滅

可以從用戶體驗、開發效率和運維效率三方面來看待前后端是否分離，

我認為在絕大部分場景下，前后端分離優于不分離，

接下來我會從三個主要的場景來分析前后端分離與否：用戶體驗、開發效率和運維效率，

用戶體驗

如果你正在做一個門店點餐系統，那么用戶對該系統最基本的要求就是界面美觀、加載速度快，對于這種側重于前端效果的專案，如果使用傳統的前后端一體專案，界面互動方面，除非有專業的前端程式員，一般的服務端程式員是無法通過JSP來實作如果復雜的前端互動邏輯，并且在其中加上豐富的主題和動效的，極大的可能性就是UI畫的是保時捷，開發出來是夏利，大家可以回憶下10年前的網站風格就可以想象了，加載速度方面，因為資源全部放在服務端，首次加載沒有瀏覽器快取，需要加載大量的js、css以及靜態資源，這在今天幾乎是不可接受的，即使將資源放在Ngnix服務器，也沒辦法做到極致加速，如果使用的前后端分離的開發模式，前端由前端專案負責，界面互動方面，可以直接使用現有的前端腳手架來實作，業內已經有專門設計師設計的UI框架供選擇，均實作了豐富的動效和復雜互動，一鍵引入即可，加載速度方面，前端資源單獨發布部署，可以通過cdn預熱和極致加速，

如果你正在做一個僅用戶服務端介面呼叫的工具類專案，那用戶對該系統的基本要求就是能看懂、能操作成功即可，對于這種側重于服務端結果的專案，如果功能變化概率較低，完全可以使用前后端一體開發模式，光速開發上線！一套系統解決所有問題，

如果專案是側重前端互動的，那么最好使用前后端分離，如果專案側重服務端功能，無復雜互動，前后端一體速度更快，它的服務端就是下單支付這種基本邏輯，很明顯，基于傳統前后端一體的JSP模式來實作需要有復雜互動的前端頁面是很難的，難度一在于頁面開發，首先開發html然后由服務端轉化為jsp，實作功能的復雜度已經很高了，美觀程度更無法保證，這對前端有很高的技術要求，難度二在于流暢性，前后端一體專案加載頁面需要經過Nginx打到服務端，如果首次訪問沒有流量器快取可能需要多次下載靜態資源，頁面加載非常的慢，并且服務端沒辦法解決這個問題，如果選擇前后端分離，前端頁面可以直接使用現有的前端腳手架來實作，各種優秀的前端框架已經支持了絕大部分的UI組件，集成了動效、樣式和互動，系結服務端資料集即可，加載速度方面前端的資源可以通過cdn加速，實作急速加載，當然如果你開發的是內部使用的工具類專案，前端邏輯簡單并且變化很少，使用前后端一體效率可能更高，

對于側重前端效果的專案，建議前后端分離，

開發效率

前后端一體的專案，僅在前端界面互動簡單且變更頻次低的服務型專案上占有微小優勢，因為此類專案核心是服務，前端僅僅是服務呼叫入口，只是比postman呼叫介面稍微產品化一點點的界面而已，不需要投入前端人力，服務端可以順手開發，這種場景下使用jsp成本最低，效率最高，

而對于任意一個對前端界面以及互動又要求，并且會長期迭代的專案，不管專案大小，使用前后端分離的效率都要比前后端一體要高，前后端分離可以通過定義服務介面并行開發，互不影響，實作雙倍提效，專業的人做專業的事，并且專業的領域有更多專業的工具，可以達到事半功倍的效果，

前后端一體的適用場景非常有限，任何一個對前端互動有要求的專案，都應該采用前后端分離的方式去開發，

運維效率

前后端一體的專案，前后端完全耦合，一次部署可實作前后端同時上線，但是一旦服務端宕機，前端頁面無法展示，影響全部用戶，而且不管是服務端還是前端的迭代都需要重新發布，無法保證前后端互不影響，增大了迭代風險，

對于前后端分離專案，前后端由不同的應用承載，迭代和發布都可以獨立進行，實作完全解耦，幾乎沒有依賴，服務端宕機可以由前端兜底頁面互動降低影響面，單獨運維極大降低迭代風險，在前端發展到如今，運維工具非常完善，成本很低，相對于諸多風險，單獨運維帶來的成本增加可以忽略不計，前后端分離在絕大部分場景下的運維效率高于前后端一體，

綜上所述，前后端分離在當前的技識訓境下已經是大勢所趨，其在用戶體驗、開發效率以及運維效率上均領先于前后端一體的方案，在互聯網技術深度發展的今天，行業對技術人員的要求從技術廣度轉變為技術深度，專業人做專業事，所以，即使小專案也依然推薦前后端分離！

淘系技術部三半