計算器是我們熟知的一個工具，基本上它是以單機的形式存在的，但它的每一次更新都基本在重繪 UI 界面，把所有代碼放在一起，處理維護很麻煩。有沒有辦法將界面代碼和后臺代碼分開？本文就計算器的處理邏輯，探討前后端分離，一起來看看吧。

作為一名剛?cè)腴T的產(chǎn)品經(jīng)理，在熟練掌握了畫原型、寫文檔、繪制流程圖等技能后，信心滿滿地踏入職場，結(jié)果在開始參與項目時就遇到了職場生涯的第一個檻，就是發(fā)現(xiàn)有一堆崗位的人需要跟自己協(xié)作，而自己卻完全弄不清楚他們到底是干什么的，在項目中究竟扮演什么樣的角色，其中最為頭疼的，就是明明都是開發(fā)，怎么還分了前端和后端。

計算器，無論是手機上、電腦上還是日常生活中都能見到，所以相信以此來舉例，應該能夠讓你更加容易理解，本文就從計算器說起，談一談產(chǎn)品經(jīng)理應該搞清楚的前后端分離。

這是我們經(jīng)常見到的計算器的樣子，基本上它都是以單機的形式存在，也就是說，它在沒有網(wǎng)絡(luò)的情況下，也可以正常使用。

這種形式像極了開發(fā)模式最初的樣子，所有代碼都在一個項目里，開發(fā)既要寫界面和交互，又要寫處理邏輯，那時候還沒有前端和后端的叫法。

后來做著做著，大家就發(fā)覺，計算器的處理邏輯就那樣子，除非數(shù)學不存在了，否則幾乎是永恒不變的，每一次更新，基本都是在重繪 UI 界面（軟件升級，以換 UI 為本），但是所有代碼放在一起，每次維護起來都很麻煩。

于是大家就想著，能不能把界面代碼和后臺代碼分開，互不干擾，界面負責接收和顯示數(shù)據(jù)，后臺負責處理邏輯。

問題是，代碼分開了，相互之間怎么通信？API 讓這個邏輯成為可能，按照新的邏輯，產(chǎn)品的架構(gòu)變成了這樣：

從此，軟件開發(fā)有了前后端的概念，前端只負責寫界面和交互，后端只負責寫處理邏輯，兩者通過 API 接口進行通信。

比如在計算器這個項目中，前端只需要負責把計算器的界面畫出來，并實現(xiàn)相應的交互，比如用戶可以點擊按鍵輸入數(shù)字，符號，可以刪除和清空輸入，當用戶輸入完成按下“=”之后，前端就不管計算了，而是直接通過 API 接口將用戶輸入的內(nèi)容傳給后端，前端不用理會后端怎么計算，只知道過一會后端會把計算結(jié)果傳回來，到時候前端只需要把結(jié)果顯示給用戶就可以了。

而后端，只管對前端傳過來的內(nèi)容進行計算，然后把計算結(jié)果通過 API 接口傳回給前端就可以了，至于前端怎么顯示給用戶，后端也無需理會。

按照以上邏輯，當用戶通過計算器計算“1+1”的整個處理過程是這樣的：

前后端分離之后，會遇到一個新問題，就是誰來做驗證。比如“0不能做除數(shù)”，當用戶輸入了以0作為除數(shù)的公式時，究竟是前端來做驗證還是后端來做驗證。其基本原則是：前端能做驗證盡量做驗證，后端一定要做驗證。

之所以要求后端一定要做驗證，是因為后端主要負責邏輯的處理，如果沒有對數(shù)據(jù)進行驗證，則處理過程可能出錯，或者處理后輸出的結(jié)果是不符合預期的。

而要求前端盡量做驗證，是因為在前端能夠發(fā)現(xiàn)數(shù)據(jù)有問題，驗證不通過的情況下，可以不調(diào)用 API 接口，避免將錯誤的數(shù)據(jù)傳輸給后臺，由于每次調(diào)用 API 都要消耗網(wǎng)絡(luò)資源，前端校驗可以有效減少錯誤的請求次數(shù)，避免資源的浪費。

