對於軟件架構師的一些理解

1、軟件架構師的定義

架構師在一個團隊中的職責比較獨特，既有特定的工做，又沒有特定的工做。但毫無疑問處於團隊的核心位置。

架構師不是項目經理，卻也須要決定交付軟件的時間和形式。架構師不是產品經理，卻也須要保證如何實現業務功能。架構師不是軟件工程師，卻也須要作核心部分的研發。

大多數的架構師都是從技術出身，懂編碼，懂算法，懂測試，懂部署。這些都是一個架構師的基礎技能，但除此以外還須要掌握一些其餘的必不可少的技能，記憶一些新的崗位職責。

2、軟件架構師的工做職責

除了掌握編碼、測試、部署等工做，架構師還須要有如下工做職責：

2.1 需求分析

架構師要與產品經理、項目經理一同協做，對客戶提出的軟件需求進行分析，並從專業角度給出意見。

項目經理從用戶角度出發進行需求分析，產品經理從業務角度出發進行需求分析，架構師從技術角度出發進行需求分析，三者的分析結果結合到一塊兒，可使分析結果更加立體和全面，避免上圖中發生的狀況。

除了業務需求外，架構師還須要關注另外一方面的需求 —— 非功能需求，這種需求更偏向技術，架構師應主動從項目經理和產品經理處密切關注這方面的需求，由於它們可能會影響到架構設計方向的約束和特性。

2.2 分解任務

這裏所說的分解任務並非分配人員的工做，而是對一個系統進行模塊分解。

一個項目通過的需求分析後，需求大致已肯定，那麼就須要對這個項目進行模塊分解，是總體向部分的過渡。架構師將軟件系統進行分解，目的將複雜問題簡單化，將項目分紅若干模塊後，逐一對這些模塊進行攻克，設計出知足功能和非功能的需求。

例如，能夠將用戶需求劃分出一個用戶模塊，車輛管理劃分出一個車輛模塊，行程應用劃分出一個行程模塊，指定不一樣的團隊開發不一樣的模塊，同時考慮非功能方面的需求，使模塊具有更高的可靠性、可擴展性等。

當業務初期整個團隊的需求理解並不那麼透徹，能夠將模塊範圍規劃的大一些，避免過分拆分致使沒法整合或整合的消耗過大，並不必定是越精細越好。當團隊將業務理解透徹後，能夠適當對模塊進行重構，由於系統已具有較好的可擴展性，因此重構的工做並不會影響太大。

2.3 系統設計

系統設計階段，是最爲關鍵的一個環節之一。這時要求架構師要與團隊的各個角色進行探討交流，從全局的角度考慮總體系統架構。

這表示架構師並不在單單處理需求和技術問題，要與研發團隊、測試團隊和運維團隊進行充分的交流和溝通，確保目標一致，減小信息不對稱的狀況。

架構師反覆思考本身在這個階段的每個決策，有條件能夠進行同行評審，利用團隊的智慧彌補我的考慮不足的狀況。由於一個小小的設計缺陷都有可能在研發階段形成深遠的影響。

另外，選擇最適合項目的架構，而不要可疑實用新技術或不務實的技術。例如，根據業務判斷，一個普通的、供10人使用的訂單管理系統就不須要選擇微服務架構。空想不能落地的架構老是很容易的，爲了不這種狀況的發生，也須要從管理角度來避免。

2.4 非功能設計

非功能設計簡單來講就是系統要求的一些指標，例如：可用性、可伸縮性、可擴展性、可移植性、性能指標等等……

對於非功能設計，架構師要根據實際狀況進行一些取捨。

例如，客戶要求可用性在99.99%，那麼架構師就要面臨硬件數量翻倍的問題，客戶要求安全係數很高，那麼架構師就要面臨採購更專業的防火牆的問題。

放棄一些東西來換取一些東西在軟件設計過程當中也是很常見的。好比用控件換時間，用稍顯複雜的設計模式換取擴展性，用冗餘來換取可用性。架構師在這個階段須要與項目經理和產品經理保持溝通，找到最符合項目的折中點。

