導讀

introduction

在大部分場景中，前后端可以在開發(fā)前約定好數(shù)據(jù)接口，雙方能夠圍繞約定并行地完成開發(fā)和自測。然而在大型系統(tǒng)中一些后端模塊有時并非直連前端，在它們之間可能包含一些其它模塊的處理過程，為了保證數(shù)據(jù)真實有效，前端需要搭建整套環(huán)境來調(diào)試渲染效果，導致效率和研發(fā)體驗不斷劣化。本文主要介紹百度商業(yè)前端團隊結(jié)合接口平臺和數(shù)據(jù)直達能力優(yōu)化前后端協(xié)作效率的嘗試，有效的提升了團隊協(xié)作效能。

一、實踐方案

GEEK TALK 我們的實踐主要分為兩大階段：

1. 協(xié)作提效；

2. 質(zhì)量保障&體驗優(yōu)化。

其中協(xié)作提效包括基礎能力建設和協(xié)作模式升級落地；質(zhì)量保障&研發(fā)體驗是在協(xié)作提效的基礎上，對業(yè)務質(zhì)量保障和極端場景所遇到的問題提出的一些解決方案。

二、數(shù)據(jù)直達能力

GEEK TALK 我們團隊所維護的后端模塊是一個BFF層，負責適配上游和前端模塊的數(shù)據(jù)，和前端業(yè)務聯(lián)系非常緊密。然而由于該層和前端之間還包含了一些策略和聚合的處理邏輯，大家在開發(fā)自測過程中沒辦法直接使用樁數(shù)據(jù)來預覽效果，前端為了調(diào)試功能只能維護多套環(huán)境，除去環(huán)境搭建本身需要消耗大把時間之外，模塊連通性排查、資源協(xié)調(diào)，環(huán)境更新都會影響前端的工作效率。 為了減少維護環(huán)境帶來的精力消耗，我們在實踐初期嘗試過多次環(huán)境管理優(yōu)化，效果都不是很理想，一方面有限的環(huán)境資源始終沒辦法很好地滿足頻繁迭代的需要，另一方面環(huán)境提供方也疲于應對各種各樣的問題，所以我們就想能不能不再維護線下環(huán)境，而是將開發(fā)測試的工作轉(zhuǎn)移到線上環(huán)境上去進行，也就是讓后端能夠同時處理線上和線下數(shù)據(jù)請求，使前端在連接線上環(huán)境時看到線下數(shù)據(jù)的渲染結(jié)果。 基于這個思路，我們在后端隔離出一套旁支邏輯定時地從Redis拉取線下物料數(shù)據(jù)和對應的設備信息，其中設備信息是某臺手機或者某個瀏覽器唯一id，當這些設備所對應的請求到達時，后端就把它當作一個特殊請求替換原有請求成線下數(shù)據(jù)，接著繼續(xù)之后的處理過程，前端只需要將數(shù)據(jù)和設備信息寫入到Redis就能接收到線下數(shù)據(jù)的處理結(jié)果，這樣前端就像在使用一套始終保持最新版本的常駐環(huán)境，不會再被各種各樣的環(huán)境維護問題消耗精力，雙方都能在協(xié)作過程中更關注業(yè)務邏輯本身。

三、升級協(xié)作模式

GEEK TALK 借助數(shù)據(jù)直達能力，我們成功解決了環(huán)境維護困難的問題，大幅地提升了聯(lián)調(diào)階段的效率，但其實我們在開發(fā)階段的協(xié)作仍然存在著一些問題。在能力建設初期我們只支持了請求數(shù)據(jù)的替換，前端沒辦法在后端代碼上線之前開始開發(fā)，這樣串行的協(xié)作模式顯然是有問題的，所以我們就想能不能基于數(shù)據(jù)直達能力擴展出一套常規(guī)的樁服務。 為了實現(xiàn)樁服務，我們在需要作為樁輸出給前端的數(shù)據(jù)上添加了特殊標識，當后端識別到攜帶特殊標識的數(shù)據(jù)請求時就會跳過后續(xù)的處理邏輯，直接返回結(jié)果給下游模塊。這種替換返回的模式能夠讓后端在開發(fā)前就將線下樁數(shù)據(jù)交付給前端使用，使前后端能夠并行協(xié)作。

