之前一直是獨(dú)立開發(fā),沒有什么協(xié)作經(jīng)驗(yàn)。這次接了個(gè)項(xiàng)目,主要是做 Web 和微信小程序的后端開發(fā),于是找了一位前端小姐姐合作。
合作了幾個(gè)月,最近前端情緒很糟糕,甚至有點(diǎn)“破防”。今天找我聊了很久,一頓輸出。我舉幾個(gè)例子:
判斷訂單歸屬問題
前端在要判斷某個(gè)訂單是不是“我的訂單”。
我主張:對(duì)比訂單的wechat_id
和全局保存著當(dāng)前登錄用戶id
對(duì)比,相等則是自己的訂單。
但前端覺得這樣處理復(fù)雜,為什么后端不能直接返回一個(gè)字段,比如is_self
,讓她直接用這個(gè)字段判斷。
我覺得,反正前端也需要if is_self
,這和if order.wechat_id == my_id
區(qū)別很大嗎,而當(dāng)前用戶的my_id
是全局信息也很容易獲取。(ps:這里內(nèi)部后臺(tái)不需要擔(dān)心id泄漏問題)審核數(shù)據(jù)對(duì)比問題
有個(gè)場(chǎng)景是審核時(shí)需要顯示數(shù)據(jù)的變更情況。我接口返回了原始數(shù)據(jù)和修改后的數(shù)據(jù)。
我主張:前端需要自己對(duì)比兩者,不相等的就是發(fā)生了變化,然后展示出來。
但前端的訴求是,希望后端直接返回一個(gè)字段,比如has_changes
這種boolean字段表示有變化,同時(shí)再另外加個(gè)字段帶上具體的變更內(nèi)容。也就是說,前端更傾向于后端把所有數(shù)量準(zhǔn)備好,拿到直接渲染。
在講這些具體問題之前,前端還提到我沒有和人協(xié)作的經(jīng)驗(yàn),之前自己開發(fā)習(xí)慣了“隨性”,這導(dǎo)致她在和我合作時(shí)非常不適應(yīng),覺得“和我對(duì)接是最惱火的一次經(jīng)歷”。
她認(rèn)為問題在于我不夠考慮她的開發(fā)習(xí)慣,而她自己和很多后端合作過,沒有遇到類似的問題。她的總結(jié)是:“是我的問題,她沒問題?!?/strong>
我的初衷很簡(jiǎn)單,在不影響數(shù)據(jù)安全性和完整性的前提下,盡量把一部分計(jì)算任務(wù)轉(zhuǎn)移到前端去處理。
后端直接從數(shù)據(jù)庫(kù)處理數(shù)據(jù)直出,少量應(yīng)用層邏輯計(jì)算,這樣能夠更高效地利用后端資源,尤其是內(nèi)存。這種設(shè)計(jì)原則,我在獨(dú)立開發(fā)時(shí)也是這么做的。
前端對(duì)我的做法很不滿意,認(rèn)為不符合她的開發(fā)習(xí)慣,而她的習(xí)慣是后端返回盡量直觀的數(shù)據(jù),讓前端不需要再去判斷或計(jì)算。她覺得,我的處理方式很失敗,完全不如她之前合作的后端。
這讓我有些無所適從:
到底是我的問題,還是我們的協(xié)作方式需要調(diào)整?
后端是否真的應(yīng)該盡量直出數(shù)據(jù),讓前端不需要再計(jì)算?
我甚至不好意思提,后面還有個(gè)更復(fù)雜的功能:數(shù)據(jù)大屏需要連接 WebSocket,前端需要自己在瀏覽器維護(hù)一個(gè)訂單列表,根據(jù)服務(wù)器傳來的碎片數(shù)據(jù)進(jìn)行更新、校驗(yàn) checksum,并自行判斷是否刷新、根據(jù)分類拆分和合并數(shù)據(jù)。
現(xiàn)在我非常困惑,可能是我確實(shí)不太懂協(xié)作,想聽聽一些建議或解決方法
分享來自:
nodeseek