前端代碼是怎樣智能生成的業務邏輯智能生成篇

NO IMAGE

作為阿里經濟體前端委員會四大技術方向之一,前端智能化項目經歷了 2019 雙十一的階段性考驗,交出了不錯的答卷,天貓淘寶雙十一會場新增模塊 79.34% 的線上代碼由前端智能化項目自動生成。在此期間研發小組經歷了許多困難與思考,本次 《前端代碼是怎樣智能生成的》 系列分享,將與大家分享前端智能化項目中技術與思考的點點滴滴。


文/卡狸

【閱讀提示】

  • 全文較長,部分術語阿里淘系內部營銷領域特有。有困惑之處可以評論交流。
  • 本文重點介紹 D2C 面對阿里內部淘系大促場景遇到的問題和解決方案,更多的研發場景我們將在不遠的將來一一涉足。
  • 本文提及的部分功能只有阿里內部版 imgcook 才有,社區版 imgcook 暫時無法體驗,敬請期待。

概述

imgcook 是以各種設計稿圖像( Sketch/PSD/靜態圖片)為原材料烹飪的匠心大廚,通過智能化手段將各種原始設計稿一鍵生成可維護的 UI 視圖代碼和邏輯代碼。

邏輯開發是前端開發的需求動線圖中最後,也是耗時最多的一步。從整個前端的開發過程上看,除了初始的靜態視圖編寫,所有的 數據映射、添加動效、函數編寫、事件流、埋點日誌等代碼本質上都是對靜態視圖信息的一種補充。

下圖中,需求的產出是 產品、交互設計師、視覺設計師 共同協作的結果,而需求落地全由程序員實現。如果說 “視覺稿 結合 PRD 交互文檔”等於最終可交付開發的需求文檔,那麼 “靜態視圖 + 邏輯”就等於一個前端頁面的最終代碼。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(需求動線圖)

探索歷程

前端開發工作屬於 GUI(Graphic User Interface) 編程的一種,從命令行時代進入圖形用戶界面時代之後直到現在,對 便捷的進行界面開發 的探索就沒有停歇過。在年頭尚淺的前端領域,也有 MVCMVVM 的設計思想落地 和 jqueryBackbone.jsAngularvuereact 這些優秀框架類庫的湧現。

關注點分離(Separation of concerns)是 GUI 開發領域的指導思想,通過將 View 視圖Model 數據 分離來簡化軟件內部結構。事實上大部分界面開發領域設計思想和框架都是遵循此基礎思路實現的,html + css + js 的 web 技術也是此思想的一種體現。

集團推崇的 react 的思想比較接近這個最初的核心理念,僅提供  VM,以及一個兩者關聯的渲染過程。簡單來說就是 Ui = render(Data),我們認同並作為依據之一開展了基於視覺稿視圖還原代碼的 D2C 項目。

我們本文所要探索的業務邏輯是項目代碼中除了 View視圖 以外的內容。如果說 D2C 是一個視覺稿到代碼的過程,那麼距最終可上線頁面代碼的缺失部分就要交給本文的業務邏輯層來實現。

所在分層

業務邏輯層處於 D2C 核心能力的最下游,所有服務化的智能化能力都需要在邏輯層實現最終的落地。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 技術能力分層)

挑戰和難點

現狀分析

在 D2C 的體系裡,大部分技術體系都是基於設計稿視覺稿維度出發的,目標是解決佈局結構、字段類名、內聯組件識別的準確性和合理性。而業務邏輯需要補全 D2C 欠缺的能力,技術方案上和整個項目都不太一致。

同時,業務邏輯層作為承上啟下的關鍵層,負責承接D2C智能化能力,輸出到可視化編排平臺。
智能化結果的是一個概率,是一個有機率不準確的值,而下游的可視化編排 IDE 卻是一個需要有確定性協議的程式,這樣才能保證輸出的代碼可最終上線。業務邏輯能否實現智能化的穩定落地是我們一個極大的挑戰。

