之前一直是獨(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
