從計算器說起,談一談產品經理應該搞清楚的前后端分離

1 評論 3885 瀏覽 26 收藏 11 分鐘

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

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

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

這是我們經常見到的計算器的樣子,基本上它都是以單機的形式存在,也就是說,它在沒有網絡的情況下,也可以正常使用。

從計算器說起,談一談產品經理應該搞清楚的前后端分離

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

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

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

問題是,代碼分開了,相互之間怎么通信?API 讓這個邏輯成為可能,按照新的邏輯,產品的架構變成了這樣:

從計算器說起,談一談產品經理應該搞清楚的前后端分離

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

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

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

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

從計算器說起,談一談產品經理應該搞清楚的前后端分離

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

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

而要求前端盡量做驗證,是因為在前端能夠發現數據有問題,驗證不通過的情況下,可以不調用 API 接口,避免將錯誤的數據傳輸給后臺,由于每次調用 API 都要消耗網絡資源,前端校驗可以有效減少錯誤的請求次數,避免資源的浪費。

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

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

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

但如果我們用前后端分離的設計模式,我們可以先為每個廠商設計好計算器的前端界面,接著將計算邏輯的代碼放到服務器上,然后讓每個計算器將需要計算的內容發到這臺服務器上,服務器再返回計算結果,整個架構就變成這樣:

從計算器說起,談一談產品經理應該搞清楚的前后端分離

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

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

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

從計算器說起,談一談產品經理應該搞清楚的前后端分離

而從每個計算器運作的角度來看,計算器應用和 SDK 包之間還是通過 API 來調用,但是無需經過網絡,在本地就能完成計算的處理,其邏輯是這樣的:

從計算器說起,談一談產品經理應該搞清楚的前后端分離

可以看到,雖然所有計算器用的是同一套計算邏輯,但是都在自己內部獨立處理,互不干擾。你會發現,折騰了一番,這個計算器又回到我們最開始看到的那個樣子,單機運行,無需聯網。

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

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

作者注:

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

關于文中提到的 API 接口文檔知識,有興趣可參閱《新手產品經理必學技術接口文檔知識

專欄作家

產品錦李,公眾號:產品錦李(ID:IMPM996),人人都是產品經理專欄作家。不務正業的產品經理和他的產品設計。

本文原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 原來SDK的作用是將同一套后端代碼配合不同的前端樣式,打包分給不同廠家使用,換句話說,SDK能提供一部分后端服務,對于不同廠家的需求,能夠使第三方服務繼續提供新增的SDK后端服務,使項目更具有擴展性。感謝作者,我對前后端分離的了解又多了一些!

    來自四川 回復