在現有的 D2C 鏈路圖裡,業務邏輯層的輸入信息除了佈局算法轉換後的 UI 結構,還有以下輸入項:

  • 語義化推測出的類名
  • 字段綁定猜測出的可綁定字段(含圖片分類和 NLP 分類)
  • 組件物料識別出的小組件

業務邏輯層的產出結果是一份攜帶邏輯的可視化編排協議。這份協議的字段通過最終實現的功能來看又可劃分成如下幾種:

  • 視圖模型
  • 字段綁定
  • 函數邏輯
  • 自定義組件轉換

目標鏈路

傳統開發鏈路中,UI 編碼和邏輯需要人工編碼。在當前的 D2C 鏈路中,基於 D2C 視覺還原能力,我們可以將 UI 編碼實現自動化開發,基本省略 UI 的開發時間。而 D2C 業務邏輯層的目標,就是實現邏輯編碼的自動化。我們希望將 D2C 能力進行全面升級,實現視覺 + 邏輯的統一還原,達到前端編碼的零投入。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(傳統編碼鏈路、 D2C 鏈路 與 目標鏈路 )

上圖中,藍色的部分實現了自動化開發,紅色的部分是 D2C 能力介入的位置。在我們期望的鏈路裡,D2C 將還原並實現前端全部代碼,而設計稿作為唯一的輸入必然存在一些需求的缺失,為此我們在還原步驟之前增加邏輯預配置階段,實現對缺失的需求進行補充。

問題分析

步驟一:思考真實的邏輯開發過程

我們在實現邏輯智能自動化之前,要分析一個邏輯代碼是如何編寫出來的。

假設我們已經開發好了靜態視圖,接下來需要為頁面增加的邏輯代碼需要一個輸入的過程,這個輸入源可以是我們的視覺稿、過往開發經驗、框架下的特殊規則、PD 的需求文檔等,從需求的輸入源裡我們獲取需求相關的信息並具象為一個個邏輯點。

比如:視覺稿中有一個寫著搜索的按鈕,我們觀察的同時檢索腦海中過往經驗,這個搜索大概率是一個點擊觸發一個網絡請求的邏輯,藉助需求文檔和與相關接口人溝通,我們知曉了這個網絡請求的方式和返回內容。據此,一個需求的形態就具象成了一個邏輯點,下一步就是邏輯編碼並提測。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(前端需求編碼操作動線)

為了實現邏輯的智能生成,以上操作動線必須實現全自動。我們觀察需求編碼動線,可以明顯的發現:以需求具象為分割線,邏輯編碼過程可拆分為前後兩個大階段。前一階段實現需求的收集,後一階段實現需求的實現,中間具象化的一個個需求點就是我們開發中要編碼解決的工作。

在我們期望的鏈路中,業務邏輯層將為 D2C 能力提供邏輯預配置和邏輯還原兩個增量能力。這兩個增量能力對應到需求動線上就是需求的收集與需求的實現。在 D2C 體系裡,我們稱其為 邏輯識別 與 **邏輯表達,**並分別融入到鏈路下述兩個位置上。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 邏輯鏈路)

步驟二:如何識別邏輯?

D2C 體系裡,邏輯識別是一個預先配置的過程。不同的邏輯點可提前配置好不同的預案,用戶使用 D2C 時命中了哪一項配置就認為此處存在哪個邏輯。

在 D2C 首先落地的 淘系營銷場景 裡,我們嘗試分析邏輯智能化生成面臨的最大問題。

思考一:“如何判別模塊所含有的邏輯點?”

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(如何觀察模塊含有的邏輯點)

掃一眼上述模塊的佈局模式,是一個 1排2 模塊,需要一個循環邏輯。

“掃一眼”這個動作,通過分析佈局算法給出的頁面結構可以識別。

分析下各個文字,“跨店滿減,錯過等明年”是一個利益點類型文案.

人“分析文字”是對文字提取特徵的過程,不同的目的下通常要提取不同的特徵。此處文字中“跨店”、“滿減”等利益點相關的詞高頻出現,我們基於 ALiWs 的分詞算法和樸素貝葉斯多分類可以有效區分。

“已售1000件”看起來需要綁定到月銷字段上;

