實踐篇(三):如何有效評審軟件架構圖?
作者:京東科技 倪新明
設計意圖的傳達是架構可視化關注的重要維度,在技術方案評審過程中不可避免的會出現各種各樣的架構圖或設計圖,這些圖形化表述在設計意圖傳達效果層面表現不一,本文從圖形化的視角為軟件架構圖的評審關注點提供了參考。
注:關於架構及架構可視化參考文章 《 探尋軟件架構的本質,到底什麼是架構?》 《 軟件架構可視化及C4模型:架構設計不僅僅是UML》
1 原則
•明確的主題:架構圖要表達的意圖明確,比如是容器圖、組件圖還是部署圖
•一致的抽象層級:保持一致的抽象層級,不應超過2個以上的層次變化
•粒度合適的範圍:不應試圖在一張圖表達“所有的東西”,每張架構圖聚焦於自身職責邊界的範圍
•清晰的圖例説明:對架構圖顏色、形狀等有明確的圖例,以方便閲讀導航
•圖形顏色不宜太多:過多顏色增加認知成本,建議不超過 4 種
•圖形元素不宜太多:過多圖形元素增加認知成本
•明確的連線關係描述
2 評審檢查單
如同上線檢查單和開發檢查單,針對於軟件架構圖的評審制定一套檢查單同樣具有價值。不論架構設計者,還是參與設計評審的開發人員,對於形式各異的 “架構圖” 是提供通用的參考關注點,以便干係人更多、更深入、更高效、更有針對性的獲取架構圖的更多信息。
2.1 通用檢查項
架構圖是否具有標題?
是否能夠理解架構圖的類型是什麼?
是否能夠理解架構圖的範圍是什麼?
架構圖是否有圖例?
2.2 元素
架構圖中每一個元素是否有名字?
是否能夠理解架構圖中每個元素的類型? (比如,抽象級別,軟件系統?容器?組件?等等)
是否能夠理解架構圖中的每個元素是做什麼的?簡要描述信息?
是否能夠理解與該元素相關的技術選型(適合標明技術選型的元素)
是否能夠理解架構圖中使用的所有縮寫/簡稱的含義?
是否能夠理解架構圖中元素使用的所有顏色的含義
是否能夠理解架構圖中元素使用的所有形狀的含義
是否能夠理解架構圖中元素使用的所有圖標的含義?
是否能夠理解架構圖中元素使用的所有邊框樣式的含義? (比如,實線 vs 虛線)
是否能夠理解架構圖中使用的所有元素大小的含義? (比如, 小框 vs 大框 )
2.3 關聯關係
架構圖中的每條線是否有描述關係含義的信息?
是否能夠理解架構圖中的每個關聯關係****(適合標明技術選型的場景)的技術選型是什麼? (比如,進程間的交互的協議)
是否能夠理解架構圖中的關聯關係的簡稱或縮寫?
是否能夠理解架構圖中的連線顏色的含義?
是否能夠理解架構圖中的連線箭頭的含義?
是否能夠理解架構圖中的連線樣式的含義? (比如,實線 vs 虛線)
3 結語
本文描述了軟件架構圖的一些評審關注點,其實不只是評審的視角,對於任何一個圖形化的軟件系統架構或設計表訴,如何能夠快速的瞭解其要表達的意圖至關重要,對於設計者而言如何快速傳遞架構設計信息並於干係人達成一致也至關重要。
- 應用健康度隱患刨析解決系列之數據庫時區設置
- 對於Vue3和Ts的心得和思考
- 一文詳解擴散模型:DDPM
- zookeeper的Leader選舉源碼解析
- 一文帶你搞懂如何優化慢SQL
- 京東金融Android瘦身探索與實踐
- 微前端框架single-spa子應用加載解析
- cookie時效無限延長方案
- 聊聊前端性能指標那些事兒
- Spring竟然可以創建“重複”名稱的bean?—一次項目中存在多個bean名稱重複問題的排查
- 京東金融Android瘦身探索與實踐
- Spring源碼核心剖析
- 深入淺出RPC服務 | 不同層的網絡協議
- 安全測試之探索windows遊戲掃雷
- 關於數據庫分庫分表的一點想法
- 對於Vue3和Ts的心得和思考
- Bitmap、RoaringBitmap原理分析
- 京東小程序CI工具實踐
- 測試用例設計指南
- 當你對 redis 説你中意的女孩是 Mia