如何高效率規模化生產中後臺頁面，如何保障產品標準、質量及體驗的一致性， 如何提升開發效率是我們當務之急的命題。
背景
電商發展至今，供給側升級降本提能、精細化運營是未來的關鍵，由此B端中後臺需求井噴並呈增長態勢。隨著運營工作臺SOP體系透過跨系統能力整合打造運營標準操作鏈路，解決運營操作體驗及站點交付效率問題時，運營能力的產品&體驗一致需要頁面研發保障，提供保障體驗的高效頁面研發能力尤為重要。
中後臺場景互動視覺趨於標準，需求鏈路長角色多協同成本高，現有研發方式研發核心圍繞原子及業務元件ProCode大量低水平重複，LowCode事件聯動，資料繫結等仍需大量程式碼瓶頸明顯，頁面生產模式亟待突破。
如何高效率規模化生產中後臺頁面，如何保障產品標準、質量及體驗的一致性，如何提升開發效率是我們當務之急的命題。
問題&策略
目標面向工作臺/大淘寶中後臺，革新頁面生產模式升級頁面生產工具帶來生產效率的提升。
主要圍繞兩個思路：
以場景為中心。 針對中後臺場景特點及對大部分現有業務梳理，表單列表詳情類場景佔比86%，基於抽象特徵提煉統一描述，固化結合領域特性標準化場景，圍繞標準生產資料進行產品設計及頁面研發生產能夠將場景價值最大化，有效降低邊際成本提升整體生產效率。
以流水線式為出發點構建全域性最優的生產模式。 本身整個生產過程可以看做是有序的且包含多個角色，圍繞產品功能本身做不同部分、環節生產加工的流水線，將各環節加工產物標準化並流轉，提供適配不同角色的工具，提升整體協同生產效率。 並且希望 站在全域性最優效率的角度去看整個生產鏈路，而非單一解決某個角色或環節的問題而粗暴將工作量轉移，並且根據必要性，可轉換性，可替代性構建新的生產模式。
整體方案
協同模式升級：透過設計與前端的標準場景規範定義，沉澱場景物料，以場景為中心，產品圍繞場景設計、頁面圍繞場景搭建、介面基於場景配置推導，改變各角色的生產關係，縮減轉譯環節，提高整體交付效率
研發模式升級：構建無程式碼UI生產能力基於場景無程式碼配置生產（包含聯動互動、條件渲染，資料繫結等完整功能）頁面並生成資料API需求描述，後端按要求提供及繫結API後完成研發。
產品標準及體驗保障：基於標準場景頁面全流程無程式碼研發，保障產品設計和技術實現的標準及產物質量。同一體系內都呈現一致的互動語言和產品調性，降低使用者學習成本，提升業務使用體驗。
技術架構
場景標準化
平臺架構以場景為中心，產品圍繞場景設計，頁面基於場景搭建，API 資料結構根據場景定義。因此，要定義出場景，收斂並標準化沉澱。
首先場景是基於中後臺常見的產品模式和功能板塊拆解，對互動形式、介面資料結構進行標準化收斂後，提取出的功能高度收斂的場景物料和場景控制元件。
從技術上定義來看：
按UI體系原子化設計的粒度劃分，場景物料屬於模版粒度，比如，基礎查詢場景包含篩選表單、操作區、展示表格、翻頁器，是頁面內的大區塊； 場景控制元件屬於元件和模組的粒度，比如員工選擇器、日期展示元件等。
從能力上看場景物料和場景控制元件具有業務屬性，內建了業務相關邏輯和API資料請求，比如： Fusion Table 是純 UI 元件，AntD ProTable 封裝了翻頁、篩選等預設邏輯，查詢場景物料還額外封裝了介面請求處理，標準了場景所需要的介面及其資料格式即 場景模型 。
場景內建核心功能，並預留一些擴充套件能力，透過場景控制元件擴充套件場景中輸入/展示/操作等 UI 元件，透過能力外掛擴充套件條件渲染、聯動執行等非 UI 型能力。場景與控制元件正交組合，再結合能力外掛，就構成頁面區塊的完整功能，多個區塊佈局組合就構成完整頁面。
圍繞上述核心邏輯，我們構建了完整的場景標準化體系：
制定
場景規範
： 成立場景規範小組，結合業務場景訴求，制定各場景統一的互動樣式和介面資料規範。
建立
場景沉澱
機制 ： 對於與現有場景完全不同的新場景，先按業務訴求梳理場景案例，對功能抽象分類，再經由場景規範小組評審，設計出符合規範的場景，最後開發並沉澱場景。 對於與現有場景相似但有定製化訴求的，拆解出要擴充/定製的能力，同樣經過小組評審後，在現有場景上進行迭代。
構建
場景生態
體系： 圍繞整個大淘寶中後臺域，構建整體場景標準及多業務域協同機制，統一管控及沉澱標準場景。 並提供自定義物料研發套件及接入能力，以支撐更大範圍業務場景。
資料標準化
資料標準化核心為模型定義，資料模型生產及資料實體生產三個環節，將基於場景標準化產出的場景物料對應的API及其所需欄位透過場景化搭建配置組合業務模型中的欄位生成具體所需API及欄位，後端根據API需求提供並繫結API實體完成頁面所需API的標準化生產。
模型定義，基於現有頁面API結構的拆解，主要有這幾部分：
閘道器模型 ： 描述工作臺閘道器封裝的資料結構，包含介面成功失敗標識、錯誤資訊、閘道器額外的除錯資訊等。 閘道器模型固定，對工作臺所有介面都有相同的結構。
場景模型 ： 描述具體場景涉及的所有介面的結構，包括場景內固定的入參、返回值欄位，以及如何透過場景配置引入的業務模型欄位。
業務模型 ： 描述實際業務中的概念、涉及物件及其屬性，包括欄位、型別、含義等。 同一個業務模型可以用於多個產品頁面。
模型或者說標準的定義並不一定是定義本身多先進，而是大家認可並且能夠遵循。因此在整個工作臺維度我們成立了覆蓋全域產品後端的規範小組，透過整體Review，RFC機制保障模型的標準及有效，透過每個團隊的介面人推進規範落實及收集反饋持續最佳化。
資料模型生產：有了上述三個模型，就可以在使用平臺研發時，透過選擇業務模型欄位並關聯到場景配置中，進而推匯出頁面所需的介面定義（入參和返回值的欄位結構）。技術上類似模版引擎，場景模型是模版，將業務模型欄位填充到模版中的佔位符，最後再套上閘道器模型的固定結構，就是期望的 API 資料模型。
資料實體生產：後端按照推匯出的 API 介面定義來標準化實現介面，同時我們也基於場景標準構建了通用的Java類，比如分頁列表類、級聯查詢類等，配合一些工具函式，將 DO/DTO 快速轉化成 VO，降低介面表現層的研發成本。大部分情況下比如新業務後端都相對能夠較好的按照所產出的結構提供資料，但是針對一些存量介面，二方服務依賴較多的介面等情況後端改造及適配成本相對較高，我們也提供了欄位組合對映能力及服務編排能力，以更低成本將非標介面快速轉化成推匯出的 API。
無程式碼頁面生產
無程式碼核心目的是透過場景標準沉澱的場景物料及資料規範完全無程式碼生產完整功能頁面並驅動頁面所需API資料結構的生成，以解決現有研發效能低，體驗&質量難保障及前後端聯調等協同問題。
頁面由UI、互動、資料構成，場景標準化和資料標準化保證了研發資產（場景和模型）是收斂的，已經有了 UI/互動/資料的結構化的大框架，只需要少量的研發工作就完成頁面研發，而對於簡單的結構化的頁面研發，高效的方式就是視覺化配置。
從場景的角度出發，剩餘的研發工作主要有場景配置、多個場景佈局和聯動、一些全域性資料的貢獻等，都可以收斂並抽象成視覺化配置。全流程無程式碼視覺化配置能降低非前端上手門檻，進一步提高交付質量和研發效率。
與低程式碼的差異？相較通用低程式碼研發平臺，我們基於標準場景搭建將非UI部分的互動邏輯和資料對接等也進行了抽象和更深層次的能力封裝，去除手寫程式碼的負擔，使得全流程無程式碼研發成為可能。
標準協議 ： 以集團低程式碼協議和 OneAPI 2。0 協議為基礎，補充場景模型、業務模 型、閘道器模型、聯動佈局等協議，構成完整的無程式碼協議，同時支撐研發配置和執行渲染。
研發資產 ： 場景中心輸入場景和場景控制元件，模型中心輸入閘道器/場景/業務模型，共同作為標準的研發資產。
研發配置 ： 頁面研發可以分為UI/互動/資料三個方面，從UI入手對單個場景進行配置，包括條件渲染、引數傳遞、全域性篩選等功能配置，對多個場景組合佈局，互動上配置場景間的聯動關係，資料上將API推導的介面定義繫結到後端實現，就完成完整頁面研發。 結合實時預覽和介面mock可以一邊配置一邊快速檢視效果。
構建釋出 ： 配置資訊整合加工後，產出頁面schema和API資料模型，然後提取元件依賴，結合腳手架生成程式碼並更新倉庫，最後構建釋出到CDN。 除了常規的頁面應用，也支援將頁面構建釋出成微模組。
執行渲染 ： 使用集團低程式碼渲染引擎解析頁面schema，渲染布局、場景和場景控制元件，使用聯動流程排程引擎處理整個頁面的聯動邏輯，介面請求則由場景自行發起和處理。
One more thing - 中後臺研發效能度量
年年效能持續提升但是還是沒變化？效率是中後臺研發的核心目標之一，目前業界和集團內缺少兼具普遍性和實操性的效能度量方案。因此，有必要建立通用可行的中後臺要能衡量對比中後臺原始碼/低程式碼/無程式碼三種研發模式，覆蓋研發及聯調完整生產環節的效能度量模型及方案。以資料化方式度量專案、個人、團隊的研發效能並指導未來效能提升的方向。
▐ 現在方案的問題&策略
效能度量方案僅停留在程式碼複雜度層面，採用霍爾斯特德複雜度來度量，無法衡量專案變更的複雜度變化，無法解決中後臺原始碼/低程式碼/無程式碼三種研發模式的效能對比。 創新性地設計歸一化最小作用域複雜度模型，解決變更和不同研發模式統一度量問題。
大部分度量方案沒有針對研發全鏈路更細緻的度量指標。 中後臺效能度量方案從微觀和宏觀的研發、聯調時長出發，結合研發流程，計算過程指標和結果效能指標，並提供效率提升的分析依據和量化基準。
▐ 核心方案
定義效能指標及計算公式 ： 分析拆解效能的度量指標，建立效能指標計算公式。 研發效能 = 歸一化複雜度 / 研發總耗時 = （ 最小作用域差量複雜度 / 研發模式標準頁面複雜度 ） / （ 連續研發工時 + 連續聯調工時 ）。
構建複雜度度量模型 ： 改進霍爾斯特德複雜度演算法，引入程式碼Diff、依賴分析、AST分析，搜尋差量程式碼的最小作用域，計算變更引入的複雜度，解決目前業內霍爾斯特德複雜度無法評估變更效能。
構建連續時長度量模型 ： 預處理原始碼/低程式碼/無程式碼研發和聯調操作的打點資料，按時間進行閾值分隔，動態構建活躍會話視窗，計算連續研發時長和連續聯調時長。
標準頁面歸一化 ： 對不同研發模式的頁面分層取樣，統計場景頻次和佔比，構建標準頁面，用於歸一化專案複雜度，解決不同研發模式語法信噪比不同導致的複雜度比較問題。
完整度量計算鏈路 ： 歸攏中後臺三種研發模式，設計度量採集、資料加工、指標彙總的完整鏈路，為提供效率提升的量化基準和分析方向
總結
▐ 一點感悟
關於低程式碼/無程式碼
由於近年來各種LCDP/Low-Code概念太熱各種方案及平臺層出不窮，導致不少偏執的認識。部分人粗暴的把所有研發內容視覺化，比如一些僅僅是把寫程式碼的過程轉化為視覺化過程的產品，針對某些人群在某種程度上是降低了門檻，但在真實生產中效果有限定位尷尬。另外一種聲音是完全否定，只要是聽到相關名詞就覺得是重複的，或者說覺得做不到、效果一定不好。很多過程的配置化、視覺化確實不適合就如前面的描述。但是無法否認的是視覺化方式更直觀、約束更強、門檻更低，核心考量在於具體的場景，研發環節及內容抽象度及合理性，能否標準化，配置是否足夠友好，目標使用者及所解的命題。
關於新工具學習使用成本及收益
對於解決問題的新工具如何考量自身學習和使用的投入產出，主要三個方面：權衡取捨，成本、邊際量。直白說如果需要獲得的是程式設計技能，那用這類研發工具那是不適合的。如果你有大量的頁面生產工作，並且期望高效的完成，那投入成本學習是有價值的。所以很多時候要客觀理解具體的使用情況及反饋（當然是在工具真的能解決問題的前提下）。
關於研發生產
我們大部分時間開發其實本質就是在做某種邏輯的轉換，而不是做什麼設計，如何將人肉繁雜的處理過程、協同過程轉為更高維度的抽象，各角色圍統一模型有機協同生產，帶來整體提效是需要持續探索的。而不是單一的構建一個工具、能力粗暴轉移工作量，僅僅解決一個角色自身問題為出發點。
▐ 一些結果
完成無程式碼平臺初步建設，實現多角色協同生產，縮減非必要的轉譯環節，提高頁面生產效能。定義場景標準，沉澱25個標準場景，場景業務覆蓋率達到96%；沉澱39個場景資料及81個業務資料規範。構建統一的中後臺研發效能度量方案Orca-Efficiency能夠度量完整頁面研發及聯調過程，可度量及對比ProCode、LowCode、NoCode三種研發模式。
平臺全年支撐200+需求/專案迭代，覆蓋大淘寶商家、商品、營銷、智慧人群運營全業務產品整體新需求覆蓋率79%，並支撐直播域，X業務等10+產品構建。根據統一效能度量無程式碼模式效能相較原始碼提升5倍，低程式碼提升1倍，完整協同及生產提效68。6%。並且透過標準場景及無程式碼方式有效保障產品體驗&研發質量。
作者：
俊希（盧俊希）
大淘寶技術
出處：https：//mp。weixin。qq。com/s？__biz=MzAxNDEwNjk5OQ==&mid=2650469344&idx=1&sn=73b19a0cc48b67702688271f98633455