此處也是個分析文字的過程,用正則可以準確區分。

左下方的券在含有一定顯著的視覺特徵,對於這種小區塊通常抽象為一個業務組件;

左下方的券是一個業務組件,其樣式,文字,節點數目存在數據特徵,我們可以運用傳統機器學習進行分析。

商品的圖片是一張白底圖,大概率綁定到白底圖字段上;

商品圖是一類特徵明顯的圖,基於圖像分類算法可較為輕鬆的識別。

立即購買按鈕可能需要一個跳轉到詳情頁的事件,也有不跳轉,轉而交給模塊外層來跳轉。

這個邏輯只能通過領域經驗來識別。

思考二:“是否可以覆蓋我們的場景?”

類似的分析過程還有很多,我們暫不贅述。為了能解決命題,我們迫切的需要知道實際場景中上述邏輯點的構成情況,為此我們分析淘系營銷大促相關模塊,得到如下邏輯點分佈柱狀圖:

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(營銷模塊邏輯分析柱狀圖)

其中數據綁定類邏輯數量佔比 50% 以上,其次是埋點相關邏輯,循環相關邏輯,處理業務的函數相關邏輯,組件邏輯等。總的來說,淘系營銷場景的模塊開發邏輯是一套有規矩可循、有規範可依,可枚舉、可複用、模式化、體系化的程式。經過多年雙11驗證,基本可以確定當下的規範可以滿足業務需求,不會在短時間內有大規模的未知需求湧入。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(淘系營銷模塊開發規範)

思考三:“我們的識別手段有哪些?”

D2C 體系本身具有許多底層智能化手段,輔助以專家經驗,可以對上述邏輯進行全面檢索識別。舉例如下:

隨機森林算法:隨機森林是一個包含多個決策樹的分類器, 並且其輸出的類別是由個別樹輸出的類別的眾數而定。既可以用於迴歸也可以用於分類任務,並且很容易查看模型的輸入特徵的相對重要性。

xgboost 多分類:XGBoost全名叫(eXtreme Gradient Boosting)極端梯度提升,經常被用在一些比賽中,其效果顯著。它是大規模並行boosted tree的工具,它是目前最快最好的開源boosted tree工具包。

文本 NLP 分類:基於阿里 PAI 平臺提供的 ALiWs 的分詞算法和樸素貝葉斯多分類進行文本分析。AliWS 的主要主要功能包括:歧義切分,多粒度切分,命名實體識別,詞性標註,語義標註,支持用戶自己維護用戶詞典,支持用戶干預或糾正分詞錯誤。

圖片分類:對業務場景中的圖片進行分類,使用 CNN 網絡,在 ResNet 的基礎上進行遷移訓練。同樣部署於 PAI 平臺之上,和文本 NLP 分類產品化鏈路完全一致。

語義化服務:D2C 基於移動場景定製的類名語義服務。內部運用專家系統制定策略樹,在具體判別過程中運用 Alinlp 語義實體、詞法分析、翻譯等二方服務,並自建 iconFont 服務實現了小圖標的鑑別。

佈局算法:D2C 基於自創的行列掃描策略發展出的絕對定位轉 flex 佈局的規則算法,同時提供了循環檢測、局部成組等關鍵性功能。
等等。

除此之外,我們有一些業務域下獨有的邏輯是沒有特徵的,這部分邏輯使用人工干預手段來實現。

最終,我們決定選用多種識別手段,從 佈局視覺、文本語義、圖像特徵、經驗規則 的層面實現邏輯的判別,並補充必要的額外信息供邏輯表達使用。這些對模塊邏輯進行識別的程式我們命名為 邏輯識別器。

每一個識別器都會基於自身擅長的領域給出鑑別結果,通過全方位的檢索視覺稿,達到近似人工思考的目的。

步驟三:如何表達邏輯?

邏輯表達依賴於兩個要素:邏輯的表達形式和邏輯的具體內容。

思考一:“邏輯以何種形式表達?”

