作者：京東零售 李春麗
作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入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、如何解決交付中核心繫統安全問題？答：遮蔽原始碼的完整擴充套件體系。