詳解ZStack Cloud v4.0：前端架構(gòu)探秘之低代碼開(kāi)發(fā)

　　日前，ZStack Cloud v4.0發(fā)布，相信大家看了都有一種煥然一新的感覺(jué)，本輪發(fā)布最大的變化是 UI 端進(jìn)行了完全的重寫，技術(shù)棧由原來(lái)的 Vue 體系升級(jí)到 React，其中采用了一些全新的技術(shù)，如 UMI、GraphQL、微前端、低代碼開(kāi)發(fā)等，接下來(lái)，我們一起來(lái)探秘ZStack Cloud v4.0 漂亮 UI 的技術(shù)原理，本文將為您解讀：低代碼開(kāi)發(fā)。

　　一、為何要引入低代碼開(kāi)發(fā)？

　　在新版 UI 中，所有列表頁(yè)、權(quán)限控制、主題外觀、界面文字都不是由前端開(kāi)發(fā)人員手動(dòng)編寫的，而是借助低代碼開(kāi)發(fā)平臺(tái)根據(jù)響應(yīng)的配置自動(dòng)生成。低代碼開(kāi)發(fā)是最近非�；鸬母拍�，本質(zhì)上非編程人員利用工具按照自己的想法生成可運(yùn)行代碼。在本文中，非編程人員特指 ZStack 的產(chǎn)品、設(shè)計(jì)、文檔、測(cè)試等角色，當(dāng)然低代碼開(kāi)發(fā)也可以服務(wù)于開(kāi)發(fā)人員，標(biāo)準(zhǔn)化輸出代碼，降低編程中的低級(jí) bug，提升產(chǎn)品質(zhì)量和開(kāi)發(fā)效率。

　　隨著項(xiàng)目的進(jìn)展，越來(lái)越多的非編程問(wèn)題暴露出來(lái)，設(shè)計(jì)師提供給開(kāi)發(fā)人員的雖然在樣式上是高保真，但其中的邏輯細(xì)節(jié)并沒(méi)有暴露出來(lái)。以云主機(jī)為例，云主機(jī)在不同 License 下顯示的字段、操作、創(chuàng)建時(shí)涉及的約束條件、云主機(jī)列表需要支持搜索和排序的字段、中英文版本、不同主題色版本等等，設(shè)計(jì)稿是靜態(tài)的，而最終實(shí)現(xiàn)的系統(tǒng)是動(dòng)態(tài)的，這中間會(huì)有很大的 gap。在傳統(tǒng)的開(kāi)發(fā)模式中，彌補(bǔ)這些 gap，完全依賴于開(kāi)發(fā)人員的想象以及手頭有限的素材，而在全新的低代碼開(kāi)發(fā)模式中，產(chǎn)品、設(shè)計(jì)、文檔、測(cè)試也可以利用各種工具介入開(kāi)發(fā)工作，將自己的想法直接落地，而無(wú)需告知開(kāi)發(fā)。

　　二、ZStack如何引入低代碼開(kāi)發(fā)？

　　目前在前端低代碼開(kāi)發(fā)領(lǐng)域，走在前沿的當(dāng)屬阿里淘系團(tuán)隊(duì)的 imgcook，imgcook 利用開(kāi)源的深度學(xué)習(xí)框架 TensorFlow 針對(duì)設(shè)計(jì)稿進(jìn)行像素級(jí)分析，結(jié)合系統(tǒng)代碼庫(kù)生成 DSL，最后經(jīng)過(guò)程序員修正后生成可運(yùn)行的代碼。筆者曾和 imgcook 團(tuán)隊(duì)溝通過(guò)，詢問(wèn)是否能生成復(fù)雜的企業(yè)級(jí)管理系統(tǒng)代碼，得到的答復(fù)是因?yàn)轭愃圃朴?jì)算這種帶有復(fù)雜業(yè)務(wù)邏輯的，因?yàn)橛写罅康募s束條件，無(wú)法通過(guò)設(shè)計(jì)稿來(lái)直接生成代碼，目前 imgcook 主要應(yīng)用于 C 端領(lǐng)域。既然高大上的 AI 行不通，那我們只能另辟蹊徑，采取更加簡(jiǎn)單有效的方式服務(wù)各個(gè)團(tuán)隊(duì)。

　　首先需要定義哪些是非邏輯功能，類似自定義列、操作項(xiàng)、權(quán)限、界面文字、主題外觀這些帶有配置屬性的都可歸類為非邏輯功能。非邏輯功能具有編寫容易但配置復(fù)雜兩大特征，每個(gè)配置項(xiàng)在程序中都代表了一個(gè)邏輯分支，一旦寫錯(cuò)，就會(huì)導(dǎo)致整個(gè)界面的展示不符合預(yù)期。