為了明確邏輯的表達形式,我們 D2C 需要一個可承載智能化成果的場景,具體到實現上就是 一套承載智能化成果的協議 和 一個智能化干預平臺。

imgcook (D2C 能力落地應用)結合 reactvue 等優秀的前端框架,參考各種競品,實現了一套簡版的基於數據驅動(Ui = render(Data) )的生命週期,並希望用戶能基於此規範進行組件的開發和編寫。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(imgcook 自定義生命週期)

阿里淘系營銷於 2019 年將營銷模塊規範升級到了基於 hooks 的 rax1.0 體系,imgcook 針對新的組件規範,實現了 mobile 和 PC 各一套的代碼生成服務。這樣開發者在 hooks 下也有生命週期可以使用,對開發者來說,不需要關心模塊是 hooks 還是其他技術方案,只需要認準 imgcook 規定的模塊開發方式就可以。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(imgcook 天馬模塊項目結構組織圖)

約束了用戶的編碼規範之後,imgcook 提供了可視化的操作來實現代碼。imgcook IDE 目前可實現大部分靜態模塊的可視化編寫,下面是模塊邏輯可視化高頻操作的面板:

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(imgcook 可視化面板【內部版】)

以淘系營銷中的典型需求舉例,在 imgcook 的可視化編輯器內,我們通常會這樣實現(假定模塊當前數據是一個單循環一排二商品模塊,循環迭代對象 item

  • 為節點的價格綁定數據:點擊 節點屬性 -> 數據 -> 新增一個數據綁定,值為 item.itemActPrice
  • 模塊不足一行的時候進行截斷:點擊 快速設置 -> 代碼編寫 -> 新增一個方法 -> 編寫截斷代碼,將 items 的長度不被 2 整除的數據去除。
  • 埋點邏輯:普通埋點需要 點擊節點屬性 -> 類型切換為 埋點鏈接,點擊新增一個數據綁定,增加 data-track-typeexp-type等屬性,併為其增加數據綁定;主會場實時埋點在做節點類型轉換和數據綁定之餘,還需要在循環節點裡新增一個用於實時曝光的節點,其曝光類型需要設定為實時曝光。
  • 加載更多:下滑式加載更多需要為模塊增加曝光事件,事件句柄裡編寫加載更多代碼。點擊加載更多需要為模塊增加點擊事件,事件句柄裡編寫加載更多代碼

對各個邏輯的操作步驟進行抽象化梳理,得出瞭如下邏輯實現步驟:

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(邏輯實現步驟抽象梳理)

表格裡每一個列都是 imgcook IDE 一類抽象化的能力,可見大部分邏輯都可以通過配置的形式來實現。
由於大規模業務邏輯的營銷模塊較少,所以我們決定基於複用而不是基於推測來生成函數算子,僅使用執行順序和是否有返回值來控制流程,更為細粒度的算數、邏輯操作符和流程控制語句暫不在我們的考慮範圍內。

思考二:“邏輯以何種內容填充?”

可視化和真實代碼之間的媒介就是 imgcook 的協議,接下來我們就需要實現協議的自動化生成。

自動化的協議生成的核心是 內容。節點將執行何種操作不是關鍵,要綁定到哪個節點、生成的代碼裡面內容 才是關鍵。為此,我們邏輯識別器執行時會將當前處理過程涉及到的節點信息、全局變量、人工配置等內容進行傳遞,在邏輯表達的運行時裡執行注入,這些當前邏輯要表達清晰準確所必需的數據在 D2C 業務邏輯層裡被命名為 邏輯上下文

下面來看一些真實的 邏輯上下文

邏輯一:為節點綁定活動價

// “邏輯上下文”
const recognizeResult = {
element: "Text_0",  // 哪個節點需要綁定數據 
meta:  {
expression: "item.itemActPrice" // 綁定具體表達式是什麼
}
}
// 最終翻譯到 imgcook 協議裡的示例協議(imgcook 私有協議裡將數據綁定都提到了最外層節點統一管理)
const layoutJson = {
id: "root節點", 
children: [...], // 節點樹🌲
dataBindStore: [
{
belongId: "Text_0",  // {{element}}
value: {
isStatic: false, 
expression: "item.itemActPrice" //  {{meta.expression}}
}   
}
]
...
}

邏輯二:不足一行截斷渲染數組
**
此邏輯函數內容是一個可複用的 xtpl 模板,可以直接訪問 recognizeResult 作為渲染上下文。

// “邏輯上下文”:scope 是邏輯層核心分析頁面佈局的處理結果之一,每個邏輯上下文都可訪問 
const recognizeResult = {
"element": null, // 此邏輯沒有掛載節點
"meta": {}, // 此邏輯也不需要額外參數
"scope": {
"gSize": 2, // 當前模塊是一個 1排2 模塊,不滿足 2 個的行將被刪除
"loop": "items", //  當前模塊以 data.items 這個數組屬性做循環
"loopArgs": "item", // 循環內部迭代對象名為 item
}
}
// 最終翻譯到 imgcook 私有協議裡的函數裡的示例協議
const layoutJson = {
id: "root節點", 
children: [...], // 節點樹🌲
scirptStore: [
{
content: `
...
{{~#if (ctx.userLogicConfig.sliceFloor)}}
// 掉坑處理,根據用戶是否使用 sliceFloor 來使用
const count = Math.floor(data.{{scope.loop}}.length / gSize) * gSize;
{{scope.loop}} = data.{{scope.loop}}.slice(0, count);
{{~/if}}
...
`,
name: "getModuleRows", // 截斷邏輯寫在拆行函數裡
type: "custom"
}
]
...
}

使用渲染上下文可以在最終要增加的協議中“佔坑”,實現協議的準確表述。

通過冗長的分析,我們業務邏輯智能生成的命題已經細化到了 如何運用智能化能力識別邏輯併產出上下文 和  基於上下文實現邏輯自動化表達 兩點上了。這兩點確認可行後,我們開始進行正式設計。

智能邏輯層設計

方案概述

根據對命題完整的推導,我們已經有了業務邏輯層能力的完整輪廓。

邏輯識別 + 邏輯表達 = 邏輯意圖
邏輯識別器需要您根據實際場景決定使用何種方式來執行識別。此階段接收視覺稿和人工規則,輸出為識別結果。
類比人的思考過程,D2C 此時已經 “確認了模塊的需求”。

邏輯表達器是 imgcook 可視化操作的預置版,將識別結果進行翻譯,將此條邏輯帶來的影響直接表現在最終的模塊上。
類比人的思考過程,D2C 此時已經 “寫完了這個需求”。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 業務邏輯層能力)

