成為一個優秀的架構師還有很長的路要走（軟件架構案例分析和***實踐培訓收獲）

2009-12-25到27日我們參加了某軟件培訓機構的的《軟件架構案例分析和***實踐》課程培訓，開拓了眼界，收獲很多，劉老師講得不錯，非常有實戰經驗，跟他學到了不少有關軟件架構的知識，可惜的是3天的培訓課程不可能完全掌握所有知識，師傅只是給我們打開了一扇門，指出了一個方向，成為一個優秀的架構師還有很長的路要走。

新視野 “軟件架構”定義的決策因素

定義1：架構是一系列重要決策的集合

一直以來，學習架構，使用架構，關注點都僅限于技術層面，沒有認識到架構和“決策”的關系，這說明架構是一個很重要的概念，從軟件架構概念產生的背景可以得出：

——-其實，軟件架構(Software Architecture，軟件體系結構)一詞早在20世紀60年代就被E.W.Dijkstra提出，但是直到20世紀90年代初才開始流行起來。為了提高軟件需求和軟件設計的質量，軟件工程界提出了需求分析工程技術和各種軟件建模技術。但是在需求和設計之間仍然存在一條很難逾越的鴻溝，即缺乏能夠反映做決策的中間過程，從而很難有效地將需求轉化為相應的設計。為此，軟件架構的概念應運而生，并試圖在軟件需求與軟件設計之間架起一座橋梁，著重解決軟件系統的結構和需求向實現平坦過渡的問題。

定義2：軟件架構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。

軟件架構不僅指定了系統的組織結構和拓撲結構，并且顯示了系統需求和構成系統的元素之間的對應關系，提供了一些設計決策的基本原理。

還有很多其它的定義方式，但從這兩個定義可以看出，架構對于決策的重要性，架構師的工作對于項目的成功運作具有決定性的作用。

“架構師”不是空頭銜

——不是項目經理，開發人員，測試人員的兼職角色

在軟件工程領域中，軟件架構師實際上就是軟件項目的總體設計師，是軟件組織新產品的開發與集成、新技術體系的構建者。Martin Fowler（著名軟件架構和設計大師，軟件設計模式創始人）指出：

架構師是對所有重要事情做出決定的人。

軟件架構師在整個軟件開發過程中都起著重要作用，并隨著開發進程的推進而其職責或關注點不斷地變化。

在需求階段，軟件架構師主要負責理解和管理非功能性系統需求，比如軟件的可維護性、性能、復用性、可靠性、有效性和可測試性等。此外，架構師還要經常審查客戶和市場人員所提出的需求，確認開發團隊所提出的設計；在需求越來越明確后，架構師的關注點開始轉移到組織開發團隊成員和開發過程的定義上。

在軟件設計階段，架構師負責對整個軟件架構、關鍵構件、接口的設計。

在編碼階段，架構師則成為程序員的顧問，并且經常性地要舉行一些技術研討會、技術培訓班等。

隨著軟件開始測試、集成和交付，集成和測試支持將成為軟件架構師的工作重點。

在軟件維護開始時，軟件架構師就要開始為下一版本的產品是否應該增加新的功能模塊進行決策。 

軟件架構視圖

——軟件架構是一種無法以簡單的一維方式進行說明的復雜實體。

——多重軟件架構之所以必不可少，是因為各類涉眾（用戶，客戶，開發人員，測試人員，維護人員，內部操作人員，其他人員）需要從各自的角度理解和使用架構。

常用的軟件架構視圖：

l 功能視圖

l 開發視圖

l 進程視圖

l 部署視圖

l 場景視圖

l 數據視圖

l 實現視圖

注：在我們的實際項目中，用的最多的是功能視圖，其次是開發視圖，沒想到還有這么多的視圖需要考慮。比如，在MB一期的設計中，我曾考慮過是否有必要作一個軟件的部署形式圖，***猶豫中還是出了一個，現在看來是很有必要的了，至少讓運維人員明白了MB的軟件部署是怎么回事。

新觀念

架構的質量屬性

在現實的系統中，決定系統成功或者失敗的關鍵因素中，滿足非功能需求往往比滿足功能性需求更為重要。從技術角度看，質量屬性影響重要的架構和設計策略。

質量屬性分為系統質量屬性和商業質量屬性，其中系統質量屬性又分為運行時期的質量屬性和開發時期的質量屬性；商業質量屬性包括政治因素，上市時間，成本和收益等。

我們雖然常常把性能，安全，可擴展等詞掛在嘴邊，但往往在實際開發中這些因素都忽略了，為了趕工期，功能實現是***位的，***軟件做出來了，質量卻不好，問題一堆。實際上，軟件的質量不只是產品經理應該關注的，軟件架構師也必須關注，給出建議，供管理層做出決策。MB的開發就是最明顯的例子，上頭規定了上線時間，滿足必須的功能，及時上線是附在開發人員身上的魔咒，開發人員只得加班加點的工作，***軟件及時上線了，但后來在運行效率，易用性等方面成為詬病。

