愛奇藝是如何在活動中臺實踐低代碼的？

作者 ｜ 田曉旭

根據海比研究數據表明，中國低 / 無代碼市場規模 2020 年爲 19 億元，預計未來五年將保持高速增長，2024 年將達到百億量級。爲什麼低代碼市場突然受到了如此大的關注？企業內部又是如何實踐低代碼的？… 爲了解答這些問題，InfoQ 記者採訪了愛奇藝技術專家慕佑，他目前主要從事用戶增長、用戶互動相關 H5 研發工作及活動中臺建設工作。

1 突然火爆的低代碼到底是什麼？

2014 年，Forrester Research 研究機構正式提出了低代碼的定義，即利用很少或幾乎不需要寫代碼就可以快速開發應用，並可以快速配置和部署的一種技術和工具。2017 年，Gartner 創建了一個新門類，提出了 aPaaS(應用程序平臺即服務) 的概念，低代碼開發平臺在市場上獲得了廣泛關注。

以上是 Forrester Research 和 Gartner 等研究機構眼中的低代碼，那麼，開發者眼中的低代碼是什麼樣子？在慕佑看來，低代碼是一種新的開發模式，基於業務邏輯，通過一定的技術組件沉澱，在類似業務場景下可以通過更便捷的形式直接複用，以達到在不寫代碼或者少寫代碼的低成本基礎上，實現業務開發效率最大化的目的。這種開發模式通常會依託於一個圖形化的開發平臺，這可以理解爲低代碼開發平臺（LCDP）。

初級的低代碼開發可以追溯到早期的圖形化開發，通過在可視化區域添加一些圖片，設置超鏈接，設置文字大小格式等方式最終生成一個網頁。隨着互聯網的發展，業務系統的產品形態迅猛發展，簡單的圖片展示已經不足以支撐業務發展，頁面中有了更多更復雜的交互形式，這就對開發工作提出了更大的挑戰。因此，此時的低代碼開發也隨之變得更加複雜，會涉及到業務更深層次的邏輯，比如與服務端數據、邏輯流程相關的各種複雜考量。

據 Gartner 的研究預測，到 2024 年低代碼平臺將被應用於 65% 的應用程序開發。爲什麼低代碼會突然流行呢？慕佑認爲，當前互聯網發展迅猛，市場上各類產品競爭激烈，在市場變化快速、業務要求緊急的情況下，業務需求與開發資源之間的矛盾不斷加深，有限的開發資源以及巨大的工作量導開發者很難及時響應需求，容易錯失市場良機。因此，開發者迫切希望能夠找到提高開發效率的有效方法來解決這個窘境，而低代碼恰好就是這樣一種新的增效開發模式，自然引發了更多關注。

慕佑表示，目前市面上的低代碼產品可以分爲以下幾類：

• 配置類：把業務邏輯或者頁面模板抽象成 JSON 語法，後期只要開發維護編輯 JSON 內容就可以生成新的內容的頁面。

• 組件拖拽類：這個大類還可以再細分成兩個分支：第一個分支是基於業務抽象出基礎組件，把這些組件集成到一個低代碼平臺，開發人員甚至是非技術同學可以直接通過拖拽組件來生成頁面。這種方法靈活便捷，成本也低。第二個分支是一種更深入的做法，通過封裝更原子化的邏輯功能組件，然後通過拖拽對邏輯進行重新編排以適應更多變的需求。

• 自動生成類：類似於 imgcook 這種的工具可以直接把設計稿轉成前端頁面結構代碼，再進行邏輯封裝。

當然業界也有一些低代碼平臺的分類方式，比如可分爲四個類型：場景應用型、產品研發型、平臺生態型、技術賦能型。

總而言之，低代碼開發適用於可以從過往案例中提煉抽象出更多高複用組件，場景可抽象成基本模型的業務。其基本模型中可以是封裝的組件或 api，比如相對固定的產品形式：產品介紹、活動頁面等。

2 愛奇藝活動中臺的低代碼實踐