　　我們選取了在 3.x 開(kāi)發(fā)時(shí)期耗費(fèi)巨大精力開(kāi)發(fā)和測(cè)試的權(quán)限體系來(lái)作為低代碼開(kāi)發(fā)的突破口。3.x 的權(quán)限實(shí)現(xiàn)，是由開(kāi)發(fā)人員在代碼中添加大量 if-else 判斷來(lái)實(shí)現(xiàn)的，比如在社區(qū)版隱藏某個(gè)按鈕，就在這個(gè)按鈕上加一行 if-else 判斷，隨著分發(fā)的版本及賬戶體系愈來(lái)愈復(fù)雜，判斷邏輯也越寫越多，最終導(dǎo)致 bug 頻出，以致無(wú)法維護(hù)。

　　這種濫用 if-else 的做法顯然是不可取的，優(yōu)雅的解決方式應(yīng)該是類似防火墻的實(shí)現(xiàn)，被攔截對(duì)象和攔截策略解耦，UI 中的被攔截對(duì)象是頁(yè)面中一切可見(jiàn)元素，包含菜單、按鈕、表格列、字段等，而攔截策略又分為 OEM、License、角色等，高等級(jí)安全系統(tǒng)擁有多層防火墻，而 ZStack UI 的界面元素也可以根據(jù)當(dāng)前生效的策略進(jìn)行多層交叉控制。

　　三、 ZStack-Assist配置系統(tǒng)揭秘

　　基本原理清楚了，接下來(lái)就需要解決如何配置的問(wèn)題。在研發(fā)體系中，最明晰用戶需求的是產(chǎn)品經(jīng)理，而最清楚產(chǎn)品使用邏輯的是測(cè)試人員。一套權(quán)限配置下來(lái)是否能夠工作，不會(huì)阻斷正常的工作流，需要產(chǎn)品和測(cè)試共同協(xié)作，這里面開(kāi)發(fā)人員不參與任何配置工作，只是提供合適的工具將產(chǎn)品和測(cè)試的工作固化下來(lái)，這套配置系統(tǒng)稱為 ZStack-Assist。具體實(shí)現(xiàn)上分為數(shù)據(jù)采集、可視化配置系統(tǒng)、代碼生成引擎、Debug 模式四大塊。

　　在 ZStack-UI 正式發(fā)布版本中，總共有 1800 多個(gè)受控的頁(yè)面元素，疊加5種 license 和11個(gè)系統(tǒng)角色，總共最多會(huì)有接近 10 萬(wàn)個(gè)配置項(xiàng)，如果算上 OEM 定制版，數(shù)量只會(huì)更多。如果沒(méi)有低代碼開(kāi)發(fā)平臺(tái)，前端的工作量將是非�？植赖�，系統(tǒng)也處于不可測(cè)試的境地。為了方便產(chǎn)品和測(cè)試人員進(jìn)行配置，我們創(chuàng)造性的在 UI 中引入了 Debug 模式，當(dāng)開(kāi)啟時(shí)，UI 中所有的受控元素都會(huì)進(jìn)行標(biāo)注，鼠標(biāo)懸浮上去就可以跳轉(zhuǎn)到配置系統(tǒng)進(jìn)行配置，如下圖所示：

　　所見(jiàn)即所得的配置方式可以讓測(cè)試人員一邊測(cè)試，一邊修正配置集合，在傳統(tǒng)的開(kāi)發(fā)模式，測(cè)試需要等待開(kāi)發(fā)修正完，重新打包才能看到修正后的效果，通過(guò)配置系統(tǒng)解耦后，大大提升了整體的開(kāi)發(fā)效率。

　　綜上所述，低代碼開(kāi)發(fā)對(duì)于 ZStack-UI 絕不是錦上添花，而是伴隨著項(xiàng)目進(jìn)展產(chǎn)生的必然需求。另一個(gè)典型需求是列表的自定義，我們 UI 中八成以上的界面都是列表，以及針對(duì)列表的相關(guān)操作，如下圖所示：

　　我們雖然封裝了完善的列表組件，可以讓開(kāi)發(fā)人員以對(duì)象形式定義列表顯示的字段，但在實(shí)際開(kāi)發(fā)中，由于每個(gè)人理解不同，類似列寬、字段順序、過(guò)濾、排序定義的千差萬(wàn)別，不僅造成界面展示的不美觀，還會(huì)造成功能上的缺失，列表的數(shù)據(jù)拉取需要編程獲得，但列表的具體展示形式則由產(chǎn)品、設(shè)計(jì)共同維護(hù)。

　　如果以傳統(tǒng)的方式解決這個(gè)問(wèn)題，需要借助腦圖梳理信息，梳理后需要多方確認(rèn)，最終再由開(kāi)發(fā)人員進(jìn)行編碼。如果中途變更，還需要同步修改并告知開(kāi)發(fā)人員改動(dòng)，最后再由測(cè)試人員重新測(cè)試，這個(gè)溝通鏈路非常長(zhǎng)，中間任何一個(gè)環(huán)節(jié)都可能出現(xiàn)信息不同步，對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，可能只需要改 1 行代碼，卻需要反復(fù)溝通半天時(shí)間。

