作者:京東零售 李春麗
作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案,在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入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/550587.html
標籤:架構設計
上一篇:05單件模式