開發一個大型後臺管理系統，應該用先後端分離的技術方案嗎？

話說這天，咱們團隊開會討論了一個問題，不，與其說「討論」，不如說「爭吵」更合適。

背景是這樣的：

咱們要開發一個 xxx 後臺管理系統，這個系統業務複雜、功能又多，你們的爭吵集中在「這個系統是否應該用先後端分離的方案」。

此次爭吵的問題比較典型，因而我就寫了這篇文章。爲了你們好理解，把「xxx 後臺管理系統」泛化一下，變成：

開發一個大型後臺管理系統，應該用先後端分離的技術方案嗎？

先說一下，本文中的觀點確定有人不認同，再加上我對前端技術掌握有限，因此你們批判的看吧。

1. 先審題，冷靜的分析一下

先後端分離的優勢多多，這不須要多說，你們人人都清楚。

來，討論以前，咱們先一塊兒好好審審題。

結合「開發一個大型後臺管理系統」這個約束條件，冷靜的分析一下：

• 什麼是後臺管理系統：首前後臺管理系統這個稱呼，意味着這是一個 B 端系統。能夠小到部門級應用（客戶投訴登記系統、辦公設備臺帳系統），大一點能夠是大集團級核心系統（500 強保險公司客服、呼叫中心），能夠是 ERP、CRM、OA（SAP、用友、泛微協同），能夠是一個 B2C 電商的商城後臺、支付網關管理控制檯，能夠是 Saas 的管理後臺（Salesforce、Teambition、Jira），能夠大到阿里雲控制檯……

• 什麼是大型：我理解大型系統是指功能模塊多、交互複雜，而不是訪問量、TPS、數據量大。因此 CMS、OA、ERP、CRM、阿里雲後臺、呼叫中心等各類管理系統，知足功能多、邏輯複雜，基本能夠稱爲大型系統，雖然他們體量和交易量可能不在一個量級。另外大型系統基本等價於「維護週期長，需求不斷變動」，這個在後面維護成本部分闡述。

• 性能考量不是主要決定因素：由於咱們這裏討論的是 B 端系統的前端技術選型，所以個人觀點是性能不是主要考慮因素，由於性能瓶頸每每在後端和數據庫，其次 B 端產品少有爆發性交易量（秒殺 大促 活動），最後 B 端產品不強調首屏渲染速度。

• UI 操做效率是最主要考覈指標：B 端系統產品都是用來幹活兒、管理、生產調度的，操做效率和方便性大於天。屏幕空間要充分利用，減小切換跳轉彈窗；快捷鍵效率遠高於鼠標；SPA 多頁籤佈局有利於保持工做上下文和狀態；必要時能夠鼠標右鍵菜單操做；功能菜單操做提示要清晰易理解，減小培訓麻煩；在此基礎上，儘可能減小每個界面上呈現的信息量，只呈現最少的必要信息，下降用戶認知壓力。

• UI 開發效率高、維護成本低是關鍵考量因素：大型系統基本等價於「維護週期長、需求不斷變動」，所以在技術選型上儘可能要求維護成本低、學習成本低、招聘容易、組件化程度高代碼簡潔……

• UI 顏值美觀度不是關鍵考量方面：界面簡潔大方、圖表豐富、數據展示清晰，這其實自己就是一種美——樸素實用的美。

• 瀏覽器兼容性：這條要看具體狀況——Saas要求兼容性高；內網系統、內部系統能夠要求瀏覽器產品和版本。

2. 亮觀點

基於上述，因此個人觀點就是：

先後端分離對於大部分「大型後臺管理系統」來講弊大於利。

大型後臺管理系統，相對於 C 端產品，B 端產品隱含等價於「業務邏輯複雜」。我不是說 B 端比 C 端產品難作，C 端有另外的難度（好比用戶體驗、好比競品之間的競爭更加激烈、好比並髮量挑戰、好比作活動的需求頻繁……）。

一般來講，複雜業務邏輯的產品須要產品、美工、開發各工種人員，密切配合、快速原型、MVP、快速迭代、快速試錯。所以，由後端工程師全棧開發的效率、效果，要高於先後端分離（這裏說的「效果」指的是趁熱打鐵和技術主觀能動性的效果）。

