移動(dòng)互聯(lián)網(wǎng)的迅猛發(fā)展讓移動(dòng)APP呈現(xiàn)出爆發(fā)之勢(shì)，這兩年更是移動(dòng)開(kāi)發(fā)程序員的春天。
今天的互聯(lián)網(wǎng)上充斥著產(chǎn)品與技術(shù)的撕逼。也許你會(huì)問(wèn)產(chǎn)品經(jīng)理到底要不要懂技術(shù)？由此引申出，產(chǎn)品經(jīng)理到底要不要懂設(shè)計(jì)？產(chǎn)品經(jīng)理到底要不要懂運(yùn)營(yíng)？產(chǎn)品經(jīng)理到底要不要懂市場(chǎng)？產(chǎn)品經(jīng)理到底要不要懂業(yè)務(wù)？這所有問(wèn)題的來(lái)源都是大家對(duì)于產(chǎn)品經(jīng)理的工作認(rèn)識(shí)不一致。
每個(gè)人心中都有一個(gè)產(chǎn)品經(jīng)理的定義，產(chǎn)品經(jīng)理在技術(shù)方面更多的是去統(tǒng)籌和規(guī)劃。不是畫(huà)畫(huà)圖寫(xiě)寫(xiě)文檔就可以了。這里面更多的需要的是對(duì)邏輯的梳理和拆分。
例如很簡(jiǎn)單的一個(gè)app內(nèi)嵌發(fā)紅包的活動(dòng)，產(chǎn)品經(jīng)理需要確定整個(gè)活動(dòng)的流程。從用戶(hù)進(jìn)入頁(yè)面的那一瞬間就應(yīng)該被產(chǎn)品經(jīng)理掌控。他的每一個(gè)步驟，每一個(gè)操作會(huì)帶來(lái)什么結(jié)果，有哪些變量會(huì)導(dǎo)致活動(dòng)進(jìn)程失敗，這些都要產(chǎn)品去考慮。等到活動(dòng)邏輯和過(guò)程全部梳理完成，下面就要進(jìn)行拆分了。還是以發(fā)紅包為例，紅包中金額是客戶(hù)端寫(xiě)死還是服務(wù)端進(jìn)行計(jì)算，紅包領(lǐng)取資格需要服務(wù)端返回幾種結(jié)果，每種結(jié)果對(duì)應(yīng)客戶(hù)端的提示是什么，用戶(hù)領(lǐng)取紅包以后服務(wù)端需要記錄那些信息（帳號(hào)，uid，領(lǐng)取時(shí)間，金額，是否使用等），客戶(hù)端哪些地方需要加入計(jì)數(shù)器進(jìn)行數(shù)據(jù)統(tǒng)計(jì)?？偨Y(jié)起來(lái)其實(shí)就是，產(chǎn)品經(jīng)理需要根據(jù)開(kāi)發(fā)的每一個(gè)環(huán)節(jié)，將所有內(nèi)容分類(lèi)整理，并分發(fā)給不同部分的開(kāi)發(fā)進(jìn)行研發(fā)。最后，還需要給測(cè)試準(zhǔn)備好check list，當(dāng)測(cè)試按照check list測(cè)試完成以后，才可以上線。
以上種種都需要產(chǎn)品對(duì)前端如何顯示后端數(shù)據(jù)有一個(gè)清晰的認(rèn)識(shí)才能規(guī)劃好數(shù)據(jù)如何展示。是APP寫(xiě)死呢還是后臺(tái)返回，在用戶(hù)任務(wù)進(jìn)行的時(shí)候有哪些可能case。只有搞清楚這些，產(chǎn)品才能在實(shí)際的開(kāi)發(fā)中掌握好整個(gè)項(xiàng)目的流程與進(jìn)展，才能不被開(kāi)發(fā)給糊弄。
1.前后端到底在干些什么
簡(jiǎn)單的說(shuō)，前端僅僅將后端返回的數(shù)據(jù)展示在頁(yè)面上，不做過(guò)多的邏輯處理。前端需要關(guān)心的是，數(shù)據(jù)如何更好的展示出來(lái)，頁(yè)面效果如何做出來(lái)，以及其性能問(wèn)題。
而后端就是負(fù)責(zé)對(duì)這些數(shù)據(jù)進(jìn)行處理，提供給前端展示。
前端一般有H5、android、ios等多端界面。數(shù)據(jù)不要輕易寫(xiě)死在前端里面，不然到時(shí)候三端都要修改，費(fèi)時(shí)費(fèi)力。而將這些變化多數(shù)據(jù)讓后端進(jìn)行處理，前端將這個(gè)數(shù)據(jù)取出來(lái)顯示出來(lái)就行了。
舉個(gè)例子吧，下圖是一個(gè)美團(tuán)app首頁(yè)團(tuán)購(gòu)的展示效果
上方美食等8個(gè)icon一般為固定展示欄目，非特殊情況不會(huì)修改。那么前端一般是寫(xiě)死在app中，等到需要更新的時(shí)候更新app即可。
而下方猜你喜歡是一個(gè)列表，該列表數(shù)據(jù)經(jīng)常變化，數(shù)據(jù)寫(xiě)在服務(wù)端維護(hù)，app取出數(shù)據(jù)進(jìn)行展示即可。
2.前端到底是怎么顯示數(shù)據(jù)的
首先，前段對(duì)頁(yè)面的展示是分兩步走的。
第一、在本地繪制好界面，當(dāng)然此時(shí)未連api會(huì)填充一些假數(shù)據(jù)，或?qū)懸恍┠J(rèn)值。
第二、連api進(jìn)行數(shù)據(jù)獲取，將數(shù)據(jù)填充進(jìn)界面。
既然如此，咱們簡(jiǎn)單看下前端拿到的數(shù)據(jù)到底長(zhǎng)什么樣的吧。
現(xiàn)在前端獲取到的數(shù)據(jù)基本是json數(shù)據(jù)。
- 何謂json數(shù)據(jù)
JSON是一種傳遞對(duì)象的語(yǔ)法，對(duì)象可以是name/value對(duì)，數(shù)組和其他對(duì)象。
拿剛才美團(tuán)截圖里面的猜你喜歡列表簡(jiǎn)單說(shuō)下吧，如下面這一坨東西就是后端可能返回給前端的數(shù)據(jù)
{
"list": [
{
"title": "合輯護(hù)甲",
"content": "【北京市】奧斯卡貨到付款..."
"price": 12.9
"distance": "145.0km"
},
{
"title": "合輯護(hù)甲",
"content": "【北京市】奧斯卡貨到付款..."
"price": 12.9
"distance": "145.0km"
}
]
}
不需要特別懂里面每一個(gè)的含義，只需要知道，前端通過(guò)"title"這個(gè)鍵名(key)就可以拿到"合輯護(hù)甲"這個(gè)值(value)。"title": "合輯護(hù)甲" 這一整個(gè)就是俗稱(chēng)的一個(gè)字段。通過(guò)該字段前端就可以獲取到列表的標(biāo)題了。當(dāng)然這個(gè)列表只是簡(jiǎn)單的展示用，還有諸如圖片地址、優(yōu)惠信息、已售份額等信息沒(méi)有提供，這就是缺少字段的情況。
前后端就是通過(guò)這樣的一個(gè)定義獲取/傳遞數(shù)據(jù)的。
3.什么樣的數(shù)據(jù)該由前端來(lái)控制，什么樣的數(shù)據(jù)該由后端提供呢
考慮到后期拓展、需求變更等，一般來(lái)說(shuō)，涉及到計(jì)算的、可能有變動(dòng)的，一律不要讓前端來(lái)弄。
還是剛才那個(gè)例子，在剛才那個(gè)列表中有一個(gè)“立減5元”的橙黃色tag。
這個(gè)tag信息，如果考慮不充分，比如說(shuō)，后端只提供一個(gè)數(shù)字5，然后前端在其頁(yè)面寫(xiě)死“立減x元”，x為填入后端提供的數(shù)字，顏色固定為橙黃色。這個(gè)如果需求不修改還好，如果后期需要新增一個(gè)“滿20減5元”的紅色tag不傻眼了嗎？
到時(shí)候只能通過(guò)升級(jí)app來(lái)解決，而且不升級(jí)的老用戶(hù)將永遠(yuǎn)看不到這個(gè)紅色的tag。
所以說(shuō)，考慮到程序的可復(fù)用和拓展性，需要產(chǎn)品將后期可能新增或變更的需求考慮好，和前后端進(jìn)行溝通，讓前后端設(shè)計(jì)好實(shí)現(xiàn)，盡量降低程序的耦合和硬編碼。這才能使一個(gè)產(chǎn)品更加健壯以及讓苦逼的程序猿少加班的關(guān)鍵。
那么剛才那個(gè)tag的需求如何設(shè)計(jì)才合理呢？
首先是tag顯示文字，全權(quán)由后端提供，可以是多個(gè)字段，由前端進(jìn)行拼接。然后是tag的顏色，提供幾種樣式讓前端判斷是一種可行的辦法，但是直接提供tag的色值給前端的這種方式無(wú)疑給前端展示增加了無(wú)限的可能。
是不是也要增加一個(gè)tag形狀的字段呢？
俗話說(shuō)，過(guò)猶不及。tag形狀這種東西真的很少變更，字段太多無(wú)疑會(huì)增加開(kāi)發(fā)的時(shí)間成本，而且會(huì)讓人有一種舍本逐末之感。
4.前端數(shù)據(jù)刷新時(shí)機(jī)問(wèn)題
前端獲取到后端數(shù)據(jù)后，如果前端不主動(dòng)刷新重新請(qǐng)求數(shù)據(jù)的話，這個(gè)頁(yè)面的數(shù)據(jù)在該頁(yè)面銷(xiāo)毀前會(huì)一直保持不變。
如何理解？
首先，第一次進(jìn)入一個(gè)頁(yè)面，該頁(yè)面數(shù)據(jù)為空或默認(rèn)數(shù)據(jù)。此時(shí)前端會(huì)鏈接api請(qǐng)求數(shù)據(jù)。數(shù)據(jù)請(qǐng)求完成后，填充進(jìn)頁(yè)面。那么本次聯(lián)網(wǎng)請(qǐng)求就完成了，在前端不進(jìn)行二次數(shù)據(jù)請(qǐng)求之前，該頁(yè)面會(huì)一直保持本次請(qǐng)求的數(shù)據(jù)。也就是說(shuō)，就算服務(wù)端修改了數(shù)據(jù)，前端此時(shí)是不能事實(shí)的進(jìn)行更新的，因?yàn)槲仪岸瞬恢滥銛?shù)據(jù)更新了。
那么在這個(gè)需要實(shí)時(shí)更新頁(yè)面數(shù)據(jù)的時(shí)候和前端講這種需求會(huì)被前端直接回絕：“做不了”。這個(gè)時(shí)候產(chǎn)品咋辦，怪怪妥協(xié)？最后背鍋的還是自己，而且自己也不知道是真做不了還是假做不了。
實(shí)時(shí)刷新也不是不能做，只是做的成本略高，需要和后端進(jìn)行配合，像微信聊天一樣和后端進(jìn)行長(zhǎng)連接(socket)，這樣服務(wù)端數(shù)據(jù)變更前端就知道數(shù)據(jù)變更了。
當(dāng)然如果稍懂頁(yè)面刷新機(jī)制的話，可以要求前端在適當(dāng)?shù)臅r(shí)機(jī)進(jìn)行頁(yè)面刷新，如在頁(yè)面可見(jiàn)的時(shí)候進(jìn)行刷新，這樣用戶(hù)每次看到的都是最新的數(shù)據(jù)。也可以讓用戶(hù)主動(dòng)刷新，如新增刷新功能。
5.One more thing
產(chǎn)品懂技術(shù)這件事情，不僅會(huì)降低和開(kāi)發(fā)同學(xué)溝通時(shí)的難度和被歧視風(fēng)險(xiǎn)，還會(huì)提升在面對(duì)開(kāi)發(fā)同學(xué)意見(jiàn)時(shí)的判斷力，會(huì)降低被技術(shù)團(tuán)隊(duì)忽悠的幾率。同時(shí)，在需要向上級(jí)解釋技術(shù)原因?qū)е伦兏那闆r下，也會(huì)有助于說(shuō)服老板。
“聞道有先后，術(shù)業(yè)有專(zhuān)攻”，要相信自己所接觸的開(kāi)發(fā)團(tuán)隊(duì)是專(zhuān)業(yè)的，靠譜的，相信開(kāi)發(fā)團(tuán)隊(duì)為實(shí)現(xiàn)需求所做出的技術(shù)方案是合理的，最優(yōu)的。如果有質(zhì)疑，可以加深溝通，以合適的方式提出自己的質(zhì)疑。這里要補(bǔ)充一句的是，這個(gè)信任過(guò)程是需要建立的，也是會(huì)根據(jù)團(tuán)隊(duì)的表現(xiàn)不斷變化的；同理，其實(shí)團(tuán)隊(duì)對(duì)于產(chǎn)品經(jīng)理的信任度也是一樣的情況。
吐槽是沒(méi)有意義的，關(guān)鍵還是要解決問(wèn)題。如果覺(jué)得產(chǎn)品經(jīng)理不靠譜，那么有沒(méi)有進(jìn)行過(guò)深入的溝通？如果覺(jué)得開(kāi)發(fā)不好溝通，那么有沒(méi)有進(jìn)行過(guò)了解，不好溝通的原因在哪里？如果當(dāng)事人本身確實(shí)不可溝通，那么有沒(méi)有考慮和對(duì)方的老板溝通，或者通過(guò)自己的老板如實(shí)反映情況？吐槽是最容易的，解決問(wèn)題反而會(huì)很難。
文章作者: chengww
文章鏈接: https://chengww.com/archives/How_does_the_front_end_display_the_back-end_data.html
版權(quán)聲明: 本博客所有文章除特別聲明外，均采用 CC BY-NC-SA 4.0 許可協(xié)議。轉(zhuǎn)載請(qǐng)注明來(lái)自 chengww's blog！
