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

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

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

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

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

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

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

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

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

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

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

按照以上邏輯，當(dāng)用戶通過計(jì)算器計(jì)算“1+1”的整個(gè)處理過程是這樣的：

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

之所以要求后端一定要做驗(yàn)證，是因?yàn)楹蠖酥饕?fù)責(zé)邏輯的處理，如果沒有對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證，則處理過程可能出錯(cuò)，或者處理后輸出的結(jié)果是不符合預(yù)期的。

而要求前端盡量做驗(yàn)證，是因?yàn)樵谇岸四軌虬l(fā)現(xiàn)數(shù)據(jù)有問題，驗(yàn)證不通過的情況下，可以不調(diào)用 API 接口，避免將錯(cuò)誤的數(shù)據(jù)傳輸給后臺(tái)，由于每次調(diào)用 API 都要消耗網(wǎng)絡(luò)資源，前端校驗(yàn)可以有效減少錯(cuò)誤的請(qǐng)求次數(shù)，避免資源的浪費(fèi)。

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

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

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

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

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

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

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

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

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

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

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

作者注：

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

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