那種「產品畫框圖、再到作設計稿、再到前端切圖、最後扔給程序員渲染模板」的傳統開發流水線，會完全拖慢一個業務需求從想法到交付的週期，會完全割裂整個團隊，會遺漏大量的上下文信息，會增長巨大溝通成本，會完全磨滅項目成員的參與感和對產品的歸屬感。

畫圖仔、切圖仔和碼農，循序漸進像流水線擰螺絲同樣開發產品，很難建立出一個有靈魂有靈性的產品！

更不用提早後端分離形成的開發、聯調、部署、定接口、維護接口的成本提升。

另外，先後端分離也不適合項目型公司，由於項目週期有限，團隊磨合的時間越少越好。還有，項目交付後，留守的人員配置不齊，致使需求變動和維護問題難以解決。

綜上：先後端分離的開發和部署模式，不太適合「大型後臺管理系統」，緣由 一方面是上面列舉的種種弊端，另外一方面是大型後臺管理系統沒法享受到先後端分離的好處：Nginx 分開部署的優點、專業前端優點（C 端產品追求極致的顏值和用戶體驗）。

既然這麼多弊端，爲何還有不少「大型後臺管理系統」之類的項目，跟風搞先後端分離呢？

答案主要集中在兩類：簡歷驅動的技術選型、盲目跟風。

3. 簡歷驅動的技術選型

軟件開發絕對是個良心活兒，跟醫生、教師同樣的。

我這幾年見到了太多的微型團隊（10人如下）搞微服務架構，以及先後端分離的 CMS 內容管理系統！

見了太多爲了用時髦技術而盲目選型的事情，太多不計後果、不計成本的追求新技術來美化本身簡歷，太多用流行技術名詞忽悠本身不懂技術的老闆、上司的狀況。

大家的良心不會痛嗎？

當你在簡歷上加上了一個個流行技術關鍵詞，而後拍拍屁股離開了一個爛尾的項目、一個預算嚴重超支的項目，讓創業團隊多走幾年彎路甚至夭折，你的良心和職業素養都破產了！

你正在透支技術人這個羣體的社會聲譽。

技術人的天職，本應是把複雜模糊的現實世界問題，建模成清晰邏輯結構化的計算機軟硬件，讓世界變得更簡單高效，若是由於一些奇怪的緣由而把簡單問題複雜化，那就是背離了這個行業的初衷。

但願愈來愈多的甲方、非技術出身的高管們明白一個道理：

靠譜的人是把解決方案作的很簡單以致於明顯沒有問題，不靠譜的人會把解決方案作的毫無必要的複雜以致於短期內看不出明顯的問題。

4. 先後端分離不是壞的，跟風纔是壞的

先後端分離的出現和存在，固然有它的合理性和優點。

這裏插一句，提及先後端分離，必須先介紹一下 Angular、React、Vue，絕對是前端領域的三大當紅花旦。可是這三大花旦，也讓無數碼農陷入選擇困難症，引起了大量無休無止的爭論。不少討論，當事人已經忘記了討論的初衷和邊界，最後陷入無心義的口水戰。

看看誰創造了它們——谷歌的 Angular、Facebook 的 React、阿里的 antd、餓了麼的 element、前谷歌程序員尤雨溪建立的 Vue。

總之就是大廠在創造和使用這些技術，這些技術能解決別人的問題，可是不必定能解決你的問題。

彼之良藥，汝之砒霜。

因此我建議：在先後端分離、前端技術選型這種問題上不要盲目跟風，不要以爲跟着互聯網大廠走就必定不會錯。你須要清楚你的項目類型、團隊結構、技術沉澱、開發週期……

若是你和大廠同樣，不差錢、不缺資源，那沒的說，儘管選最好最貴、對標一線大廠技術棧，甚至是直接從大廠挖人。

若是你是作項目賺辛苦錢，或者本身投資研發產品，在傳統行業、在產業互聯網精耕細做，慢慢摸索培育市場，不在風口不受風投追捧的，那我以爲你須要務實一些。

我建議各位本着務實和誠實的態度、職業精神操守，結合本身公司、團隊、資源、項目、業務需求，選擇最適合本身的技術棧。

但願這篇文章對你幫助，有不一樣觀點歡迎經過公衆號和我討論。