根據 KPMG 的一項調查發現，在過去一年中，企業組織的分散加速了低代碼的發展。自 COVID-19 爆發以來，將低代碼開發平臺列爲最重要投資的高管人數從 10% 增長到了 26%，增加了兩倍。

那麼，企業內部應該如何實踐低代碼開發呢？慕佑表示，一個比較通用的低代碼實踐可以分爲五個階段：

• 初期的業務調研：看當前遇到的問題適不適合應用低代碼平臺來解決；

• 基於現有業務抽象可複用的組件單元；

• 將沉澱積累的組件及工具集成進低代碼平臺；

• 低代碼平臺負責更好的編輯體驗，具備對各個組件組合渲染的能力；

• 產出業務成果：生成可用頁面、邏輯編排並應用到具體業務中，實現快速迭代、體驗優化等，以提升整體產研效率。

慕佑所在的團隊從 2019 年第三季度開始落地低代碼實踐，當時愛奇藝對的活動業務開發有非常多重複性工作，只要接收到了一個需求，無論規模大小，全部是定製開發，不僅效率低下，也浪費資源。長期重複性的工作會讓開發人員失去耐心和激情，因此技術團隊從那時起，就有意識地積累通用的組件，並通過開發頁面模板讓運營能夠直接配置生成活動頁面，經過慢慢發展，通用組件越積累越多，就變成了一個平臺。

愛奇藝內部的很多技術團隊都基於各自業務領域進行了低代碼實踐，實現方式各有不同。慕佑所在的技術團隊結合活動業務搭建了活動中臺，整個中臺基於 React 框架開發，低代碼拖拽部分使用了 React-dnd 、React-rnd 等插件進行拖拽縮放等操作。

活動中臺最重要的一個功能是打通活動生命週期的完成鏈路：活動的搭建——智能投放——數據分析。在活動搭建環節，技術團隊在活動中臺集成封裝了活動業務中最爲高頻複用的組件，包括圖文混排、多種形式的抽獎、投票、評論、播放等幾十個組件，運營同學自己就可以直接在中臺拖拽組件生成各類活動頁面。據瞭解，目前這個平臺已經被愛奇藝的 40+ 個業務線使用，上線一年累計生成活動頁面 4000+，極大的提升了運營效率。

3 低代碼實踐的三個關鍵問題

雖然開發者在實踐低代碼過程中會因爲業務系統、原有技術棧的不同，而導致實現方案不一致。但是在實踐過程中，大家都會面臨一些共性問題，本文我們列舉了三個共性的關鍵問題。

第一個問題是低代碼平臺如何與現有的系統做整合？慕佑表示：“低代碼平臺的主要功能應該是基於現有開發模式抽象積累出的組件集成，所以基礎能力是來源於現有開發體系的，開發者應該合理地基於現有開發體系，將產出的組件更便捷地同步到低代碼平臺，同時低代碼平臺最終產出的效果需要與公司其它系統打通，直接進行投放。通過這種方式將整個鏈路串聯起來。”

第二個問題是如何判斷哪些功能適合整合成低代碼平臺上的一個模塊？慕佑表示：“我們通常會選擇將一個具備完整邏輯的功能模塊抽象成一個最小組件來整合到低代碼平臺上。具體來說，這個最小單元的功能基本可以實現閉環，而不需要依賴其他功能。有時，業務中也會涉及到一些組合形式的組件，這時可以以組合的形式落地到平臺。”

第三個問題是低代碼平臺實踐過程中最關鍵的是什麼，什麼樣的低代碼平臺纔是完美的平臺？慕佑表示：“低代碼平臺實踐過程中最關鍵的是要從業務出發。因爲實現業務需求是最終目標，開發只是實現的過程，因此關鍵點在於深入瞭解業務特點並能夠判斷出是否適合低代碼。最完美的低代碼平臺一定是讓使用者（無論是開發人員還是運營人員）都能夠以更便捷舒適的方式實現更多場景的業務需求，當然這是一個需要長期積累優化的過程。”

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。