iT邦幫忙

2023 iThome 鐵人賽

DAY 4
0
IT管理

萬丈高樓平地起:解決方案架構師的探索之旅系列 第 4

Day 4 : Solution Architect 技術相關技能樹

  • 分享至 

  • xImage
  •  

在前三天的內容大略的探討了架構師的種類以及與軟體工程師的差異,架構師不僅需要有基本的技術知識,還要有視野和策略性的思考,與軟體工程師相比,需要更多的參與系統的設計和決策過程。

今天將深入探討軟體架構師所需的核心技能樹,根據Roadmap的總結,每位軟體架構師都必須掌握的一些技能包括:設計、決策、簡化、編碼、文件撰寫、溝通、估算(成本或是時間)、平衡(溝通上)、技術諮詢和市場推廣。

接著就從這幾點來做個簡單的說明

技能

設計與架構:打造可維護系統的基礎

設計與架構在軟體開發中佔有核心地位,那麼哪些條件構成了好的設計,這是一個既重要又具挑戰性的問題。可以從理論和實踐兩方面來看待這個問題。

理論:學習模式、反模式和質量指標

  • 了解基本的設計模式:模式是開發可維護系統的重要工具。通過模式,可以重用設計來解決常見問題。例如,《Design Patterns: Elements of Reusable Object-Oriented Software》這本書描述了Model-View-Controller (MVC)模式,這是現代軟體架構的基礎。

Model-View-Controller (MVC) 是一種架構模式,將應用程式分為三個主要組件群組:模型 (Models)、視圖 (Views) 和控制器 (Controllers)。此模式有助於實現關注點的分離。來源

  • 深入研究模式和反模式:如果已經熟悉所有的基本模式那麼可以擴展知識,或深入研究特定領域,例如,《Enterprise Integration Patterns》這本書涵蓋了應用集成的各個方面。反模式則是指那些看似有效但實際上會導致不良後果或陷阱的設計或實踐。例如,《AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis》這本書介紹了一些常見的反模式,如分析癱瘓和過度工程等。

下表為上述的一些名詞的敘述

專有名詞 定義
反模式 反模式是處理重複出現問題的某些解決方案的後果,它是應用軟體中常見的有缺陷的過程的實現,產生的原因可能是開發人員不了解軟件開發實踐或沒有將設計模式應用正確
分析癱瘓 分析癱瘓是指當人們過度分析或思考一個問題時,可能導致決策的延遲或無法做出決策。
過度工程 過度工程指的是設計或建構一個產品、系統或過程時,使其比實際需要更為複雜,這可能是因為過度考慮未來的需求、想要包含所有可能的功能,或是僅僅因為技術上的挑戰。
  • 了解質量指標:定義架構不是終點。需要確保系統是可維護的、可靠的、可適應的、安全的、可測試的、可擴展的等等。質量指標是用來衡量系統質量的屬性或特徵。例如,《Software Architecture in Practice》這本書提供了一個質量指標的分類,包括功能性、可用性、修改性、可移植性和測試性等。

從實踐方面:嘗試並了解不同的技術堆疊

  • 嘗試並了解不同的技術堆疊:這是成為更好的架構師的重要活動,例如深入研究SAP R/3,也應該嘗試JavaScript,並了解SAP S/4 Hana的最新進展。
  • 分析和理解應用的模式:例如,研究Angular框架中的模式,如Observables,並嘗試理解它是如何在框架中應用的。

決策:指引項目或組織的方向

架構師需要具備決策能力,並能夠指引項目或整個組織朝正確的方向前進。

重要性:區分主要和次要

  • 辨識重要性:避免在次要的決策或活動上浪費時間和資源,要學會區分哪些是真正重要的,然後評估事物重要性時會考慮以下因素:

    • 概念完整性:一旦選定某種策略或方法就應該持續堅持(即使中途出現了更佳的選擇),這樣可以確保整體的策略或方法更加統一和完整,更易於理解和維護。
    • 一致性:例如,在命名規則上重要的不是是否使用大小寫,而是確保在所有情境中都採用相同的規則。
  • 確定優先順序:某些決策對項目的成功至關重要。延遲這些決策可能導致權宜之計或開發停滯。有時,及時做出不完美的決策也比完全不做決策要好。建議使用敏捷軟體開發中的Weighted Shortest Job等方法,以確定決策的優先順序。