架構是有生命力的

運維人員說：軟件運行這么慢，架構太爛了！

開發人員說：代碼這么難寫，架構太不靈活了！

客戶說：軟件太不穩定了，架構有沒有問題?。?/p>

XXX說：YYY架構師太差勁了，怎么就沒有設計出一個好架構？

在所有人看來，架構必須是***的，對所有人感覺都是良好的，能夠適應未來的種種變化，能夠一勞永逸！

起初我也是這么認為的，但是老師告訴了我們一個新觀點：

架構是有生命力的！

“架構是有生命的，是不斷變化的。因此，設計架構不能只想著要考慮到所有的問題，設計出一個能夠包容所有可能問題的架構，這幾乎是不可能完成的任務。因為變化是絕對的，架構總是會修改，關鍵問題是何時修改？一定不能在系統問題頻出、已經來不及補救的時候才去考慮修改，而要在潛伏的問題逐漸露出端倪之前展開行動。”

——FreeWheel CTO和聯合創始人 于晶純

亞馬遜，MySpace（進行了6次架構重構），eBay，淘寶網，這些大型網站都是不斷地對架構進行重構，對應用進行升級來應對業務發展的需要的。

所以，我們不能一味的去指責FT的架構如何差勁，MB的架構如何糟糕，公司的這些產品線都是逐漸發展起來的，功能是一點點增加起來的，在功能開發***的市場戰略下，架構成了次要考慮的問題，所以我們不能說當初的架構設計的不好，問題是在于功能增加了，應用變復雜了，而架構沒有跟上變化。

架構的思維

全局觀

首先，架構師要有全局觀，不能***摸象，要看到架構的多個層面，多個角度。如架構的多個視圖，架構的質量屬性，架構設計，架構模式等，都是從項目的全局視角來看待問題的。

設計的本質就是一種權衡，是各類相互制約的模塊間的一種權衡。明白這一點，就要求架構設計上對各個模塊應有靈活的控制，以保證用戶期望目標為設計出發點，平衡各類資源的使用。

一個好的架構的概念是完整的，模塊間的關系是清晰簡潔，弱耦合的，模塊的接口是抽象穩定的，模塊的實現是強內聚和可擴展的。

面向架構的思考

一個目標或一件設計任務，在架構師的頭腦中，永遠是有層次感的，是立體的，就如同草稿中的一個建筑物：它應該是一個什么類型的建筑物，需要多少個支撐面、大概需要多高（幾層樓）、需要滿足多少功能…。

實際上，這是一種考慮問題的習慣：分類思考，分層觀察。

架構師的一個重要素養或價值是將一個問題或者方案的“分類學”搞清楚 - 從幾個方面來考慮，最重要的“動因”是什么，關鍵的需要是什么，關鍵的設計要素是哪幾個。當然，做到這一點需要很強的理論功底，也需要很豐富的經驗，這樣你拿出來的解決方案才有說服力。

總結和分析問題

要善于總結經驗，找到解決問題的***方法—架構模式。

要善于分析和歸納問題，找到事情的變化點和風險點，并能夠采取良好的設計規避這些不穩定因素，這是普通和優秀架構師的重要區別。

站在巨人的肩山

“我之所以成功，是因為站在巨人的肩上。”

——牛頓

“既全面又面向重點細節的思路，參考前人的實踐經驗，聚焦問題的癥結，采用安全且有創意的手段，追求***的精神。”

——西門子中國***架構師 李偉

不要重復造輪子，把輪子的樣式和制造方法告訴我吧！架構也是一樣，業界有很多通用的商業或者開源軟件架構，比如Java的Spring，Hibernate，.NET的Enterprise Library，Entity Framework 。我們可以參考別人用過的成功的架構，把它們作為參考架構。他們可以是現成的架構模式、架構機制和框架，也可以是具有已知特征并證實已在使用的完整系統。 使用經測試的參考架構是處理許多非功能性需求（尤其是質量需求）的一種有效方法。

先知其然，再知其所以然

“你們現在學的東西可能覺得對你們現在的工作沒有太大的實際意義，但你應該先了解它，知道有這么回事，然后當你遇到問題的時候，想想有沒有以前學習過的，有你就拿出來，仔細研究，使用，總結，***你就能夠駕馭它，這樣你就成了專家，成了大師了。”

——這是老師最常給我們講的一句話。

先知道有它，了解它，再使用它，駕馭它，這就是先知其然，再知其所以然。這是一種循序漸進的學習方式，軟件架構的知識這么多，面這么廣，不可能一下子全部掌握，現在學的以后可能會使用到的，到時候再來深研也不遲。

如果你不知道這些知識，這些方法，等你以后遇到問題，辛苦鉆研出來，興高采烈的宣稱自己多么聰明，多么偉大的時候，說不定有人就會給你破盆冷水—這個問題某某人在很久之前就有好的解決方案了。

