話說這天，我們團隊開會討論了一個問題，不，與其說“討論”，不如說“爭吵”更合適。 背景是這樣的： 我們要開發一個 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。 總之就是大廠在創造和使用這些技術，這些技術能解決別人的問題，但是不一定能解決你的問題。 **彼之良藥，汝之砒霜。** 所以我建議：在前後端分離、前端技術選型這種問題上不要盲目跟風，不要覺得跟著網際網路大廠走就一定不會錯。你需要清楚你的專案型別、團隊結構、技術沉澱、開發週期…… 如果你和大廠一樣，不差錢、不缺資源，那沒的說，儘管選最好最貴、對標一線大廠技術棧，甚至是直接從大廠挖人。 如果你是做專案賺辛苦錢，或者自己投資研發產品，在傳統行業、在產業網際網路精耕細作，慢慢摸索培育市場，不在風口不受風投追捧的，那我覺得你需要務實一些。 我建議各位本著務實和誠實的態度、職業精神操守，結合自己公司、團隊、資源、專案、業務需求，選擇最適合自己的技術棧。 希望這篇文章對你幫助，有不同觀點歡迎通過公眾號和我討論。