在保險做低碼的探索之路
?????♀? 編者按：本文作者是螞蟻集團前端工程師度城，分享了在螞蟻保險場景下，進行低代碼探索的經(jīng)驗和思考。
前言
2021 年 10 月份，我開始了在螞蟻保險場景下的低碼建設之路，一晃眼滿滿的一年過去了，不管結果如何，從 0 到 1 的產(chǎn)品建設過程，也收獲了很多的經(jīng)歷和想法，通過這篇文章做一個總結，也算對自己這些年建設低碼研發(fā)方向的踩過的坑做一些記錄，同時給其他同學后續(xù)如果要做一些基礎的技術項目做一些參考。
從電商 C 端到保險產(chǎn)品 C 端
電商 C 端場景
從上面的介紹中說到，這次來螞蟻瞄準建設的也是 C 端場景，我之前在 1688 主要做的是導購場景，所謂導購場景，就是電商最常用的商品列表，看了下面的圖大家就知道了
電商場景每隔一段時間需要進行大促，為了讓用戶可以保持新鮮感，設計經(jīng)常會對會場的主題，卡片的樣式做一些變化，這樣就導致每次大促都需要重新開發(fā)商品的 offer 卡片，對接數(shù)據(jù)也會有一些區(qū)別，所以通過低碼我們抽象了一些容器組件，例如樓層，tab 組件，通過低碼編輯器進行商品 offer 卡片的拖拽和開發(fā)，大幅提升了每次大促的活動頁開發(fā)速度，同時會場列表通常邏輯也比較簡單，我們通過該方法再大促中大量復制，成果顯著。
保險產(chǎn)品 C 端
剛來到螞蟻的時候，我希望可以直接把在 1688 導購場景的經(jīng)驗復制過來，我簡單看了下商業(yè)險最典型的幾個投保場景，好像也挺簡單，幾個頭圖組件+一些交互的表單+產(chǎn)品圖片列表，表單組件抽幾個典型物料，基本就搞定了，so easy ???。
但是，當我深入去看了一下上面的代碼以后，頓時心涼了半截，整個頁面的結構看似簡單，但是組件和組件之間需要進行聯(lián)動，并不是單純的像導購頁面組建累積起來就行，同時每個投保頁的邏輯異常復雜，光一個通用的投保邏輯就有上千行的代碼,這還不包括一些產(chǎn)品的特殊邏輯等
思考如何設計平臺
從上面分析可以看到，保險投保場景，比導購場景復雜的多，如果直接套用原來的定位和方案，明顯是不適合的，低碼場景在這些邏輯復雜的場景中是否還適用？擺在我面前有兩條路
直接放棄高復雜場景，重點轉(zhuǎn)向低復雜的一些場景（例如營銷、簡單承接頁）
繼續(xù)攻堅高復雜場景，能很好的承接保險投保場景。
其實從投入 ROI 來看，似乎第一條路更容易達成結果，簡單的復制一下之前的經(jīng)驗，搭建一下平臺，就可以完整覆蓋低復雜的場景，從而更好更快的拿到結果。但是再深入分析，我們發(fā)現(xiàn)第一條路也不好走，原因如下
經(jīng)過我們的 FY21 商業(yè)險開發(fā)場景調(diào)研，發(fā)現(xiàn)商業(yè)險內(nèi)除營銷業(yè)務以外，其他場景中高復雜度的場景占據(jù)?80%?以上
非營銷場景商業(yè)險業(yè)務
另外通過我們前期做的一些宣講，大家對平臺的能力的可維護性有一定的擔憂，假設我們定位低復雜場景，業(yè)務一期剛好也是低復雜的頁面，但是萬一 二期、三期業(yè)務的復雜度增加了，那是不是平臺就承接不了了？這些問題如果不能得到很好的解答的話，就算真的是低復雜的場景，開發(fā)者也不愿意去開發(fā)，誰會把自己的業(yè)務放在一個能力受限的平臺上去研發(fā)呢？除非是那些一次性的頁面用完就扔的頁面，但是這些量又有多少呢？
結論：如果只專注做低復雜的場景，基本就固定了平臺的上限和規(guī)模，業(yè)務的量擺在那里。同時由于平臺定位低復雜場景，不具備中高復雜場景的可持續(xù)迭代能力，造成了開發(fā)者對后續(xù)迭代的顧慮和不信任，后續(xù)可預見推廣舉步維艱。
所以基于上述思考，我們平臺定位必須具備高復雜場景的可維護能力，這樣才能保證開發(fā)者在上面開發(fā)以后，不用擔心后續(xù)因為業(yè)務迭代變復雜以后因為平臺能力的問題導致無法迭代，提升開發(fā)者的信心。
如何提升平臺承接復雜需求的能力
我們仔細想一下，現(xiàn)有的前端技術框架是如何解決高復雜度下的維護問題的。大家現(xiàn)在都在使用 React，es6 的語法，但是如果大家接觸前端年代更加久遠的話，可以知道 Jquery、無模塊概念是如何編寫邏輯的，所以經(jīng)過這么長時間的發(fā)展，不管前端框架、技術如何變動，我們對其中兩點能力基本達成共識：
組件化：隨著前端的邏輯會越來越復雜，很多時候我們需要將頁面進行拆解，通過合理的設計規(guī)劃以后，我們將頁面拆成若干個組件，組件具備復用能力，通用的組件可以被其他頁面使用。
模塊導入：目前大家對 import 都已經(jīng)習以為常，但是最開始前端也是沒有的，后面就有 require.js、sea.js 等 AMD，CMD 方案，直到 es6 支持 import 語法后，前端的模塊化概念被作為一項基本能力普及起來，有了模塊化以后，我們就可以拆分更細的粒度，將復雜的邏輯分塊分而治之，也可以引用其他以后的模塊，前端生態(tài)通過 NPM 包的形式，越來越完善。
基于上述兩點，我們在低碼整體設計的候?qū)⑦@兩點進行重點思考，分別通過物料系統(tǒng)和多文件優(yōu)化對上述兩點進行體現(xiàn)和實踐。
物料：物料就是低碼的組件庫，通過將通用部分的物料進行封裝，就可以讓低碼開發(fā)者在開發(fā)的時候直接在物料庫中選取對應的組件拖拽使用，其本質(zhì)就是使用已經(jīng)封裝好的組件，只不過在低碼這個場景，我們讓使用組件更加可視化，方便，開箱即用。
問題: 雖然通過物料模式可以實現(xiàn)Procode中組件的使用，但是物料的開發(fā)還是太麻煩了，需要在線下新增一個倉庫，需要通過特殊的配置和打包構建方式才可以在低碼編輯器中使用。
為了能進一步降低開發(fā)者的門檻，提升開發(fā)者開發(fā)物料的效率，我們在原有物料開發(fā)體系的基礎上，新增在線物料研發(fā)方案，將物料的研、配置、發(fā)布和輕研發(fā) needle 進行完整串聯(lián)，改變之前組件開發(fā)線下、低碼使用線上的割裂方式，通過全線上的方式提升研發(fā)的體驗
模塊導入：為了能夠模擬在低代碼代碼編輯器中可以進行模塊的導入，我們通過擴展低代碼代碼編輯器，實現(xiàn)了多文件處理、多模塊 require 等功能方案，通過強化原有的低碼代碼編輯器，提升了對模塊、文件的分塊處理，更加符合現(xiàn)在前端研發(fā)的方式
通過上述兩個改動，讓我們的平臺提升了對復雜應用的支持能力，能夠在組件和邏輯兩個維度進行拆解，有效的降低復雜頁面的接入難度。
業(yè)務試驗
在設計了上述能力后，雖然在功能上可以具備復雜應用的接入能力，但是是否在實際的研發(fā)中真正有效，還需要實踐進行說話，我們挑選了壽險的兩個新的投保場景（儲蓄型兩全、學平險）作為試驗，這兩個是全新的投保類目，在使用低碼接入的時候不用顧慮舊的改造影響，雖然新的改造必定會在后續(xù)的維護中和其他投保不一致，帶來額外的成本，但是我們思考的是只有我們在自己在實際的場景中進行深度的使用，才有一手的經(jīng)驗去進行改進，所以即使是在后續(xù)維護中帶來一定的兩套維護成本，我們也需要去進行嘗試。
儲蓄型兩全投保
學平險投保
雖然學平險由于最終業(yè)務問題沒有能夠正式上線，但是儲蓄型兩全如期上線，成為第一個通過布偶開發(fā)的投保頁面，并且維護了將近半年之久（后續(xù)開放統(tǒng)一遷移長江），在整個開發(fā)過程中，我們認為平臺的深度可維護能力是可以支撐復雜的頁面級應用的，核心的部分還是在投保的邏輯編寫和維護上，主邏輯將近 1700 行，對于一個低碼頁面來說可以說是比較重度了，我們在實操過程中也發(fā)現(xiàn)了不少問題
state 共享：頁面的模塊之間無法共享 state，由于投保的每個模塊都需要用到全局 state，需要有一套全局 state 的存儲讀取機制的框架。為此我們在多文件的基礎上額外設計了"插件"化方案，通過該方案相當于內(nèi)置了一個小型的 state 可讀寫的框架
如上面的例子，可以將邏輯拆成一系列插件，插件內(nèi)可以通過 ctx 實例操縱組件狀態(tài)，控制頁面渲染，每個插件負責一塊邏輯。
基礎物料的缺失：壽險投保的試算模塊中包含試算的表單組件，這一類組件用到 picker、級聯(lián)等基礎組件庫，我們對這些基礎組件進行補充，并且精心設計了物料的配置方式，力爭后續(xù)的使用可以做到開箱即用
金額選擇器物料?
?Picker 選擇物料
看到這里，也許你會有疑問?，既然需要寫這么多的代碼，那我用 vscode 不香嗎，用低碼的優(yōu)勢和價值提現(xiàn)在哪里？這個問題我們在上述投保頁用低碼研發(fā)的時候也做了重點的對比。我們使用下來，綜合覺得有以下幾點優(yōu)勢：
物料庫的使用，使用可 UI 交互的物料，和使用純代碼組件引入相比，具備一定的低門檻優(yōu)勢，這里需要有幾個前提：第一是物料需要夠全，在開發(fā)過程中反過來去寫物料這個時間是比較費時的，同時在那個時間的物料開發(fā)體驗又沒有能夠優(yōu)化好，導致間接的開發(fā)成本上升。第二是物料的配置需要有一定的設計，物料配置 != 組件 props
在設計物料配置的時候，需要將最常用的屬性，放在最前面，一些復雜的、使用頻率較低的屬性應該進行降級展示甚至屏蔽，保證用戶能在第一眼就可以使用到，并且不需要查詢額外的文檔，配合編排區(qū)域的UI實時展示，真正的做到開箱即用
整體一站式的研發(fā)體驗，通常我們在 procode 研發(fā)的時候需要拉倉庫代碼，安裝依賴包、本地編譯等等一系列操作，同時發(fā)布的時候需要提交代碼，合并、雨燕構建發(fā)布，這些操作每個節(jié)點雖然都不是非常耗時的節(jié)點，但是在整個過程中，線下、線上需要分開進行，同時在安裝、本地編譯等環(huán)節(jié)又容易出現(xiàn)包安裝依賴等問題需要通過一定的經(jīng)驗排查解決，無形中增加了一些門檻和成本，一站式的研發(fā)無需考慮這些環(huán)節(jié)的問題，因為這些都由平臺解決了，開發(fā)、構建、調(diào)試、發(fā)布僅需要按幾個按鈕就能解決（前提是平臺將這些功能做的比較完善），無論從研發(fā)門檻還是研發(fā)體驗來說都更勝一籌。
核心邏輯編寫，純代碼編寫體驗上 vscode 確實比低碼的代碼編輯器（monaco editor）更好，更不用說 vscode 還可以裝很多自定義插件、主題。低碼代碼編輯器主要核心的優(yōu)化點是通過動態(tài)注入的方式，將插件體系、模塊中的一些變量進行注入，方便用戶編寫的時候有更好的提示
通過復雜場景的實踐，我們擴寬了平臺的能力的深度，能讓開發(fā)者在開發(fā)中低復雜的續(xù)期的同時，不用擔心因為后續(xù)需求變更導致難以維護的窘境，同時我們也發(fā)現(xiàn)，低碼目前在研發(fā)人員中推廣還存在以下幾個問題
研發(fā)習慣：開發(fā)人員，特別是有經(jīng)驗的開發(fā)人員研發(fā)習慣很難改變，傳統(tǒng) Procode 在研發(fā)工具鏈、靈活性、經(jīng)過多年的不斷演進，已經(jīng)相對成熟，在低碼不具備核心能力突破的情況下(例如設計到代碼 D2C，或者需求到代碼 P2C)很難通過一些研發(fā)鏈路上、小提效的方式吸引這一類人群，同時平臺的完善度需要追平甚至超越現(xiàn)有的研發(fā)鏈路，才有可能走下一步，對平臺的基礎能力有很高的要求，需要持續(xù)的投入。
復雜場景支持：并不是說低碼不能用于復雜場景，通過平臺能力的支持，我們也實踐了在投保頁的低碼能力完全研發(fā)，但是要考慮的是在這些場景上，低碼提供的價值點是什么，給到新用戶用的理由是什么？復雜場景主要是需要寫大量的代碼邏輯，這塊不是低碼擅長的部分，所以這一類場景我們需要做進一步的拆解，將頁面組件化、通過通用框架層的架構設計，抽離核心復雜的代碼，做到通用能力和業(yè)務能力分離。
針對上述實踐、總結，我們在年中的時候，適當調(diào)整了一些平臺的方向，對面向人群，方式做了一定的調(diào)整
面向人群：主動非正式員工的研發(fā)人員，這一類研發(fā)并不會太糾結研發(fā)習慣問題，只要在最終產(chǎn)出上比 Procode 具備優(yōu)勢，就可以往下推進，并且第一波上手執(zhí)行上也相對容易。
面向場景：重點面向中低復雜的頁面，通過和 needle、輕研發(fā)合作，通過低碼研發(fā)卡片類的需求，擴展低碼價值領域范圍，這一類場景需要寫代碼的地方不對，通過物料+插件+可視化配置等低碼最擅長的領域完成研發(fā)既降低了門檻，又提升了效率，需要重點推廣。
提升平臺基礎能力：用的好了用戶才會留下。持續(xù)提升平臺的基礎能力，包括發(fā)布鏈路、出碼優(yōu)化、調(diào)試優(yōu)化、插件功能等，提升平臺綜合研發(fā)體驗。
復雜投保場景的組件化拆解
上面也說到，投保場景作為商業(yè)險的核心場景，如果全部采用低碼方式進行研發(fā)，在用戶接受度和使用推廣上會遇到很大的困難，即使在已有壽險投保場景落地的情況下。所以我們再思考，是否可以分解頁面，將頁面分割成組件維度，組件維度的低碼可以有效的降低復雜度，讓用戶更容易接受。保險投保場景的和普通的搭建會場有比較大的區(qū)別，普通的搭建會場基本每個組件都是獨立的，組件之間可以自由組合，并且組件之間交互相對較少，可以通過事件等機制進行比較弱的關聯(lián)，組件具備一定的復用能力，可以在不同的會場頁面進行復用（banner 組件、輪播組件、抽獎卡片組件）。所以這一類的場景可以通過組件獨立研發(fā)、頁面搭建的形式快速 run 起來，開發(fā)者只需要關注組件研發(fā)就行。
保險的投保頁雖然看上去也是通過不同的組件進行累積，但是卻有很多不同的地方，拿壽險的教育金進行舉例：
結構不同：投保頁存在著大量的全局公共邏輯，主要投保接口請求，數(shù)據(jù)處理，試算邏輯等，這些邏輯幾乎每個產(chǎn)品都需要用到，同時需要高頻的修改。每個投保頁必須帶著這些邏輯模塊才可以運行，UI 部分只負責展示。
組件與組件之間需要通過全局公共的狀態(tài)做聯(lián)動，例如下一步按鈕需要等到詢價的請求返回完成才可以進行點擊等等。
綜上，完成一個投保頁需要通用邏輯+產(chǎn)品定制邏輯+UI 組件幾部分
區(qū)別與常規(guī)的搭建組件，每個組件具備完整的子功能，可以直接復用，投保頁的組件由于邏輯復雜，一般不會直接放在組件內(nèi)部實現(xiàn)，而是通過一個統(tǒng)一的公共邏輯去處理，這樣做的目的是為了在同一類目的產(chǎn)品中增加復用能力，減少開發(fā)量。
統(tǒng)一售賣投保統(tǒng)一方案
正因為投保整體技術方案的復雜性，為了拉齊人生險投保技術方案，保險中臺組針對開放的投保方案進行了重構和改造，包括產(chǎn)品配置、前后端架構。
前端側(cè)整體思路是將公共部分和業(yè)務部分進行拆分，公共部分包含投?？蚣芎凸步M件，業(yè)務部分包含業(yè)務組件
投?？蚣?/strong>：包含通用的核心接口處理，包含投保渲染接口、投保接口、投保選項查詢接口等，以及提供一個 SDK，將全局的 state 進行封裝，通過 API 的形式進行讀取和存儲，將一些業(yè)務可定制的 hooks 封裝成?切面 ，可以通過切面的 API 在特定時機進行一些參數(shù)，行為的定制。這部分由中臺技術組研發(fā)并維護，業(yè)務只需要通過 SDK 的 API 獲取數(shù)據(jù)
通用組件：基于現(xiàn)有的投保頁，抽取的一些可復用組件，例如產(chǎn)品列表圖、投保按鈕、通用投保選項，由中臺技術組研發(fā)并維護
業(yè)務組件：每個垂類業(yè)務線特定的組件，例如壽險的試算組件，每個壽險開放類目都長得不太一樣，需要單獨定制開發(fā)。
從上面來看，新的投保架構將分工進行了合理的劃分，通過框架、公共組件和業(yè)務組件進行區(qū)分開來，對于業(yè)務線來說，只需要專注開發(fā)業(yè)務組件就行，而業(yè)務組件的研發(fā)方式也產(chǎn)生了變化，原先需要維護的上千行公共邏輯代碼整體以 SDK 形式進行了拆分，留出了擴展點進行業(yè)務擴展，剩下的根據(jù) SDK 提供的數(shù)據(jù)做業(yè)務的加工和展示，大大降低了業(yè)務研發(fā)的難度。
低碼場景投保方案適配
從上面可以看到，新的投保架構設計從將頁面內(nèi)嵌框架后，頁面開發(fā)變成了組件開發(fā)，降低研發(fā)復雜度，通過低碼研發(fā)組件，這個是一個相對比較成熟的領域，我們通過平臺的對接，對投保場景做了充分的支持，分成短期方案和長期方案
落地結果
經(jīng)過下半年定制開發(fā)，壽險所有開放類目共計 22 個組件，5 個類目全部通過低碼方式遷移到長江，驗證了投保頁低碼方式從 0 到 1 的突破，完成了低碼復雜組件可用的能力，從長遠上看，我們需要做到好用，才能吸引其他垂類的用戶進行遷移，這個也是我們今年工作的重點。
簡單場景的使用
上面我們說到，低碼在場景在常規(guī)中低復雜頁面、組件有著更直觀的優(yōu)勢，對此我們也沒有停止這類場景的探索，除了商業(yè)險常規(guī)的營銷組件、中低復雜承接頁以外，我們發(fā)現(xiàn)輕研發(fā)的卡片場景非常適合低碼，卡片場景 UI 多變，邏輯簡單，需求大，非常適合低碼研發(fā)場景。
為了能夠嵌入到 needle 編輯器，我們設計了將低碼編輯器作為 SDK 的方式進去，并通過實時出碼的方式和 needle 編輯器進行打通，最大程度上復用了 needle 本身的預覽+構建編譯，同時具備低碼完整能力。
通過 D2C 作為媒介，低碼進入卡片的研發(fā)更加具備優(yōu)勢，同時在針對不同的卡片產(chǎn)物（H5 卡片 React，Cube 卡片類 Vue），低碼統(tǒng)一的 schema 作為多 DSL 的升維協(xié)議，更方便開發(fā)者對多 DSL 產(chǎn)物進行研發(fā)。
通過下半年的和輕研發(fā)的整體推廣、迭代，加上本身在商業(yè)險內(nèi)部的使用，我們一共完成
總計落地?101?個線上資產(chǎn)，其中頁面資產(chǎn) 65 個，組件資產(chǎn) 36 個
完成輕研發(fā)?83?個組件資產(chǎn)（包含 H5 卡片+Cube 卡片）
算是在保險領域，低碼研發(fā)模式的一次探索加實踐。
寫在今年開始
在 2B 領域，低碼通過附能給非研發(fā)人員，大放異彩，解決了生產(chǎn)力的部分問題，在企業(yè)研發(fā)領域，今年我們通過這個實踐，做了一次寶貴、難得的探索，感覺在這個過程中支持、給與過幫助的同學，不管是使用者、合作方、上下游，都對你們說一聲感謝，基礎前端研發(fā)鏈路，是一個耗時、耗力的工程，從純代碼、低代碼、0 代碼，甚至當前正火的 chartGPT,未來總在不斷的變革中，今年我們還是會不停探索研發(fā)提效、體驗提升之路，腳踏實地，仰望星空。
