掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
你是否在為如何制定前后端協(xié)作規(guī)范而發(fā)愁？干貨來啦，一文帶你了解我們團隊內(nèi)部沉淀并踐行已久的前后端協(xié)作規(guī)范，讀完本文，回去大膽拒絕你后端的不合理設(shè)計！
成都創(chuàng)新互聯(lián)公司主營涼州網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP軟件開發(fā),涼州h5微信小程序搭建,涼州網(wǎng)站營銷推廣歡迎涼州等地區(qū)企業(yè)咨詢
假如你要在團隊內(nèi)部推一套規(guī)范，那么首先你得知道為什么需要制定協(xié)作規(guī)范呢？有規(guī)范會帶來什么好處呢？
隨著前后端分離開發(fā)模式大行其道，前端和后端已經(jīng)在兩個方向上漸行漸遠，各自深耕細作、術(shù)業(yè)專攻。前端更加關(guān)注交互視覺體驗，而后端對高并發(fā)、高性能、高擴展上要求更高。這就導致大部分的前端和后端之間會存在所謂的"代溝"，我不知道你的數(shù)據(jù)如何存儲，你不知道我的頁面如何渲染。
因此，很有必要制定前后端開發(fā)上的規(guī)范來抹平代溝，有了協(xié)作規(guī)范，便有了前后端開發(fā)默契，也因此達到了提高開發(fā)效率、降低溝通成本的作用。
首先是協(xié)作的流程規(guī)范，相信每個團隊在前后端協(xié)作中都有各自的開發(fā)模式和開發(fā)流程來保障效率和質(zhì)量，我們團隊的前后端協(xié)作大致流程如下圖所示：
以下總結(jié)了我們團隊內(nèi)部在協(xié)作中遇到的比較典型的 Bad Case 以及解決方案，我相信大家在開發(fā)過程中也遇到過類似的痛點經(jīng)歷：
【現(xiàn)象】
// 按鈕文案、顯示邏輯
{((record.state === 'RESULT_CONFIRM' && isCurrentUserCreate) ||(record.state === 'RESULT_CHECK' && isCurrentUserCreate && currentUserCanCheck )) && }
{['DREFT', 'AUDIT_FAILD', 'REVOKE'].includes(record.state) && isCurrentUserCreate && }
// A 場景調(diào)用接口 1，B 場景調(diào)用接口 2，C 場景調(diào)用接口 3 和 4
if (id) {
this.operation = '修改';
const res = await this.fetchInfo(id);
...
} else if (source) {
const res = await this.fetchSourceInfo(id: source);
...
} else {
const res = await this.fetchBasicInfo();
...
}
【解決】
注：如果功能簡單，前端也可以做判斷，如何鑒定是否簡單？從代碼層面比如 If 判斷中超過 2 個條件，按鈕顯示超過 2 個條件，可視作復雜邏輯，邏輯移到后端處理。建議一開始就視作復雜去處理，這樣后期就不用再調(diào)整。
// 按鈕展示
前后端約定好 按鈕的顯示返回一個數(shù)組，數(shù)組具體返回哪些邏輯寫在后端。
[
{ name:'確認'，type:'resultConfirm'},
{ name:'修改'，type:'edit' },
]
【好處】
【現(xiàn)象】
【解決】
1、后端做好數(shù)據(jù)的整合，避免數(shù)據(jù)在前端的重組。
2、Tree 數(shù)據(jù)展示的場景，如果數(shù)據(jù)不大后端全量返回，如果數(shù)據(jù)量過大異步返回，但異步返回存在后續(xù)的回顯和搜索展示方面問題。
3、同一個業(yè)務(wù)功能，一個接口搞定，不要分接口進行，后端業(yè)務(wù)考慮復用可包裝新接口或原接口加參數(shù)兼容。
【好處】
減少前后端數(shù)據(jù)處理的成本，提高性能和用戶體驗
【現(xiàn)象】
// 狀態(tài)值映射
const getStatusName = (status) => {
switch(status) {
case 0:
return '草稿'；
case 1:
return '待部門審批';
case 2:
return '待財務(wù)審核';
case 3:
return '待單位審核';
case 4:
return '審核中';
...
default:
break;
}
}
【解決】
如果是狀態(tài)定死的情況下譬如：選項為【是、否】可無需后端返回。
// 由后端接口返回下拉框選項
{
result: [{
code: string
name: string
}]
}
【好處】
【現(xiàn)象】
【解決】
【好處】
【現(xiàn)象】
【解決】
【現(xiàn)象】
【解決】
【現(xiàn)象】
【解決】
// 入?yún)ⅲ?br> {
code: '99900', // 區(qū)劃代碼
identity: '11111', // 標識碼
datas:[ // 數(shù)據(jù)
{
key: 'catalog',
value: 'A07',
},
{
key: 'assetApproval',
value: 0,
}
]
}
// 返回值：
{
result: true
}【現(xiàn)象】
由于 A 和 B 是不同業(yè)務(wù)線后端，接口對接以及后期的溝通維護成本會比較高。例如該接口發(fā)生改動，需要跨業(yè)務(wù)線通知到對應(yīng)的前端（該后端還不一定知道前端是哪位）；并且接口返回的大量字段前端都用不到。
【解決】
【現(xiàn)象】
// 形式一：
{
result: {
data: [],
total: 0,
}
}
// 形式二：
{
result: {
data: [],
pagination: {
total: 0,
pageSize: 10,
pageNo: 1
}，
}
}
// 形式三：
{
result: {
data: [],
total: 0,
pageSize: 10,
pageNo: 1
}
}
【解決】
類型 10：后端一個接口拆分多個
【現(xiàn)象】
【解決】
基于一套合理可行的協(xié)作規(guī)范，前后端從開發(fā)到上線的各個階段都能夠看到諸多成效：
一言以蔽之：如果你發(fā)現(xiàn)前端在處理大量的邏輯，那么就是協(xié)作規(guī)范存在問題啦！前端更多的是關(guān)注交互、渲染上的邏輯，應(yīng)盡量避免復雜的業(yè)務(wù)邏輯處理。萬事開頭難！推一套規(guī)范是需要時間去沉淀的，前端和后端同學都應(yīng)多些耐心，多些理解。
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動版官網(wǎng)