這不是說自己鉆研不重要，而是這么做不值得，就像前面說的，不要重復造輪子，而在這之前，要有“先知其然，再知其所以然”的思維方式。

架構師的素養

不是誰都可以段時間內直接成為架構師的，需要有一些必備的素質和培養成的良好習慣。

溝通能力

一個人擁有知識，但是卻沒有能力清晰的表達自己，這簡直就和他從來沒有任何思想一樣。

——亞里士多德

交流不完全是一種知識，而是本領，是生產力。

——吳建民

溝通能力是通過書面、口頭和其它溝通方式表達自己的觀點的能力。架構師要和客戶，領導，開發人員，測試人員，維護人員等架構涉眾進行溝通交流，要能夠清晰的表達架構目的。

光溝通還不行，還要會溝通，要深入淺出的展現溝通。把書看厚難，再把書看薄更難。理解起來是說，看很多很多書、掌握很多很多知識很難，可是能夠把很多很多知識再融匯貫通、抽象成為言簡意賅的、深入淺出的“濃縮版”知識更難。為什么一定要架構師具備這樣的本領？架構師需要很多溝通：其中最重要的溝通是向上，與管理層溝通，向管理層報告方案的要點，獲取管理層的理解、支持和批準。

廣博的知識面

架構師不是美術師（把建筑圖紙畫的很漂亮），架構師也不是力學家或材料學家。他精通主要技術，熟悉業界的***動向，為我所用，甚至進而形成自己的設計風格和vision，然后說服管理層和團隊成員。這是架構師（Architect）和某個專項專家（SME, Subject Matter Expert）的區別。

架構師從產品的生命周期上來看，他所涉及的層面很廣，而且他所需要的知識面也會很廣，需要過程更需要時間的學習和磨練。

另外，掌握很多知識，也是有備無患，說不定哪天就能夠用上，就像上面說的“先知其然，再知其所以然”。軟件架構師除了技術知識和行業知識，還應該掌握一些其它行業和學科的知識，比如建筑學，美學，甚至哲學。

不追求***主義

前面說過，架構是有生命力的，要明白軟件架構的生命周期，設計合適的架構而不是超前的***的架構。

架構師不僅需要掌握各種相關知識,還需要有一個能夠評判利弊并進行***組合的能力。有時候,還不得不考慮到開發團隊的實際水平和效率,否則設計再理想卻難以實現,也成了紙上談兵.因此,還需要對開發團隊的成員的知識水平能有準確的判斷能力。

關注成本

企業的IT技術不同于科學研究，技術永遠都不能脫離成本來討論，這就是你不能問奔馳和賽歐孰好孰壞的原因。

架構沒有好壞之分，只有成本高低之分，如果成本過高，高過營收了，那公司賠錢，雖然也能把建筑物修建起來，但是沒有意義了，因此，架構師最核心的要務是節約成本，通過合理的架構，在盡可能滿足需求的前提下，節約成本。

出色的架構師擁有很強的成本概念，熟悉不同的技術方案的成本屬性，了解不同的業務需求對于成本的基本限制。所以，出色的架構師可以向管理層和用戶提供“適用”的、“可靠的” 的技術方案。

架構師之路

軟件架構師是軟件項目的總體設計師，是軟件組織新產品開發與集成、新技術體系的構建者，是從宏觀上駕馭大型系統的戰略家，是對軟件項目中所有重要架構事情做出決策的人，是策略制定者、組織協調高手、稱職的顧問與***。 

作為一個軟件架構師，在整個軟件系統的開發過程中是樂趣無窮的，因為這個角色很具有挑戰性，有時需要左右逢源八面玲瓏，有時又需要果斷堅定不留情面。Philippe   Kruchten曾經說過：當一個偉大的架構師領導開發團隊時，團隊的每個成員都感覺不到他的存在。次一點的架構師使開發團隊的每個成員都喜歡他，再次一點的是害怕他，最次的是鄙視他。

具體來講，架構師的職業道路有三個方向：

(1)行業應用架構。行業架構師往往是行業專家，了解行業應用需求，其架構行為主要是將需求進行合理分析布局到應用模型中去，偏向于應用功能布局。   

(2)應用系統技術體系架構。技術架構師往往是技術高手中的高手，掌握各類技術架構、掌握應用設計模式，其架構行為考慮軟件系統的高效性、復用性、安全性、可維護性、靈活性、跨平臺性等。  

(3)規范架構。規范架構師是通過多年磨礪或常年苦思頓悟后，把某一類架構抽象成一套架構規范。

這三個方向上面的道路怎么走，實在是一個太復雜的問題，而且國內很多公司可能要求一個架構師同時具備這三個方向上面的能力。所以，這路實在是不好走，而要成為前面說的那種優秀的架構師，這條道路實在是很長很長。

原文鏈接：http://www.cnblogs.com/bluedoctor/archive/2012/06/25/2560737.html

【編輯推薦】