功能劃分

基於上述推導過程和職責界定,我們將業務邏輯層劃分為 邏輯識別邏輯表達邏輯核心 等模塊。

  • 邏輯識別 提供智能化能力統一接入,確保業務邏輯可以被指定識別器準確識別 並 產出統一邏輯上下文。
  • 邏輯表達 負責對邏輯進行可視化協議的配置,能自動應用邏輯上下文,在邏輯被識別出來之後自動錶現到模塊上。
  • 邏輯層核心部分 提供兩者的串聯整合和擴展能力,比如 執行時序控制、佈局模式支持、兜底 VO(View Object) 生成、邏輯上下文注入、人工干預等。從全局把控整個靜態設計稿邏輯化的過程。
  • Libs 提供基礎能力,一部分供核心調用,一部分可在邏輯上下文中供識別函數調用。
前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 業務邏輯層結構圖)

前文也說過,D2C 試點的是阿里內部淘系營銷領域,為了方便以後接入集團其他業務場景,我們有了附著於團隊的 邏輯場景 概念。邏輯場景是解決一個業務域的邏輯合集,只要某個業務域下的業務邏輯可枚舉、可規範、可定製,就可以構建自己的邏輯場景,方便自己的團隊的其他同學進行模塊開發。

邏輯核心功能拆解

佈局模式識別

