成為一個優(yōu)秀的架構(gòu)師還有很長的路要走（軟件架構(gòu)案例分析和***實(shí)踐培訓(xùn)收獲）

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

新視野 “軟件架構(gòu)”定義的決策因素

定義1：架構(gòu)是一系列重要決策的集合

一直以來，學(xué)習(xí)架構(gòu)，使用架構(gòu)，關(guān)注點(diǎn)都僅限于技術(shù)層面，沒有認(rèn)識到架構(gòu)和“決策”的關(guān)系，這說明架構(gòu)是一個很重要的概念，從軟件架構(gòu)概念產(chǎn)生的背景可以得出：

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

定義2：軟件架構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)成系統(tǒng)的元素的描述、這些元素的相互作用、指導(dǎo)元素集成的模式以及這些模式的約束組成。

軟件架構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓?fù)浣Y(jié)構(gòu)，并且顯示了系統(tǒng)需求和構(gòu)成系統(tǒng)的元素之間的對應(yīng)關(guān)系，提供了一些設(shè)計決策的基本原理。

還有很多其它的定義方式，但從這兩個定義可以看出，架構(gòu)對于決策的重要性，架構(gòu)師的工作對于項(xiàng)目的成功運(yùn)作具有決定性的作用。

“架構(gòu)師”不是空頭銜

——不是項(xiàng)目經(jīng)理，開發(fā)人員，測試人員的兼職角色

在軟件工程領(lǐng)域中，軟件架構(gòu)師實(shí)際上就是軟件項(xiàng)目的總體設(shè)計師，是軟件組織新產(chǎn)品的開發(fā)與集成、新技術(shù)體系的構(gòu)建者。Martin Fowler（著名軟件架構(gòu)和設(shè)計大師，軟件設(shè)計模式創(chuàng)始人）指出：

架構(gòu)師是對所有重要事情做出決定的人。

軟件架構(gòu)師在整個軟件開發(fā)過程中都起著重要作用，并隨著開發(fā)進(jìn)程的推進(jìn)而其職責(zé)或關(guān)注點(diǎn)不斷地變化。

在需求階段，軟件架構(gòu)師主要負(fù)責(zé)理解和管理非功能性系統(tǒng)需求，比如軟件的可維護(hù)性、性能、復(fù)用性、可靠性、有效性和可測試性等。此外，架構(gòu)師還要經(jīng)常審查客戶和市場人員所提出的需求，確認(rèn)開發(fā)團(tuán)隊(duì)所提出的設(shè)計；在需求越來越明確后，架構(gòu)師的關(guān)注點(diǎn)開始轉(zhuǎn)移到組織開發(fā)團(tuán)隊(duì)成員和開發(fā)過程的定義上。

在軟件設(shè)計階段，架構(gòu)師負(fù)責(zé)對整個軟件架構(gòu)、關(guān)鍵構(gòu)件、接口的設(shè)計。

在編碼階段，架構(gòu)師則成為程序員的顧問，并且經(jīng)常性地要舉行一些技術(shù)研討會、技術(shù)培訓(xùn)班等。

隨著軟件開始測試、集成和交付，集成和測試支持將成為軟件架構(gòu)師的工作重點(diǎn)。

在軟件維護(hù)開始時，軟件架構(gòu)師就要開始為下一版本的產(chǎn)品是否應(yīng)該增加新的功能模塊進(jìn)行決策。 

軟件架構(gòu)視圖

——軟件架構(gòu)是一種無法以簡單的一維方式進(jìn)行說明的復(fù)雜實(shí)體。

——多重軟件架構(gòu)之所以必不可少，是因?yàn)楦黝惿姹姡ㄓ脩?，客戶，開發(fā)人員，測試人員，維護(hù)人員，內(nèi)部操作人員，其他人員）需要從各自的角度理解和使用架構(gòu)。

常用的軟件架構(gòu)視圖：

l 功能視圖

l 開發(fā)視圖

l 進(jìn)程視圖

l 部署視圖

l 場景視圖

l 數(shù)據(jù)視圖

l 實(shí)現(xiàn)視圖

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

新觀念

架構(gòu)的質(zhì)量屬性

在現(xiàn)實(shí)的系統(tǒng)中，決定系統(tǒng)成功或者失敗的關(guān)鍵因素中，滿足非功能需求往往比滿足功能性需求更為重要。從技術(shù)角度看，質(zhì)量屬性影響重要的架構(gòu)和設(shè)計策略。