這些工做很難作到盡善盡美，可能會犯一些錯誤，因此還須要進行嚴格的質量評審，而且有一套技術債務管理的方式方法。

2.5 技術債務管理

當由於某些緣由不得不留下一些未完成的工做，或者因爲一些失誤形成的遺留項，必定要記錄在冊，並有計劃的進行補償。

全部的軟件都會存在技術債務，架構師須要瞭解系統的分解、模塊的劃分，還要把業務與技術放到一塊兒進行考量，只有這樣才能遊刃有餘的處理技術債務。

出色的研發團隊會有意識的引入技術債務來實現更快的交付，後續再進行償還，從而持續創造價值。

但要作到這必定，架構師必定要從大局觀出發來考慮如何遺留技術債務，保證遺留的同時不影響軟件的交付，這很難作到，要求架構師既精通技術，又瞭解業務，同時技術團隊的研發人員也要與架構師在思想上達成統一。

2.6 團隊技能提高

架構師還要擔任整個團隊的導師和顧問，設計狂拽酷炫卻無能能理解的架構毫無心義，做爲團隊的技術專家，必須承擔向團隊分享知識的任務。

架構師要因地制宜，因人而異的傳授設計技巧和架構理念，作到傳道、受業、解惑。也能夠提出一些批判性的建議。把架構當成一項團隊建設，讓全部團隊成員都參到設計過程當中是最佳實踐，這是最有效的提高團隊技能的方式方法之一。

技能的提高對於團隊的成敗將起到相當重要的做用。

另外，架構師也要參與到團隊的研發過程當中，能夠經過編寫模板、樣例代碼的方式與研發人員進行交流，若是時間不容許，最起碼每週花費一天或者半天參加到研發團隊中，瞭解架構的使用狀況，有哪些優勢和不足。

要知道，團隊的智慧必定是大於我的的。同時有一點要說明，軟件架構設計是一門以人爲本的學科，培養體系是其中最難的一種體系之一。

3、如何成爲軟件架構師

從經驗角度看，成爲架構師以前，應該參與並開發過某行業領域的軟件三到五個，並且在這個過程當中，承擔的職責不斷的增長。隨着經驗不斷的累積，會發現編程的時間愈來愈少，設計的時間愈來愈多。慢慢的，變潛移默化的成爲了架構師。

爲了記錄和評估是不是一個合格的架構師，能夠創建一個項目工做檔案表，來記錄在項目中的工做。

業務理解，以及業務目標是什麼？

答：

項目總體解決方案是什麼？如何進行拆分的？

答：

涉及的技術棧有哪些？爲何這麼作？好處是什麼？

答：

最大的風險是什麼？如何克服的？如何管理的技術債務？

答：

若是從新作一次這個新項目，有哪些地方須要改進？爲何？

答：

這個表格能夠隨時增長，記錄項目中的架構思惟，當慢慢的對這些問題駕輕就熟，就已經能夠勝任架構的工做了。

架構師不只僅是團隊中的一個角色，更是一種思惟方式，就算是研發人員，天天也會作出不少小的設計決定，這其中有些決定是有架構意義的，架構師要作到高瞻遠矚，俯瞰大局，把設計工做當成樂趣從而樂在其中。

4、總結

綜上所述，架構師是一個既須要掌控總體又須要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。

架構師跟多的時候是一個團隊，須要創建高效的體系，帶領團隊去攻城略地，在規定的時間內完成項目，確保團隊有共同的技術願景，協調多個團隊甚至整個組織內的工做。在通常組織裏，很是優秀的研發人員才能夠成爲架構師。

同時，架構師又是很年輕的一個職業，這是相比於醫生或者建築師而言，若是醫生和建築師在工做期間給出了錯誤的判斷和決定，那麼頗有可能要負法律責任，例如在某些國家，獲得註冊建築師資格以前，要通過七年的系統性學習，並且這些職業幾千年前就已經存在了。

因此，架構師應該站在後進的立場上，持續不斷的完善本身，成爲一個優秀的合格的架構師。