作者：景莊
本文主要談一談網易雲音樂大前端團隊在面向模式化研發場景的低程式碼體系的建設思考和實踐。本文將會從當前我們所面臨的業務研發問題出發，談一談我們對於構建低程式碼研發體系的思考，進而介紹我們正在構建的同時支援 LowCode 和 ProCode 線上研發的線上快速研發能力。
業務研發現狀
先看下的我們的業務現狀。伴隨著業務的快速發展，出現了大量的平臺化產品，其中公共技術，質量保障，資料智慧相關的平臺有 40 多個，另外雲音樂主站，Look 直播，音街 還有大量的 CMS 平臺，和各類的 web 應用。並且，這個數字還在不斷的增加。而另一方面，無論是 CMS 平臺，還是活動類頁面都呈現著明顯的模式化特徵。這就意味著，開發者所面臨的大量的開發需求其實是重複類似的。
而我們的研發現狀是：大量的業務需求和低效的研發吞吐之間的矛盾。 我們不妨以不同視角來看下對於研發現狀的一些心聲：
產品同學經常抱怨：只是改個文案，前端卻需要排 2 周，還要合併需求釋出，怎麼能這麼低效；
後端同學經常會碰到：一些內部系統體驗不好，要改 UI，得找前端資源來排期，但前端沒有資源來做；
而前端同學則面臨的是：業務需求很多，每個都很急，簡單重複的需求，沒有設計稿，我很難有技術上的成長！
這裡我做了一個簡單的數學統計，在中後臺，前端人均支援平臺 3.3 個，平均交付週期在 2 周左右。右圖是一張來自 Muse 平臺第 20 期的需求清單，你會發現大量的需求是類似於 “改文案”， “加欄位” 等瑣碎細節，但這些問題卻需要多方協同，排期開發。
業務快速發展中的應用開發困境
為什麼會出現這樣的問題？我認為，可以從 4 個方面來拆解業務快速發展中的應用開發困境：
- 首先是 人員，一方面人員的流動性是難以避免的，另一方面，全棧型的開發者在當下是極為稀缺的。
- 其次是 變化 ，因為需求總是不斷在變化的，而迭代的週期卻越來越短。
- 第三是 複雜，一方面是技術體系變得越來越複雜，另一方面是研發依賴變的越來越複雜。
- 第四是 脫節，一方面是 需求與開發交付的脫節，另一方面是長流程與快速交付的脫節。
從關注應用開發到關注業務的交付
我們該如何應對？我的思考是需要讓一線開發者 “從關注應用的開發過程轉移轉向關注業務的交付過程” 。
傳統的業務開發過程我認為是一種線性的應用開發過程，需要經歷需求溝通，開發測試，再到釋出部署幾個環節，這個過程往往依賴多個工種在不同環節的專業分工，所以存在較高的溝通協作成本。並且開發者會過多的關注於靈活分散的本地開發工具，以及複雜的 web 應用架構，從而忽視了業務交付本身。
我認為，理想的開發過程應該是非線性，業務的變化，可以被快速的響應，多種研發角色都能低成本的使用低程式碼的方式介入到交付過程中。而這依賴於標準化和整合化的快速研發能力，以及更加輕量可控的 web 應用架構。
雲音樂線上快速研發交付體系
基於這樣的思考，我們一致認為需要構建一套快速研發交付體系來應對業務的變化。通過這套體系，我們可以去有效串聯公司現有的設計規範，開發模式，開發工具，和基礎研發設施。於是，我們在雲音樂技術中心立項了 “探戈低程式碼” 專案，探戈是一種優雅的雙人舞蹈，隱喻我們致力於為業務研發交付帶來的全新體驗。
雲音樂探戈低程式碼專案的核心優勢包括三個方面：
- 基於原始碼的視覺化搭建能力：它提供了從原始碼到原始碼的視覺化搭建體驗，不依賴特定的 DSL 和也沒有私有的搭建協議，做到與前端框架無關，支援 LowCode & ProCode 雙模式線上開發能力。
- 與既有研發設施無縫整合，提供一鍵應用建立和釋出部署能力：能對前端部署平臺，對接版本控制系統 Gitlab，並完全複用現有的物料體系。
- 提供對接契約聯調和模型驅動的能力：支援與雲音樂現有的契約聯調模式對接，提供設計器內的自動化聯調能力，並藉助後端後設資料中心的應用介面模型資訊構建自動化的頁面生成方案。
傳統低程式碼搭建方案的弊端
在講雲音樂的低程式碼的技術方案前，我們不妨首先分析下傳統低程式碼搭建方案所存在的問題：市面上絕大部分的低程式碼方案都可以用下面這張圖來進行描述。核心在於將檢視邏輯轉換為 頁面描述 邏輯，在此基礎上構建 節點模型和屬性模型，進而藉助對模型的操縱變更來修改 檢視邏輯。
這裡的問題在於，搭建引擎的設計者通常需要首先去定義這裡的 頁面描述協議 ，通常採用 JSON 的方式進行描述，受限於特定的業務場景和開發者的個人喜好，這裡的協議設計存在非常多的不確定性因素，很容易導致協議的不一致性和後期的維護問題，由於需要與程式語言進行對等對映，這種私有的搭建協議方案，也很難做到圖靈完備。
簡單總結一下，我認為這類傳統的低程式碼搭建方案有三個較為明顯的弊端：
- 採用私有的搭建協議，導致協議設計成本高，難以長期維護，難以做到圖靈完備。
- 依賴特定的 DSL 方案，使得物料一定程度上受限於特定的搭建方案。
- 由於上述兩個原因，導致只具備單向轉碼能力，一旦輸出原始碼，過程不再可逆。
雲音樂基於原始碼的低程式碼方案
我們需要重新思考低程式碼搭建的協議設計問題，我們期望新的搭建協議需要足夠通用且易於理解，易於維護，甚至不用維護，易於操縱，並且能夠做到與前端框架無關。這個時候，我們想到了 AST（Abstract Syntax Tree），也就是程式語言原始碼的抽象語法樹，它用於表示原始碼結構的結構化描述。對於 JavaScript 語言而言，Babel 已經提供了面向 JS 語言的 AST 解析和生成能力，藉助於 Babel 的工具函式可以很容易的實現對原始碼節點的操縱和變更。
因此，在探戈低程式碼體系的視覺化搭建模型，我們採取的核心思路是：將原始碼解析為 AST ，在 AST 的基礎上進一步抽象和建立 檔案模型 和 節點模型，通過將檢視的拖拽配置行為轉為對 AST 的操縱和修改，進而將變化後的 AST 重新還原為原始碼。
LowCode & ProCode 雙模式實時切換
由於採用了完全基於原始碼的低程式碼搭建方案，在雲音樂內部構建的低程式碼平臺能夠同時提供 LowCode 和 ProCode 兩種研發模式，並且兩種模式中使用者的行為可以做到完全對等，使用者在設計檢視中的行為都會實時的同步到原始碼中，而原始碼的變更也可以實時的反映在設計檢視中。藉助於這種雙模式切換的能力，可以為一些進階場景提供更加靈活的線上研發體驗，並且，使用者在本地建立的原始碼專案也可以採用相容模式線上繼續開發。
與既有研發設施無縫整合
對於雲音樂的探戈低程式碼體系而言，在構建了 LowCode & ProCode 混合研發模型的基礎上，我們更加關注於與內部既有研發設施的整合上，從而進一步加速業務研發效率。探戈平臺提供了與 Gitlab 整合能力，使用者的每一次儲存操作都會將原始碼寫入到 Gitlab 的倉庫中；提供了與研發平臺的整合能力，可以一鍵快速建立應用，並可以一鍵部署和釋出應用；提供了與物料中心的整合能力，可以快速消費團隊內的二方，三方元件包；提供了與資料閘道器的整合能力，藉助於契約聯調模式，可以線上快速生成頁面；提供了與 D2C 的整合能力，支援從設計稿一鍵生成程式碼。
契約聯調和模型驅動能力
雲音樂的研發體系中建立了契約聯調的研發模式，提供了介面契約及其變更管理，介面自動化 Mock 能力，並且藉助程式碼自動化分析中心提供的應用的基礎後設資料，可以為探戈低程式碼平臺提供強有力的應用資料模型和服務支援。目前雲音樂的探戈低程式碼平臺已經初步構建基於契約聯調模式的線上自動化聯調能力，基於應用後設資料的模式化頁面自動化生成能力也在推進過程中。
One More Thing：基於原始碼的低程式碼引擎
在構建雲音樂探戈低程式碼體系的過程中，我們將核心的低程式碼能力進行下沉，抽象並構建了基於原始碼的低程式碼引擎的生態體系，一方面為平臺側能力提供了更加解耦和易於維護的底層方案，另一方面藉助與多方團隊合作來共建公司內的低程式碼生態體系。
藉助於探戈低程式碼引擎，在內部我們重新啟動一個低程式碼專案時，只需要 30 行程式碼就可以輕鬆的完成整個低程式碼專案的前端實現，開發者可以將更多的關注點放在服務整合和使用者功能上，從而極大的降低了內部的試錯成本。
小結
最後，簡單回顧下我們在雲音樂正在構建的低程式碼研發體系。為了應對業務研發過程中的問題和挑戰，結合雲音樂的業務研發現狀和技術體系現狀，我們認為採用低程式碼的方式來構建線上快速研發交付能力，可以有效的應對模式化業務研發場景中的問題，並且可以簡化前端開發流程，賦能多種業務研發角色，為此我們構建了雲音樂探戈低程式碼研發體系，該方案完全基於原始碼方案，不採用私有搭建協議，不依賴特定的 DSL 方案，並且支援與內部既有的基礎研發設施進行無縫整合，來加速模式化業務研發的效率。
在後續，我們將繼續帶來更進一步的有關雲音樂低程式碼能力建設的技術分享。
本文釋出自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們 grp.music-fe(at)corp.netease.com！