D2C 支持對 一排N 類型模塊,橫向縱向循環 和 任意層級的循環嵌套這些佈局的識別,覆蓋營銷域下大部分的靜態模塊佈局。值得注意的是,D2C 對設計稿的規範程度要求較高,在雙11這種級別的活動裡對模塊佈局還原準確度的要求必須是 100%,這就要求智能化必須有規則化做兜底。為此我們升級了 D2C 設計稿協議,您可以在設計稿上用標註的形式規整設計稿,確保佈局還原結構準確、循環檢測正常。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 已支持的佈局模式)

視圖模型推演

智能化的前提是標準化。D2C 識別出的視圖需要和 數據模型(schema)映射上才可以正常表達邏輯。對模塊視圖佈局識別的過程中 D2C 會同步檢索 schema,確保循環層級和每一層的字段能對應上。然而現階段開發者不能保證模塊具有成型的 schema,為此 imgcook 實現了視圖模型推演,在沒有 schema 時能自動推測出模型,確保僅從視覺稿視角出發的 D2C 也是一個完備的體系。

推演是一個構建數據模型樹的過程,在佈局結構的過程中,我們將循環佈局視作枝幹,將每個觸發綁定數據綁定的節點視作枝幹的葉子,葉子的具體內容從淘系過往模塊數據聚合結果中獲取。

渲染上下文注入

函數識別器和視圖表達器是邏輯層兩個基於 node VM 執行函數的地方,從接口定義上可以看來他們之間的聯繫。
函數識別器

// 函數識別器入參
export interface LayoutJson {
children: LayoutJson[];
style: any;
}
export interface LayoutResult {
ctx: Ctx, // 開發上下文。略
scope: Scope, // 全局變量。略
UserLogicConfig: UserLogicConfig, // 用戶輸入。略
}
export interface Options {
utils: Utils, // 工具方法。略
_: any, // lodash // https://www.lodashjs.com/docs/latest
} 
// 函數識別器出參(僅在有識別結果時輸出)
export interface RecognizeResult {
order: number; // 當本次邏輯需要表達順序控制的時候,將按照 order 自小到大排列
element: number; // 本次邏輯掛載的節點 id
meta?: any; // 其他識別結果
}

視圖表達器

// 視圖表達器入參
export interface LayoutJson {
// 同 識別器入參一
}
export interface RecognizeResult {
// 識別器的出參
}
export interface Options {
// 同 識別器的入參三
}
// 視圖表達器出參
export interface ViewResult {
layout: LayoutJson // 處理後的佈局 json
}

函數算子時序控制

實際場景中,需要經由 D2C 自動化生成的編碼相關的邏輯較少。我們採用時序和是否有返回值來做簡單數據流向控制。流程控制只會出現在生命週期事件或節點事件的句柄函數裡,舉個例子,假設我們有三個邏輯需要在 created 裡面實現,分別是:“向循環數組塞入一個圖片”、“根據一排幾來截斷數組” 和“發送一個曝光埋點”。那麼通過配置順序和是否有返回值,我們可以得到這樣的 created 函數。

function created() {
let data = this.get();
// created-flow // created 流程開始
data = this.addImage(data);  // 順序為 1,有返回值
data = this.sliceArray(data); // 順序為 2,有返回值
this.expTrack(data); // 順序為 3,無返回值
return data;
}
export default created;

人工干預

我們也知道,許多邏輯是無法通過 設計稿Design 獲取到信息的。為了解決這種無特徵邏輯的生成,我們加入了人工干預來進行協調。
協調方式一是 參數問詢:定義自定義表單獲取用戶的輸入,在內部鏈路的 layoutResult.userLogicConfig 中訪問。
協調方式二是 邏輯過濾:每個邏輯的配置都有 開發者干預 選項,勾選之後,模塊開發者有權對此邏輯進行屏蔽。
這些管控措施都會體現在模塊還原的詢問彈窗上,若不瞭解彈窗內容的具體意圖,需要聯繫當前邏輯場景的負責人。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 開發問詢面板)

邏輯識別器一覽

邏輯識別器是一個 N 選一的配置方式,對於一個邏輯,我們有如下圖示來引導用戶使用正確的識別器:

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(選擇一個正確的 D2C 邏輯識別器)