為了減少學習和操作成本，我們將以上所介紹的能力封裝成平臺提供給團隊使用，后端可以按照項目為維度編輯和交付數(shù)據(jù)，前端可以拿這些數(shù)據(jù)去和設備做連接，然后直接在app上刷新就可以看到效果。

四、數(shù)據(jù)分級

GEEK TALK 為了改造前后端協(xié)作模式，我們在開發(fā)過程中使用的其實都是樁數(shù)據(jù)，這樣可能會導致數(shù)據(jù)和最后真實邏輯所輸出的結(jié)果存在差異，這些差異可能會暴露到線上影響業(yè)務功能，所以如果缺少有效的措施去約束數(shù)據(jù)使用的話，那么質(zhì)量風險會變得難以控制。 為此，我們將數(shù)據(jù)的使用根據(jù)規(guī)則和應用場景劃分成三種類型：手動生成、線下后端生成、線上后端生成。

可以看到，數(shù)據(jù)的約束規(guī)則隨著項目的推進是逐步收緊的。在開發(fā)前期后端能使用編輯生成出的樁數(shù)據(jù)快速交付給前端，讓前端完成單模塊開發(fā)自測；在聯(lián)調(diào)階段，我們的數(shù)據(jù)是由后端所開發(fā)完成的代碼邏輯生成而來的，由于這部分數(shù)據(jù)需要保證一定真實性，所以不再支持編輯，這樣數(shù)據(jù)就能夠匹配上后端即將上線的邏輯；而在后端上線完成之后，前端能夠從線上檢索系統(tǒng)采集到真實物料數(shù)據(jù)，通過掃碼等方式進行效果預覽，這樣同時從數(shù)據(jù)和代碼邏輯兩方面保證了真實性。 通過上述對數(shù)據(jù)分級的規(guī)劃，我們保證了協(xié)作過程在高效并行運轉(zhuǎn)的同時，始終遵循一套流程標準，能夠有效地保障了業(yè)務的交付質(zhì)量。

五、優(yōu)化平臺體驗

GEEK TALK 經(jīng)過前面三個步驟的優(yōu)化，我們在大部分的項目中已經(jīng)能讓前后端解耦協(xié)作，然而在一些復雜項目中這套流程反而會降低工作效率，這是因為復雜項目往往需要覆蓋的功能點更多，數(shù)據(jù)組合也相應的更多，我們發(fā)現(xiàn)部分項目所需要的數(shù)據(jù)條數(shù)甚至超過兩百條，這樣后端就要花費大量的時間和精力去錄入和編輯數(shù)據(jù)，在這種極端需求下數(shù)據(jù)準備時間就成為了效率瓶頸，使得研發(fā)體驗急劇下降。 為了解決這個問題，我們圍繞“片段”概念支持了對數(shù)據(jù)批量編輯的功能，可以讓后端在編輯數(shù)據(jù)的過程中，將編輯的操作以“片段”的形式保存下來，每一個“片段”包含編輯的位置和值，這些“片段”可以繼續(xù)應用到多個數(shù)據(jù)上，這樣編輯工作就從多次變成一次，大大減少了重復工作量。

同時，由于前端需要頻繁對同一個功能進行例如版本兼容、標題長度兼容等細分情況的驗證，為了更好的支持這種需求，我們支持了“片段”的版本的功能，也就是在保持“片段”操作位置不變的前提下，為“片段”賦予不同的值，前端可以通過切換“片段”的不同版本，快速拿到同個功能下攜帶不同細節(jié)的數(shù)據(jù)去快速地驗證一些兼容效果。

六、總結(jié)

GEEK TALK 前后端數(shù)據(jù)接口協(xié)作升級使我們的團隊能夠更穩(wěn)定高效地完成產(chǎn)品迭代，團隊的項目的平均交付時間減少了50%以上，目前已經(jīng)有上千次的業(yè)務項目基于這套方案完成了開發(fā)測試和線上回歸工作。我們也在持續(xù)不斷地探索在如產(chǎn)品視覺驗收、銷售問題驗證等其它方面落地的可能性，希望能在更多的場景下提升團隊的協(xié)作效能。

END

審核編輯 ：李倩