前后端的分離，除了有更好維護的優(yōu)勢以外，還有另外一個好處，就是能夠避免“重復造輪子”。

這是開發(fā)界廣為流傳的一句話，說的是在不同的產(chǎn)品中重復寫一些相同的功能代碼。比如現(xiàn)在有幾個手機廠商，每個手機廠商都來找你開發(fā)一個計算器的 APP，每個廠商的計算器除了 UI 界面不一樣，功能都是一樣的。

剛剛說過，除非數(shù)學不存在了，否則計算器的計算邏輯是不會變的，無論你用哪個計算器，“1+1”的計算結(jié)果都是等于“2”。但在上面提到的這種情況下，你除了得為每一個廠商開發(fā)不同的前端界面，還要給每個應用寫相同的計算代碼，這就是所謂的“重復造輪子”，明明是相同的功能，為什么要一遍又一遍重復地寫。

但如果我們用前后端分離的設(shè)計模式，我們可以先為每個廠商設(shè)計好計算器的前端界面，接著將計算邏輯的代碼放到服務(wù)器上，然后讓每個計算器將需要計算的內(nèi)容發(fā)到這臺服務(wù)器上，服務(wù)器再返回計算結(jié)果，整個架構(gòu)就變成這樣：

這樣的好處是，相同的代碼只需要寫一套，同時，維護也更加方便，如果出現(xiàn)了 bug 需要修復，比如原本“0不能做除數(shù)”的錯誤提示文案寫成了“0不能做被除數(shù)”，只需要更新服務(wù)端的代碼，幾個計算器收到的提示內(nèi)容就會同步更新成正確的文案。

這個時候你肯定會想到另外一個問題，就是這種設(shè)計模式在現(xiàn)實中是行不通的，手機廠商不會同意與其他的廠商共用代碼，而且將計算器的計算處理放在云端，一旦服務(wù)器出問題，計算器就“掛了”。

這個時候，又出現(xiàn)了另外一種解決方案，叫做 SDK。按以上的例子來理解，就是將服務(wù)器上用于處理計算器計算邏輯的代碼打成一個包，這個包就叫 SDK 包，然后把這個包發(fā)給每個廠商，每個廠商再將 SDK 包集成到自己的計算器應用里，集成的邏輯是這樣的：

而從每個計算器運作的角度來看，計算器應用和 SDK 包之間還是通過 API 來調(diào)用，但是無需經(jīng)過網(wǎng)絡(luò)，在本地就能完成計算的處理，其邏輯是這樣的：

可以看到，雖然所有計算器用的是同一套計算邏輯，但是都在自己內(nèi)部獨立處理，互不干擾。你會發(fā)現(xiàn)，折騰了一番，這個計算器又回到我們最開始看到的那個樣子，單機運行，無需聯(lián)網(wǎng)。

這是 SDK 的優(yōu)勢，下一次更新，只需要將最新的功能代碼重新打包，發(fā)給廠商更新即可。不過，這也暴露出 SDK 的缺點，就是如果廠商未能及時集成最新版的 SDK 包，則用戶無法體驗到最新的功能，比如基于安卓的不同國產(chǎn)手機操作系統(tǒng)，安卓底層不一樣就是這個道理，因為如果 SDK 實現(xiàn)的功能比較多，那么集成 SDK 是一項非常大的工程，而且每次集成新的 SDK 都需要進行完整的測試，防止出現(xiàn)兼容性問題。

以上便是本文的全部內(nèi)容，希望對你搞清楚前后端的具體工作有參考價值。

作者注：

軟件開發(fā)模式中的前后端分離本身是一門比較復雜的學問，本文用了一種非技術(shù)出身的產(chǎn)品經(jīng)理比較好理解的形式介紹了前后端分離的基本概念，如果各位有興趣進一步探究，可以在網(wǎng)上搜索“MVC 軟件開發(fā)模式”深入學習。

關(guān)于文中提到的 API 接口文檔知識，有興趣可參閱《新手產(chǎn)品經(jīng)理必學技術(shù)接口文檔知識》