1. UI 物料識別器

  • 特點:
    • 使用 xgboost 算法對模塊中含有邏輯的視覺特徵節點進行識別,相較於隨機森林算法在我們的數據集上表現更優越
    • 適用於子組件視覺特徵足夠明顯,邏輯組件具有一定複雜性的場景
    • 物料識別器本質是一個分類器,只告訴管理員某個節點是某個邏輯的載體。而不會告訴更多信息
    • 當 UI 物料識別器不滿足預期時,可以使用 設計稿注入協議 來進行此條邏輯的兜底

2. NLP 文本識別器

  • 特點:
    • 基於ALiWs 的分詞算法和樸素貝葉斯多分類實現文本分類模型。對您輸入的文本樣本進行訓練,有助於您對自己問題域下文本進行有效歸類。
    • 當您擁有大規模文本體量時,推薦用此方法進行文本的分類
    • 含有 內置識別結果,涵蓋不方便走文本NLP訓練鏈路的一些常用分類。比如:價格、原價、商品圖、白底圖等。

3. 自定義函數識別器

  • 特點:
    • 當目標邏輯可以通過 javascript 代碼 分析樣式、結構、文字等信息的方式識別出時使用
    • 在沒有樣本訓練 UI物料識別器 和 NLP文本識別器 的情況下,它是一個比較不錯的邏輯庫建設方案
    • 函數識別器可接收用戶傳參來做邏輯決策。比如 天貓 業務場景下對於埋點有兩套截然不同的邏輯表述,我們可以編寫兩個埋點邏輯,在各自的識別函數裡做二選一。除此之外,函數識別器可以攫取組件樹信息,給邏輯表達器提供更為強大的邏輯上下文

4. 默認識別器:

  • 特點:
    • 默認邏輯會被所有模塊應用,它的邏輯識別結果永遠為 true
    • 用於一些視覺層面沒有特徵的、較為通用的邏輯
    • 多與 “開發者干預” 配套使用,由開發者決策是否使用
    • 默認識別器無法獲取組件樹信息,如果有攫取信息的需求請移步 函數識別器

5. 正則識別器

是 NLP 的正則分析版,能力是 NLP 識別的子集。

邏輯表達器一覽

邏輯表達器是多個抽象化的子表達器組合的結果。我們將一個邏輯的實現方式拆解為最細粒度的可視化操作,通過分析此邏輯的具體實現方式,依次在後臺配置表達式,進行邏輯組裝。當識別器告知表達器當前邏輯激活時,則自動化實現該條邏輯的代碼。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(邏輯表達器功能劃分)

1. 視圖子表達器

  • 可以處理視圖層面的變更,能力極強,理論上可以覆蓋其他所有表達器的能力。未來 imgcook 希望對視圖操作也進行可視化配置,所以希望視圖表達器只關注視圖層面的變化,職責劃分明確,不要涉足其他表達器的能力範疇
  • 此表達器接收一個被 vm 執行的視圖處理函數

2. 數據綁定子表達器

  • 可以新增一條標準數據綁定,自動去重。大部分時候都需要藉助邏輯上下文內的屬性做動態表達
  • 此表達器接收一條數據綁定的配置

3. 事件綁定子表達器

  • 可以新增一個事件綁定,此事件會默認帶一個事件執行句柄,每個事件執行句柄內部可以用函數算子填充流程。
  • 此表達器接收一條事件綁定的配置

4. 函數算子子表達器

  • 構造一個自定義方法,並決定在哪個句柄裡調用。一般來說,函數算子只能在事件執行句柄和生命週期函數的流程中被調用,並通過排序和是否有返回對象來控制流程。
  • 此表達器接收一個函數的配置,內容可使用 xtemplate 語法編寫

5. 依賴管理子表達器

  • 在前幾個子表達器需要引入三方依賴的時候使用
  • 此表達器接收一個依賴的注入

落地成效

雙11邏輯場景建設

