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