質(zhì)量屬性分為系統(tǒng)質(zhì)量屬性和商業(yè)質(zhì)量屬性，其中系統(tǒng)質(zhì)量屬性又分為運(yùn)行時期的質(zhì)量屬性和開發(fā)時期的質(zhì)量屬性；商業(yè)質(zhì)量屬性包括政治因素，上市時間，成本和收益等。

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

架構(gòu)是有生命力的

運(yùn)維人員說：軟件運(yùn)行這么慢，架構(gòu)太爛了！

開發(fā)人員說：代碼這么難寫，架構(gòu)太不靈活了！

客戶說：軟件太不穩(wěn)定了，架構(gòu)有沒有問題??？

XXX說：YYY架構(gòu)師太差勁了，怎么就沒有設(shè)計出一個好架構(gòu)？

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

起初我也是這么認(rèn)為的，但是老師告訴了我們一個新觀點(diǎn)：

架構(gòu)是有生命力的！

“架構(gòu)是有生命的，是不斷變化的。因此，設(shè)計架構(gòu)不能只想著要考慮到所有的問題，設(shè)計出一個能夠包容所有可能問題的架構(gòu)，這幾乎是不可能完成的任務(wù)。因?yàn)樽兓墙^對的，架構(gòu)總是會修改，關(guān)鍵問題是何時修改？一定不能在系統(tǒng)問題頻出、已經(jīng)來不及補(bǔ)救的時候才去考慮修改，而要在潛伏的問題逐漸露出端倪之前展開行動。”

——FreeWheel CTO和聯(lián)合創(chuàng)始人 于晶純

亞馬遜，MySpace（進(jìn)行了6次架構(gòu)重構(gòu)），eBay，淘寶網(wǎng)，這些大型網(wǎng)站都是不斷地對架構(gòu)進(jìn)行重構(gòu)，對應(yīng)用進(jìn)行升級來應(yīng)對業(yè)務(wù)發(fā)展的需要的。

所以，我們不能一味的去指責(zé)FT的架構(gòu)如何差勁，MB的架構(gòu)如何糟糕，公司的這些產(chǎn)品線都是逐漸發(fā)展起來的，功能是一點(diǎn)點(diǎn)增加起來的，在功能開發(fā)***的市場戰(zhàn)略下，架構(gòu)成了次要考慮的問題，所以我們不能說當(dāng)初的架構(gòu)設(shè)計的不好，問題是在于功能增加了，應(yīng)用變復(fù)雜了，而架構(gòu)沒有跟上變化。

架構(gòu)的思維

全局觀

首先，架構(gòu)師要有全局觀，不能***摸象，要看到架構(gòu)的多個層面，多個角度。如架構(gòu)的多個視圖，架構(gòu)的質(zhì)量屬性，架構(gòu)設(shè)計，架構(gòu)模式等，都是從項(xiàng)目的全局視角來看待問題的。

設(shè)計的本質(zhì)就是一種權(quán)衡，是各類相互制約的模塊間的一種權(quán)衡。明白這一點(diǎn)，就要求架構(gòu)設(shè)計上對各個模塊應(yīng)有靈活的控制，以保證用戶期望目標(biāo)為設(shè)計出發(fā)點(diǎn)，平衡各類資源的使用。

一個好的架構(gòu)的概念是完整的，模塊間的關(guān)系是清晰簡潔，弱耦合的，模塊的接口是抽象穩(wěn)定的，模塊的實(shí)現(xiàn)是強(qiáng)內(nèi)聚和可擴(kuò)展的。

面向架構(gòu)的思考

一個目標(biāo)或一件設(shè)計任務(wù)，在架構(gòu)師的頭腦中，永遠(yuǎn)是有層次感的，是立體的，就如同草稿中的一個建筑物：它應(yīng)該是一個什么類型的建筑物，需要多少個支撐面、大概需要多高（幾層樓）、需要滿足多少功能…。

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

架構(gòu)師的一個重要素養(yǎng)或價值是將一個問題或者方案的“分類學(xué)”搞清楚 - 從幾個方面來考慮，最重要的“動因”是什么，關(guān)鍵的需要是什么，關(guān)鍵的設(shè)計要素是哪幾個。當(dāng)然，做到這一點(diǎn)需要很強(qiáng)的理論功底，也需要很豐富的經(jīng)驗(yàn)，這樣你拿出來的解決方案才有說服力。

總結(jié)和分析問題

要善于總結(jié)經(jīng)驗(yàn)，找到解決問題的***方法—架構(gòu)模式。

要善于分析和歸納問題，找到事情的變化點(diǎn)和風(fēng)險點(diǎn)，并能夠采取良好的設(shè)計規(guī)避這些不穩(wěn)定因素，這是普通和優(yōu)秀架構(gòu)師的重要區(qū)別。

