架構師在團隊里的角色很獨特，他們不是Master卻決定著何時以及如何交付軟體；他們不是PO卻確保軟體能夠滿足業務目標；他們也編程但做的更多的是架構層面的Coding而不僅僅是寫演算法，更多的在于設計層面，包含了管理、技術和交付的職能，或者說整個產研線的作業都與這個角色有關，它不單單需要會編程，懂設計，會測驗，通部署，這些只是架構師必備技能
從軟體工程角度而言
軟體的架構設計以人為本，軟體所有利益相關方都有著對專案的預期，而架構師需要的便是與利益相關方多方協作共同定義軟體專案的需求和目標，PO定義功能特性，而架構師需要挖掘功能特性后的質量屬性，除此之外更要關注那些影響架構設計方向的約束和特性
分解系統分配職責
架構師只有把軟體系統進行分解，才能制定出滿足質量屬性和其他系統性需求的策略，而這其中你要做的便是定義模塊、分配模塊到開發者；指定讀寫分離策略解決資料同步延遲，為系統的可靠性、可用性、伸縮性提供保障
關注大局
從全域角度考慮整體系統，意味著架構師需要處理的不僅僅是技術問題，人員、程序、業務需求以及其他技術和非技術因素都將影響最后的軟體系統，即便是一個小小的設計決策也可能產生深遠的影響，架構師必須高瞻遠矚縱觀全域而不能陷入區域細節的設計
然而很多時候是個掙扎的程序，在想要達到的目標和必須接受的現實之間尋找平衡，這意味著一個優秀的架構師必須善于尋找平衡做出取舍
管理技術債務
所有的軟體都有技術債務，架構師知道系統是如何分解的，知道各個模塊是如何協作的，在此基礎上再將業務需求和技術決策通觀考慮才能管理好技術債務，技術債務是軟體系統的副產品，出色的軟體團隊會有意的引入技術債務來實作更快的交付，后續在逐步進行償還，從而持續的創造價值
因此識別技術債務管理技術債務便成為架構師多執行緒作業的其中一個執行緒
提升團隊的架構能力
架構師是整個團隊的導師和顧問，設計炫酷卻無人理解的架構毫無意義，作為團隊的架構專家，向團隊分享知識，幫助團隊提升架構思維同樣是架構師多執行緒作業中的其中一個執行緒，因此組隊設計、檔案授業解惑，代碼Review便成為架構師完成此項職能的“方法”
軟體架構
軟體架構是從零開始組織軟體的一系列重大設計決策的集合，集合的目的便是實作期望的質量屬性和其他軟體特性，設計得當的架構能夠提升利益相關方需要的質量屬性，抑制或消除利益相關方不需要的質量屬性，同時還可以提升其他屬性，例如好的架構勢必能夠提升開發效率，多快好省
定義基本結構
軟體應該有主體結構，這個結構定義的是軟體系統的組織和協作方式，它體現在你撰寫的代碼和運行的軟體中，甚至體現在開發者之間的寫作中；將兩個元素以某種關系鏈接在一起就形成了結構，而元素是軟體的基本組成部分，關系則描述了元素如何協作完成任務
基本結構的設計切忌空想
通常情況下可以使用三種型別的元素和關系來構建架構，這三種型別分別為模塊、組件連接器和分配
| 型別 | 元素 | 關系 |
|---|---|---|
| Module | 類、包、層、存盤程序、模塊、組態檔、資料庫表等 | 使用、允許使用、依賴等 |
| Component&Connector | 物件、連接、執行緒、行程、層、過濾器等 | 呼叫、訂閱、管道、發布、回傳等 |
| Allocation | 服務器、傳感器、臺式機、負載均衡器、團隊、用戶、Docker容器等 | 運行于、負責、開發、存盤、支付等 |
- Module： 存在于設計階段，撰寫代碼的程序也是與模塊進行互動的程序，軟體沒有運行，模塊結構仍然存在于檔案系統中
- 組件連接器： 在軟體運行時出現，組件可以創建與其他組件的鏈接、產生新行程以及實體化新物件，與Module不同的是它在系統不運行是便不復存在，只能從其運行留下的日志或資料庫條目中看到其身影
- Allocation：展示了模塊與組件連接器之間以及這些元素與現實的物理元素之間的協同與回應關系，它也被稱為映射，因為它顯示了元素之間的相互映射關系，例如某個元素運行在客戶端還是服務器、A團隊負責構建系統的哪個部分等等
- 不同型別的結構適合用來思考不同的系統特性，例如Module考慮可測性和可維護性、組件連接器則考慮運行時問題可用性和性能，而如果發現使用了混合結構，例如靜態元素使用了動態關系，則說明設計欠考慮
- 結構決定了系統的身形輪廓，身形輪廓決定了用戶體驗到的質量屬性和其他特性
實體參考
- 元素：命名要明確具體，不要忘記他們之間的關系
- 考慮模塊結構：使用了哪些方法或類？這些類是否存在于不同的包或者命名空間？包管理器和構建腳本中包含哪些依賴關系？
- 考慮C&C結構：軟體在運行時是否與其他行程或者系統發生互動？誰在呼叫系統，它是如何回應的？
- 考慮分配結構：軟體各個部分有誰負責開發？如何部署？
推演質量屬性
- 軟體系統并非單純的功能實作，還要做到速度快、可靠、可擴展、可維護，質量屬性是利益相關方判斷軟體系統是否好用的一切外部可見特性，包括可伸縮性、可用性、可維護性、可測驗性等等，與軟體互動用戶就能體驗到這些質量屬性
- 選擇架構的結構實際上就是選擇你想在軟體系統中提升的質量屬性，思考架構設計可以確保你設計的軟體系統能夠支持你關心的質量屬性
- 是質量屬性讓你獨一無二，即便兩個軟體架構完全一樣，實作的功能需求也一樣，不同的是質量屬性
出色的軟體
架構使軟體成功的基礎
- 架構將大問題分解為容易處理的小問題：現代系統龐大且復雜，架構精確地解釋了如何將系統劃分為輕巧、獨立的小模塊，同時確保整個系統協同作業，讓系統的價值高于各個部分的價值之和
- 軟體架構告訴我們如何協同作業：軟體開發既是技術也是人際溝通的藝術，軟體架構描述了整個（包括開發者）如何組成有機的整體，掌握了架構也就清楚了人們該如何合作開發軟體，系統越復雜這一點越重要
- 軟體架構為討論負責設計提供了基本詞匯：不明白彼此在說什么就無法合作，軟體架構提供了溝通必備的基本概念和詞匯，這樣可以把時間用在解決用戶問題上
- 軟體架構關注的不僅僅是功能：軟體的特性和功能很重要，但他們不是決定軟體是否出色充分條件，架構除了考慮功能需求外，還要考慮成本、約束、進度、風險、團隊交付能力，以及最重要的唯一的質量屬性
- 軟體架構讓你避免犯重大錯誤：軟體架構是重要的設計決策，其重要程度可以用變更的成本來衡量
- 架構讓軟體更靈活：如果沒有架構，軟體就像水一樣無法控制，架構為軟體提供了靈活應變的結構
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/4807.html
標籤：其他