如何作一個技術全面的架構師

 

本文從六個方面討論一個良好架構師所必須具有的專業水準。數據庫

 

做爲領導編程

 

好的軟件架構師必須知道,他們做爲領導者的做用不必定是告訴開發人員作什麼。 相反,好的架構師的行爲自己就像一個指導,管理一個開發團隊向同一個技術願景前進,利用領導技能,如講故事,影響,導引衝突和創建我的的信任等方式,把他們的架構願景變成現實。安全

 

一個好的領導者,同時也是一個好的架構師,將仔細聽取每一個參與者的意見,經過與團隊反饋互動微調他們的願景。 很好地引導到下一個點。架構

 

做爲開發人員工具

 

在理想的目標架構與軟件系統的當前狀態之間平衡才能作出良好架構選擇。好比,若是關係數據庫更適合問題域,即便很無聊,若是再將文檔數據庫添加到系統中也沒有意義。架構師若是不首先考慮是否適合業務問題領域,會被各類技術誘惑而進行架構選擇。性能

 

架構師減輕這一點的最好方法是花費時間與開發人員泡在代碼中。瞭解系統如何創建,以及系統的約束,這些將爲架構師提供關於當今環境的正確選擇的更多信息。學習

 

具備系統焦點測試

 

經驗豐富的開發人員知道,代碼只是工做軟件的一個方面。爲了使代碼運行,經驗豐富的開發人員須要理解其餘重要的質量屬性,代碼才能在其生產環境中運行良好。他們須要考慮部署過程,自動測試,性能,安全性和可支持性等方面質量屬性。 開發人員才能能夠根據這些質量屬性進行編碼實施,架構師不只專一於理解代碼,並且須要瞭解並知足不一樣利益相關者(如支持,安全和操做人員)的需求。優化

 

好的架構師須要專一於尋找可以知足這些不一樣利益相關者需求的解決方案,而不是根據某一個參與者的偏好或風格選擇進行優化的工具或方法。編碼

 

像一個企業家思考

 

全部的技術選擇都有成本和效益,一個好的架構師將從兩個角度考慮新的技術選擇。成功的企業家會願意承擔風險,可是會尋求快速學習和快速失敗的方法。 架構師能夠以相似的方式處理技術選擇,尋求現實世界中有關短時間和長期成本的信息,意識到他們的可能好處。

 

一個很好的例子是,當架構師避免承諾當即使用重新文章讀過的或在會議上據說過的新工具。相反,他們應當設法瞭解該工具的相關性,並在他們的環境中運行的架構樣本以收集更多的信息。他們不會基於多好的銷售額而選擇一個工具,,而是依據它提供了什麼價值,是否提供給他們的系統所須要的。 他們還會尋找工具的隱性成本,例如支持的工具是否足夠好(例如文檔級別,社區採用狀況),工具帶來多少鎖定或長期引入的額外風險。

 

用戰術思惟平衡策略

 

許多團隊與各個開發人員都是傾向於選擇他們最溫馨或最有經驗的工具和技術構建他們的系統。

 

好的架構師須要注意什麼是更新的技術,哪些工具或方法多是有用的,但不必定當即採用他們。技術採用須要一個考慮長期前景的方法。 架構師將在團隊和組織層面尋求敏捷性(容許團隊快速移動)和調整(保持足夠的一致性)之間的良好平衡。

 

創建本身的技術雷達是在探索有用的工具。

 

良好溝通

 

架構師須要知道有效的溝通是創建在信任基礎上,須要在團隊外影響隊員,這些都是架構師的關鍵技能。 他們知道不一樣羣體的人使用不一樣的詞彙,使用技術術語與生意或管理人士交流會變得困難。架構師不會使用模式、工具和編程概念與他們交流,而是使用受衆熟悉的詞語與之交流。 使用諸如風險回報,成本和收益等詞彙向商業人士傳達技術選擇,將比與開發團隊一塊兒使用的技術詞彙更適合。

 

架構師也意識到團隊內部溝通和外部溝通同樣重要,能夠利用圖表和小組討論,創建和完善技術願景,並使用編寫寫日誌的方式,如維基,可以爲未來提供爲歷史發展軌跡。

 

結論

 

作一個全面的架構師不容易。有這麼多的元素須要咱們關注,每一個都利用許多開發人員每每不具有的技能。 最重要的不必定是架構師具備什麼能力,而是他們在這些不一樣領域有足夠的專業知識才能有效。只有熟練掌握上述六個領域之一的架構師,纔會成爲具備良好專業知識水平的架構師。

相關文章
相關標籤/搜索