　　既然操作的對(duì)象是表格，很自然的想到了利用釘釘自帶的表格功能，釘釘表格支持多人協(xié)同編輯，也可以非常方便的鎖定并回溯歷史。為了維護(hù)構(gòu)建表格所需的原始數(shù)據(jù)，我們創(chuàng)建了一個(gè)模板，稱為字段配置表，如下圖所示：

　　該模板的每一列都有相關(guān)的維護(hù)角色，由不同的人來(lái)維護(hù)，同時(shí)每列還有一個(gè) key，代碼生成引擎會(huì)讀取行列內(nèi)容，根據(jù) key 生成相關(guān)代碼。以云主機(jī)為例，填充后的內(nèi)容如下：

　　生成后的代碼如下(云主機(jī)列表生成的代碼約800行，只截取片段)

　　通過(guò)上圖可以看出，生成的代碼是非常工整的，由于是根據(jù)配置基于模板自動(dòng)生成的，可以保證統(tǒng)一的風(fēng)格。云主機(jī)的表格數(shù)據(jù)不僅存在于主列表中，還附屬在物理機(jī)、云盤、網(wǎng)絡(luò)、安全組等資源的詳情頁(yè)中，當(dāng)資源創(chuàng)建需要選取云主機(jī)時(shí)，也會(huì)彈出云主機(jī)列表，在新版 UI 中，資源的所有列表頁(yè)都共用了同一個(gè)組件，細(xì)心的讀者如果觀察 ZStack-UI 界面，會(huì)發(fā)現(xiàn)雖然云主機(jī)出現(xiàn)在很多地方，但其中顯示的列數(shù)量、種類是不同的，這些都是通過(guò)上述的配置表來(lái)分開(kāi)管控的，產(chǎn)品經(jīng)理可以隨心所欲的定制界面，而無(wú)需告知開(kāi)發(fā)去修改。

　　不僅列表可以通過(guò)配置生成，界面中所有的操作按鈕、狀態(tài)等也可以用配置的方式生成代碼，此處不再一一贅述

　　最后界面中除了表格數(shù)據(jù)，用戶看到最多的應(yīng)該就是各種提示性文字，定義清晰的界面文字可以幫助用戶快速上手，減少誤操作的次數(shù)。為了支持國(guó)際化，在 ZStack-UI 中，界面上任何可見(jiàn)文字都分配了一個(gè)唯一性 key，如云主機(jī)的 i18n key 為 vm，云盤為 volume，相同的文字 key 也一樣，key 由開(kāi)發(fā)人員在編碼的時(shí)候定義，通過(guò)掃描腳本收集后導(dǎo)入配置系統(tǒng)，再由文檔團(tuán)隊(duì)潤(rùn)色和翻譯，流程和上文的權(quán)限體系一致。

　　在 3.x 開(kāi)發(fā)時(shí)期，如果文檔、售后或者客戶發(fā)現(xiàn)界面描述不正確，一般采用截圖提 Jira 的方式，交由開(kāi)發(fā)人員修改，這種方式費(fèi)事費(fèi)力，修改完畢后還需要打包交付測(cè)試驗(yàn)證。而采用配置系統(tǒng)，開(kāi)啟 Debug 模式后，文檔同學(xué)在修改完畢后，界面會(huì)立即生效，再也無(wú)需等待，所見(jiàn)即所得。

　　通過(guò)各種低代碼開(kāi)發(fā)工具生成的代碼約為 15萬(wàn)行，這些是跨團(tuán)隊(duì)共同協(xié)作的結(jié)晶。雖然15萬(wàn)行只有整個(gè) UI 代碼的 1/4，卻完成了界面中所有列表、按鈕顯示，權(quán)限控制、主題、多語(yǔ)言等功能，并大大減少了測(cè)試量，而后者正是 ZStack 4S 體系的根基所在。

　　關(guān)于ZStack Cloud v4.0

　　日前，ZStack Cloud v4.0驚艷登場(chǎng)!這是一場(chǎng)關(guān)于UI的革命性升級(jí)，它不僅采用了全新UI設(shè)計(jì)系統(tǒng)，對(duì)500+組件實(shí)現(xiàn)了重構(gòu);同時(shí)，它還擁有領(lǐng)先的低代碼、Micro Frontend(微前端)技術(shù)加持，致力于帶給用戶最舒適友好的使用體驗(yàn)!不僅如此，ZStack Cloud v4.0還推出了20多項(xiàng)新功能，自定義運(yùn)維首頁(yè)、企業(yè)管理、彈性裸金屬、云平臺(tái)監(jiān)控等等統(tǒng)統(tǒng)都上新!點(diǎn)擊觀看ZStack Cloud v4.0精美展示~點(diǎn)擊閱讀原文立刻試用!