思考多種的解決方案

  • 多角度評估:決策時應該考慮多種可能的選項,通常每個需求或是問題都有多種可能的解決方案,然而只提供一種選擇可能會限制視野,並可能導致錯誤的決策。

實際案例:在一個大型軟體開發項目中,團隊需要選擇合適的數據庫技術。架構師從多個角度評估了關聯型數據庫和NoSQL數據庫,並根據性能、成本和可擴展性等標準進行了深入比較,最終的決策是基於充分的資料分析,而非單純的直覺,且得到了所有利益相關者的一致認同。

編碼:了解開發者的日常工作

作為解決方案架構師仍需了解開發者的日常工作,若不了解此工作方式可能會遇到以下問題:

  • 開發者對建議的接受度低
  • 難以體會開發者所遭遇的問題和需求

為了克服這些挑戰,以下幾種習慣值得培養:

  • 進行Side Project:透過實際的專案,探索新技術和工具,以深化對當前和未來開發趨勢的認識。若時間有限,考慮fork熱門的開源專案進行研究。
  • 策略性地探索新技術:建議參考ThoughtWorks的技術雷達。這是一份每半年更新的報告,由ThoughtWorks的技術領導編寫,提供對當前軟體開發趨勢的見解。報告將技術、工具、平台、語言和框架分為四類:採納、試驗、評估和持有,幫助你更有策略地了解和評估新技術。

什麼是ThoughtWorks的技術雷達?

Technology Radar | An opinionated guide to technology frontiers | Thoughtworks是一個每年更新兩次的報告,它為軟體開發領域中的各種技術趨勢和實踐提供了專業的見解和建議。

由ThoughtWorks的技術領導人員基於在客戶項目中的實際經驗和觀察提供參考資訊,並且將技術分為四個象限分別為技術、工具、平台和技術語言與框架,其中每個象限中的技術都被標記在一個圈中,表示對其採用程度的建議。

https://ithelp.ithome.com.tw/upload/images/20230918/20141298Lb2sj42oKC.png

上述的每一圈都有不同的意思:

  • Adopt:這些是值得在任何合適的情況下使用的成熟且有益的技術,已經被廣泛測試和驗證並且有足夠的社區支持和豐富的官方文件。
  • Trial:這些是值得在特定情境下嘗試的有前景的技術,可能還不夠成熟或穩定,或者還沒有足夠的證據表明可以帶來顯著的好處,需要更多的探索和實驗確認是否適合某些用例或場景。
  • Assess:這些是值得關注和學習的新興或變化中的技術,可能還沒有足夠的成熟度或廣泛性,或者還存在一些爭議或不確定性,需要更多的研究和分析以確定是否具備潛力成為未來可採用/落地的技術。
  • Hold:這些是不建議在新項目中使用或引入的過時或有問題的技術,因為可能會有更好的替代方案,或者已經被證明有嚴重的缺陷或風險,長期而言需要被逐步淘汰或替換,以避免對系統的可維護性和品質造成負面影響。

技術雷達不僅是一個學習新技術的指南,也是一個反思和改進自己的技術實踐的工具,它可以幫助架構師識別自己的技術盲點和學習需求,也可以幫助與開發者和其他利益相關者進行有效的評估和思考,提供有價值的見解和建議。

結論

軟體架構師的角色不僅僅是技術專家,更是一位具有策略性思考和廣泛視野的領導者,包含了一系列的核心技能,從設計、決策、編碼到溝通和市場推廣,以確保軟體的成功開發和部署。

明天會提到剩下的幾個技能需求,包含有一些比較偏向管理面的內容。


上一篇
Day 3 : 軟體開發工程師和解決方案架構師的差異
下一篇
Day 5 : Solution Architect 管理與軟實力相關技能樹
系列文
萬丈高樓平地起:解決方案架構師的探索之旅30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言