作者：京東零售 李春麗

作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基於此我們探索了一種新的技術體系及交付方案來解決如上問題。

背景

嗨，大家都知道軟體研發需要許多角色共同協作，包括客戶、產品經理、研發工程師、測試人員、實施運營團隊等等。在這眾多角色中，研發工程師的人數占比最高，但是研發資源畢竟有限，隨著需求量不斷增加，在項目中還會聽到如下吐槽：

1、研發團隊排期瓶頸，非研發角色感受不到研發技改提效的變化。

2、引入ISV 團隊又擔心質量和安全問題，而且培訓成本高、周期長，在核心複雜系統中，不敢也無法短時間大規模引入。

不過，如果有一種方法能夠實現生態化交付和全民開發的願景，那就可以解決上述問題了！這種方法可以讓所有角色，無論是技術還是非技術的，以安全、更簡單的方式參與進來。

這樣一來，就可以在不增加團隊人數的情況下，提高團隊的吞吐量，實現更高效的需求交付，是不是很奇妙呢？

挑戰

為了達到生態化交付和全民開發的願景，我們需要解決如下幾個問題？

1、如何讓非技術角色實現研發的交付？

2、如何讓全民開發者完整實現一個需求閉環，而非僅僅實現其中一部分需求？

3、如何解決交付中核心系統安全問題？

我們帶這幾個問題看下解決方案。在講技術方案之前，我們先站在客戶角度，從整體看一下，一個系統的需求都來自哪裡？而我們都知道比起從0-1新做一個系統，二次擴展類需求更加複雜，我們今天就以二次擴展類需求入手和大家一起分享下，在京東智能供應鏈Y做的一些實踐。

方案

設計思路

如上圖就是任意一個系統中二次擴展類需求分類的最大集合，主要有8類：API類、參數類、模版類，界面類、流程類、規則類及資料庫類。

1、API類：主要是新增API和在原有API的擴展，例如，原有API上新增一些屬性。

2、模版類：主要是新增一個模版。例如，製作一類新的合同模版或問卷調研，各部門填報填寫。

3、參數類：主要是新增KV類的參數。例如，新增“是否包括自營商品“參數，並讓這些參數在某些邏輯中起到作用。

4、UI類：主要是新增菜單、按鈕、佈局、圖表、校驗規則等。例如新增一個外呼按鈕，並調用外呼系統 介面。

5、流程類：在原有流程節點中新增新的節點。

6、規則類：在原有的規則前、後等，新增新的規則。

7、資料庫類：在原有表中增加新的屬性，或者新增一個子表。

8、最後還有一類其他：無法劃分為某一類，需要複雜的邏輯處理實現。例如 數據重新聚合與邏輯運算

我們就基於這些研發的需求類型，設計一套技術體系，實現生態化交付和全民開發的願景。

技術方案

我們把軟體系統分成三層，建立完整的全鏈路擴展技術體系，在把這些能力通過零低代碼手段把他們進行打通、包裝和開放，就可以實現屏蔽源代碼的情況下，對系統進行安全、簡單、閉環的二次增強，進而達到全民開發的目標。具體包括：

1、界面層：該層擴展主要手段就是零低代碼技術。

2、介面層：該層擴展主要手段就是依靠不同模型之前的映射來解決，而模型的擴展就可以依靠對象擴展來解決。

3、服務層：該層擴展主要依靠流程、規則引擎來實現，這個業界有很多開源工具，例如activity和drools等。另外還有很多場景是複雜的邏輯變更，這個可以依靠插件、事件驅動模式來實現。

4、模型層：該層擴展主要手段就是依靠元數據驅動，通過依賴元數據對象，而非底層物理資料庫。

以上能力，在通過最後零代碼技術的加持和封裝，實現可視化配置，形成一個工作空間，在對工作空間進行分角色授權，讓不同角色以熟悉的語言進行操作，這樣就可以實現生態化交付和全民開發的願景。

所以說擴展的技術體系不是一個單一的解決方案，它需要零低代碼、插件、業務事件、元數據驅動、流程規則引擎等技術共同協作才可以。而難點是這幾個技術需要互相搭配好，實現擴展的互認，例如我們在對象模型擴展中增加了一個屬性，這個屬性需要在界面展示、需要在介面中透傳、需要在規則中校驗，這就需要做好頂層架構設計。

我們通過幾個案例來描述，它需要和可以實現哪些能力？

案例

案例1：讓非技術參與進來，體會技術提效的變化

需求描述：基於業務變化，一個核心系統，需新增 “渠道類型” 這個屬性，改動涉及：

1、數據模型變化（技術上：資料庫欄位變化）

2、後端服務及規則變化（技術上：介面變化、對象變化、判斷規則變化等）、

3、展現界面變化（技術上：UI 界面增加帶數據許可權的查詢條件、表格新列及圖表增加等），

也就是需要軟體不同層次的進行變化。通常，這些特別技術的需求變更，只能技術排期做，但是通過這種新方式。產品經理/客戶就可以在無需等待，7 分鐘內，全程零代碼的模式下完成。

1、在對象擴展中，增加新的屬性。

2、在規則引擎中，基於新的屬性，編排增加新的校驗。

3、在界面擴展中，把在對象擴展中的新列拖拽出來，展示為查詢條件，並製作一個新的餅狀圖展示到界面。

通過這個案例，也就是說我們可以把黑盒的研發工作，安全、高效的交付給其非研發角色自助完成，提升交付效率，減低溝通成本。另外還有一點值得一提，這種方式也讓非技術人員，可以直觀的感受到技術提效的變化。

案例2：不觸及代碼情況下，實現安全一站式開發

需求描述：基於業務變化，一個核心系統，需要與客服系統集成，實現對某類特殊業務的客服外呼，改動涉及：

1、新增一個外呼按鈕

2、新增前端規則校驗，只有履約數據滯留2天的才需要進行客服介入。

3、調用外呼介面，組裝數據增加複雜邏輯並傳遞。

4、發送郵件通知相關角色。

同樣，這些也是特別技術的需求變更，原來只能原廠技術開發來排期做，但是通過這種新方式。客戶IT或ISV，就可以在不觸及代碼的情況下，通過統一平臺一站式完成需求的變更。

1、在界面層中，通過零低代碼手段完成按鈕新增。

2、在界面層中，通過零低代碼手段完成規則校驗的新增。

3、在服務層中，通過插件方式，實現代碼邏輯處理，並調用外呼介面。

4、在服務層中，通過事件訂閱方式，監聽外呼狀態，配置郵件模版，實現郵件自動發送。

通過這個案例，我們可以看出來，業務需求具有多變性，不能僅僅依靠一種手段完成擴展，需要多種方式進行搭配，才能實現大幅度提效。

結束

其實零低代碼、插件、業務事件、元數據驅動、流程規則引擎等技術在行業中並不是一個新事物，而這些技術可以互相搭配，實現完美集成和互認，讓用戶在一個平臺針對不同業務的場景使用合適的技術，完成需求的自助化，是個難點。它不僅僅需要平臺技術，還需要對業務系統需要合理的抽象、抽取。

最後，我們在回過頭看看最開始的技術挑戰。是不是都解決了呢？

1、如何讓非技術角色實現研發的交付？答：通過零低代碼模式進行封裝和開放。

2、如何讓全民開發者完整實現一個需求閉環，而非僅僅實現其中一部分需求？答：需要全鏈路開放和打通，並不僅局限一種技術手段。

3、如何解決交付中核心系統安全問題？答：屏蔽源代碼的完整擴展體系。