本次雙11模塊的開發中,基於本文提及的智能邏輯鏈路,imgcook 構建出了一套淘系營銷活動獨有的業務邏輯場景。內置了基於 淘系營銷視覺規範的邊距設置邏輯、基於淘系營銷埋點規範的埋點邏輯、基於 rax-hooks solution 的模塊渲染拆行邏輯等 默認邏輯。
除此之外,結合文本NLP、UI 物料分類算法等識別器提供的智能化能力,配置了大量的數據綁定、組件識別的邏輯,當開發者視覺稿中含有此類特徵時會自動將邏輯代碼運用到結果上。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 雙11邏輯場景【內部版】)

雙11邏輯還原指標

根據統計,2019 雙11有 78.94% 左右模塊使用 imgcook 業務邏輯生成鏈路,生成的模塊代碼有 79.34%  數量留存至此次還原之後的上線代碼中,平均命中的業務邏輯數量約為 14,也就是說平均每個基於 D2C 新鏈路開發的新模塊幫開發者少寫了至少十幾條邏輯。
在弱邏輯的靜態 UI 的模塊上,相關指標更高。以下方模塊舉例,基本可達到一鍵還原至可提測狀態,大大減輕了開發者的工作量。

前端代碼是怎樣智能生成的業務邏輯智能生成篇

(D2C 雙11邏輯命中示例【內部版 imgcook WEBIDE 開發鏈路】)

未來展望

當前不足

在雙11 落地的過程中也暴露了很多問題,比如流程不夠友好,淘系模塊開發流程是 需求->設計稿->模塊開發->前後端聯調->模塊上線。作為一個為設計稿賦予邏輯,使其直接轉為可上線模塊的全新理念的體系,沒有為之預留的開發時間。當下我們通過加大人力在開發前提前介入來彌補上述不足,未來我們將會把需求和設計稿的產出過程都納入業務邏輯層範疇,對於可支持的模塊提供一站式研發閉環體驗。設計師負責設計UI,PD基於UI添加需求,開發負責在後臺維護可用邏輯。結合團隊未來趨勢,D2C 在業務邏輯領域的實戰經驗將在未來有效的助力整個體系。

未來計劃

D2C 智能邏輯體系已經驗證了自己的想法並邁出了堅實的一步,未來,邏輯智能體系2.0 將聚焦在以下幾個方向:

產品形態升級

如本文開始所述,Design + PRD 才等於需求。D2C 是一個基於設計稿的技術體系,我們將在未來接入需求 PRD 結構化能力,替代 imgcook 目前的人工干預鏈路,實現全鏈路零研發。

指標驅動優化

基於雙促模塊統計結果,我們產出了 代碼可用度 的概念,即 imgcook 產出的代碼占上線代碼的比例。未來,我們將擴展更多的邏輯識別器算法接入、提供更抽象易用的邏輯表達器、實現業務邏輯層內核的組織。 imgcook 將基於指標驅動開發,讓智能化生成的代碼與實際業務產生真實的碰撞,並最終朝著提供更優異的智能化服務而邁進。

Imgcook Studio

imgcook 編輯器內核升級。基於內核我們將衍生出營銷業務、社區業務、小程序業務等業務平臺,並將邏輯場景的建設擴展到集團級別,在更多的業務場景裡實現定製。最終實現前端智能化能力的穩定輸出。

小結

簡單來說,我們希望有 更強的智能化能力,更廣的服務場景,更高的提效訴求。使整個體系真正成為一個從視覺稿視圖推演並生成全部模塊邏輯的智能化服務。從前端編碼佔比 79.34% ,到前端“零研發”,到需求“零研發”,最終到整個需求的“零投入”。


更多推薦:

前端代碼是怎樣智能生成的業務邏輯智能生成篇


歡迎加入我們: [社招/校招] [杭州] [阿里淘系技術部-頻道與 D2C 智能] 前端招聘:此時此刻,非我莫屬!

相關文章

Android主流三方庫源碼分析(六、深入理解Leakcanary源碼)

還不會七大排序,是準備家裡蹲嗎!?

Java併發原理抽絲剝繭,讀寫鎖ReadWriteLock實現深入剖析

SpringBoot要怎麼學?要學哪些東西?要不要先學SSM?鬆哥說說看法