站在巨人的肩山

“我之所以成功，是因?yàn)檎驹诰奕说募缟稀?rdquo;

——牛頓

“既全面又面向重點(diǎn)細(xì)節(jié)的思路，參考前人的實(shí)踐經(jīng)驗(yàn)，聚焦問題的癥結(jié)，采用安全且有創(chuàng)意的手段，追求***的精神。”

——西門子中國***架構(gòu)師 李偉

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

先知其然，再知其所以然

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

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

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

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

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

架構(gòu)師的素養(yǎng)

不是誰都可以段時間內(nèi)直接成為架構(gòu)師的，需要有一些必備的素質(zhì)和培養(yǎng)成的良好習(xí)慣。

溝通能力

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

——亞里士多德

交流不完全是一種知識，而是本領(lǐng)，是生產(chǎn)力。

——吳建民

溝通能力是通過書面、口頭和其它溝通方式表達(dá)自己的觀點(diǎn)的能力。架構(gòu)師要和客戶，領(lǐng)導(dǎo)，開發(fā)人員，測試人員，維護(hù)人員等架構(gòu)涉眾進(jìn)行溝通交流，要能夠清晰的表達(dá)架構(gòu)目的。

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

廣博的知識面

架構(gòu)師不是美術(shù)師（把建筑圖紙畫的很漂亮），架構(gòu)師也不是力學(xué)家或材料學(xué)家。他精通主要技術(shù)，熟悉業(yè)界的***動向，為我所用，甚至進(jìn)而形成自己的設(shè)計風(fēng)格和vision，然后說服管理層和團(tuán)隊(duì)成員。這是架構(gòu)師（Architect）和某個專項(xiàng)專家（SME, Subject Matter Expert）的區(qū)別。

架構(gòu)師從產(chǎn)品的生命周期上來看，他所涉及的層面很廣，而且他所需要的知識面也會很廣，需要過程更需要時間的學(xué)習(xí)和磨練。

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

不追求***主義

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

架構(gòu)師不僅需要掌握各種相關(guān)知識,還需要有一個能夠評判利弊并進(jìn)行***組合的能力。有時候,還不得不考慮到開發(fā)團(tuán)隊(duì)的實(shí)際水平和效率,否則設(shè)計再理想?yún)s難以實(shí)現(xiàn),也成了紙上談兵.因此,還需要對開發(fā)團(tuán)隊(duì)的成員的知識水平能有準(zhǔn)確的判斷能力。

關(guān)注成本

企業(yè)的IT技術(shù)不同于科學(xué)研究，技術(shù)永遠(yuǎn)都不能脫離成本來討論，這就是你不能問奔馳和賽歐孰好孰壞的原因。

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

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

架構(gòu)師之路

軟件架構(gòu)師是軟件項(xiàng)目的總體設(shè)計師，是軟件組織新產(chǎn)品開發(fā)與集成、新技術(shù)體系的構(gòu)建者，是從宏觀上駕馭大型系統(tǒng)的戰(zhàn)略家，是對軟件項(xiàng)目中所有重要架構(gòu)事情做出決策的人，是策略制定者、組織協(xié)調(diào)高手、稱職的顧問與***。 

作為一個軟件架構(gòu)師，在整個軟件系統(tǒng)的開發(fā)過程中是樂趣無窮的，因?yàn)檫@個角色很具有挑戰(zhàn)性，有時需要左右逢源八面玲瓏，有時又需要果斷堅(jiān)定不留情面。Philippe   Kruchten曾經(jīng)說過：當(dāng)一個偉大的架構(gòu)師領(lǐng)導(dǎo)開發(fā)團(tuán)隊(duì)時，團(tuán)隊(duì)的每個成員都感覺不到他的存在。次一點(diǎn)的架構(gòu)師使開發(fā)團(tuán)隊(duì)的每個成員都喜歡他，再次一點(diǎn)的是害怕他，最次的是鄙視他。

具體來講，架構(gòu)師的職業(yè)道路有三個方向：

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

(2)應(yīng)用系統(tǒng)技術(shù)體系架構(gòu)。技術(shù)架構(gòu)師往往是技術(shù)高手中的高手，掌握各類技術(shù)架構(gòu)、掌握應(yīng)用設(shè)計模式，其架構(gòu)行為考慮軟件系統(tǒng)的高效性、復(fù)用性、安全性、可維護(hù)性、靈活性、跨平臺性等。  

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

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

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

【編輯推薦】