作者：京東零售 李春麗
作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案，在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入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、如何解決交付中核心系統安全問題？答：屏蔽源代碼的完整擴展體系，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/550591.html
標籤：其他