這是我在今年上海參加亞太軟件研發(fā)團(tuán)隊管理年會時，InfoQ對我的一次采訪內(nèi)容(我自以為普通話還算行，聽了視頻，才覺得自己的普通話真是糟透了。而且在采訪之初，看得出來，我有些小小的緊張啊)。本次發(fā)言，僅代表個人觀點，未必正確。如有不妥，敬請指正。視頻請鏈接：張逸談如何評價架構(gòu)的優(yōu)劣

　　大家好，我現(xiàn)在是在亞太軟件研發(fā)團(tuán)隊管理年會，坐在我旁邊的是《軟件設(shè)計精要與模式》的作者張逸。張逸你好。
　　你好。

　　能給我們讀者先介紹一下您自己嗎？
　　我叫張逸，是麥思博（MSUP）的金牌講師，主要負(fù)責(zé)架構(gòu)和設(shè)計的培訓(xùn)和咨詢工作。在今年的上半年，我剛剛完成我這本書的第二版。目前從讀者的反饋來看，這 個書本的情況還是比較滿意。我對開發(fā)和設(shè)計架構(gòu)的經(jīng)驗，大約有十年左右的時間，先后在中興通迅、惠普和中軟國際工作，擔(dān)任的職務(wù)也有普通的開發(fā)人員、軟件 開發(fā)工程師、架構(gòu)師、項目經(jīng)理、技術(shù)總監(jiān)，在技術(shù)這塊很多角色我都擔(dān)任過，主要是在.NET方向有一定的經(jīng)驗，是2006年到2010年連續(xù)四年的微軟的 MVP。同時，我主要是在基于架構(gòu)和設(shè)計掌握了一定的知識，也愿意和大家一塊來分享架構(gòu)和設(shè)計這一塊，我的一些心得體會，謝謝。

　　那您是如何看待架構(gòu)師這個角色的？因為架構(gòu)師都包括很多職責(zé)，那您認(rèn)為他的主要的職責(zé)都有哪些，而其中最重要的又是什么？
　　說到架構(gòu)師，從在技術(shù)方面講，它應(yīng)該是很高的一個級別。我們都知道軟件的這個架構(gòu)是從建筑學(xué)里邊引喻過來的，我們稱為架構(gòu)Architecture，架構(gòu)師 是Architect。那么相對于建筑行業(yè)來說，架構(gòu)師就相對于是建筑的設(shè)計師。但是軟件行業(yè)，它跟建筑行業(yè)還有很大的區(qū)別，那么從我們業(yè)界來說，從幾個 不同的視角來看，一般的架構(gòu)師可能會把它分解為，業(yè)務(wù)架構(gòu)師、系統(tǒng)架構(gòu)師、軟件架構(gòu)師。那么整體來看，我可以打一個比方，比如說這個項目是坐在一個車上， 項目經(jīng)理就是這個開車的司機(jī)，那么架構(gòu)師，他的職責(zé)應(yīng)該是來規(guī)定汽車的行駛的路線，保障在這個車在整個行駛過程中不會出現(xiàn)任何問題，并且能夠毫無障礙的最 后能夠達(dá)到我們的目標(biāo)位置，我覺得架構(gòu)師就應(yīng)該在把握整個技術(shù)，這個項目的方向，行駛的方向。
　　那么他的職責(zé)，首先從技術(shù)方面，要非常滿足客戶需求。同時，在非功能需求方面，也能夠滿足要求的這樣一個解決方案。
　　第二，他是要在業(yè)務(wù)和技術(shù)人員兩者之間搭建一個很好的橋梁。在日本的外包開發(fā)里面，把架構(gòu)師有時候稱為Bridge，橋梁的工程師，它的意思就是相當(dāng)于把架 構(gòu)、技術(shù)和業(yè)務(wù)之間搭建一個溝通的橋梁，怎么樣把業(yè)務(wù)需求給理解分析，得到我們的領(lǐng)域模型。同時，再把這個分析后得到的結(jié)果用模型設(shè)計出來。設(shè)計出來之 后，由我們的開發(fā)人員來進(jìn)行實現(xiàn)，這是第二方面。
　　第三方面應(yīng)該是一個技術(shù)的帶頭人，就是負(fù)責(zé)在項目當(dāng)中出現(xiàn)的技術(shù)問題，我們的開發(fā)人員應(yīng)該首先通過架構(gòu)師得到比較好的指導(dǎo)的意見。
　　第四個應(yīng)該是作為一個規(guī)劃師，就像我們整個改革開放有一個規(guī)劃，幾步走，分幾步走，這樣一個規(guī)劃。那么對架構(gòu)師來說，更多的是著眼于大局，而不是細(xì)節(jié)的這種 實現(xiàn)，尤其是針對產(chǎn)品開發(fā)來說，產(chǎn)品研發(fā)來說，有一個產(chǎn)品線的這樣一個規(guī)劃，這個整體的規(guī)劃，我認(rèn)為是架構(gòu)師非常重要的一個職責(zé)。
　　那剛才您也提到了架構(gòu)師與項目經(jīng)理不同的職責(zé)，那如何來權(quán)衡一個好的團(tuán)隊中架構(gòu)師與項目經(jīng)理之間的責(zé)權(quán)呢？
　　首先，不同的開發(fā)團(tuán)隊，不同的開發(fā)周期，選擇不同的軟件開發(fā)生命周期，可能在職責(zé)方面，他們的關(guān)系方面是有些區(qū)別的。從傳統(tǒng)的軟件開發(fā)管理來說，比如說瀑布 式的、迭代的、RUP的，這些方面的組織結(jié)構(gòu)相對來說，不是一個平行的結(jié)構(gòu)，是有一個上下級的這種關(guān)系。但是在這種團(tuán)隊里面，項目經(jīng)理和架構(gòu)師應(yīng)該是兩個 不同的關(guān)系，一方面是一個上下級的關(guān)系，也就是說架構(gòu)師還是要向項目經(jīng)理來負(fù)責(zé)，項目經(jīng)理負(fù)責(zé)安排架構(gòu)師的一些工作，這是一方面的關(guān)系。
　　但是另外一個更重要的關(guān)系是，架構(gòu)師和項目經(jīng)理應(yīng)該是一個Partner的關(guān)系，就是合作的這種關(guān)系。因為項目經(jīng)理是負(fù)責(zé)整個項目管理這一塊，他更多的是操 心的是怎么完成項目的進(jìn)度，進(jìn)度的安排，任務(wù)的跟蹤，還有跟客戶的協(xié)調(diào)。而架構(gòu)師則是從技術(shù)方面以及業(yè)務(wù)的分析方面來完成，所以他們兩個在這個層面上來 說，應(yīng)該是一個平行的這種關(guān)系。但是在很多敏捷的團(tuán)隊里邊，因為這個角色的劃分就不是很清晰。例如以Scrum來說，那么Scrum Master就相當(dāng)于是我們傳統(tǒng)所謂的項目經(jīng)理，但是他的管理的職責(zé)權(quán)限被弱化了很多，而更多的是起到一個指導(dǎo)以及配合的這樣一個作用。同時Scrum Master主要是負(fù)責(zé)把我們這個團(tuán)隊，把Scrum這個團(tuán)隊能夠更好的運(yùn)作起來。那么在這個團(tuán)隊里面，就沒有所謂架構(gòu)師這樣一個職責(zé)，那么也許每個團(tuán)隊 成員可能都會成為架構(gòu)師。像這樣一個情況的話，根據(jù)我以前呆的項目來看的話，如果我們過于強(qiáng)化這種架構(gòu)師的這種角色，有可能會對我們整個團(tuán)隊，會造成一定 傷害。像這種情況，我們就需要每個團(tuán)隊成員，發(fā)揮自己的這種自主能力，以平行的方式，在設(shè)計方面，更多的是以協(xié)作的方式，而不是以管理的方式來完成，這是 我的一個理解。

　　您剛才說會帶來一些傷害，是過于強(qiáng)調(diào)架構(gòu)師帶來的傷害嗎？
　　因為之前，我在惠普有一個項目，我們在實施Scrum，但是我們原來有一種傳統(tǒng)的，由于在公司，實施Scrum也是第一次，大家都沒有經(jīng)驗。我們當(dāng)時我們的團(tuán) 隊成員，在開發(fā)能力方面、經(jīng)驗方面，還是有一定欠缺，所以當(dāng)時由我來擔(dān)任整個團(tuán)隊的架構(gòu)師這個角色。但是在Scrum里面，本來是沒有這個角色的，但是由 于我們這個團(tuán)隊的特殊情況，增加這個角色。結(jié)果后來導(dǎo)致什么呢，就是我們這個團(tuán)隊，每個團(tuán)隊成員的這種主動性、積極性有一定的影響，他會對架構(gòu)師產(chǎn)生一種 依賴，覺得有什么問題都會去找我，出現(xiàn)了技術(shù)方面把握不好，乃至于從需求方面把握不好的，都會來找我，這樣就會導(dǎo)致我們沒有形成一個Team。我覺得這一 方面來說，可能會造成一些影響，其實這也是在敏捷，在咱們中國有些小的公司，或者來自于一些大的公司推廣起來，出現(xiàn)一個障礙的一個大的問題，就是我們團(tuán)隊 成員，在能力上還很難達(dá)到每個人都夠完整的來完成業(yè)務(wù)的分析、設(shè)計，最后編碼實現(xiàn)一些測試。在宏觀這個角度來說，很多人不具備這個大局觀。因此，在架構(gòu)方 面也有很多欠缺，這是我的一個心得體會。
　　很多架構(gòu)師都是從程序員轉(zhuǎn)型過來的，在轉(zhuǎn)型的過程中，您認(rèn)為哪些要素是比較重要的，哪些要素又是比較難于把握的，如何來應(yīng)對這個轉(zhuǎn)型之痛呢？
　　這件事確實是存在一個問題，我也跟很多一些剛剛踏入這個行業(yè)的程序員有過溝通，首先我問到他們的理想，如果是選擇技術(shù)這塊，他們的理想都是架構(gòu)師。這個問題 在我們這個行業(yè)來說是很突出的，我也和很多剛剛踏入這個行業(yè)的一些開發(fā)人員有過交流，我問到他們的理想，將來準(zhǔn)備做什么，有的是想做管理，有的是想做技 術(shù)。那么想做技術(shù)的這些開發(fā)人員來說，他們都很向往這種架構(gòu)師的角色，應(yīng)該說架構(gòu)師也確實是站在技術(shù)這塊是最高的級別。但是他們怎么成為架構(gòu)師，在這個過 程當(dāng)中，他們應(yīng)該做什么事情，應(yīng)該怎么去往這個方向努力，其實他們都很茫然。事實上我們也知道，現(xiàn)在我們這個行業(yè)很多架構(gòu)師，尤其是做技術(shù)的這些架構(gòu)師， 他們很多都是從開發(fā)人員這樣一步一步走上來的。
　　但是在這個過程當(dāng)中，有的人就倒下了，有的人就一直就是成為一名普通的開發(fā)人員，或者軟件 工程師，沒有走上這樣一個層面。原因就在于，架構(gòu)師需要的能力和開發(fā)人員需要的能力還是有區(qū)別的，我們要求架構(gòu)師要有實現(xiàn)方面能力，這跟做建筑這塊不一 樣，建筑方面可以直接培養(yǎng)一個架構(gòu)師，但是就我們這個行業(yè)來說，從學(xué)院里面培養(yǎng)出來一個架構(gòu)師是不大可能的，是需要有很多經(jīng)驗的積累，也是要有編碼的這樣 一些技巧，這是必須的。就是架構(gòu)師必須要了解實現(xiàn)，但是如果停留在實現(xiàn)這個層面，就不可能成為一名合格的架構(gòu)師，是因為架構(gòu)師把握的更多的是大局的東西， 是一個更高層面的、抽象方面的知識。
　　怎么才能成為一名架構(gòu)師呢，需要在這方面有意識的培養(yǎng)自己，第一個培養(yǎng)，就是從行業(yè)這塊，因為做我們 這個軟件行業(yè)，根據(jù)不同的領(lǐng)域，領(lǐng)域模型可能不一樣，業(yè)務(wù)流程不一樣，業(yè)務(wù)規(guī)則不一樣。那么如果你對這個行業(yè)的業(yè)務(wù)規(guī)則、業(yè)務(wù)流程不清楚，你也很難得到一 個好的理論模型，也就很難得到一個好的架構(gòu)，所以從行業(yè)這方面，要有意識的培養(yǎng)這方面的能力。就是你可以集中在你公司所從事的一些行業(yè)，比如金融行業(yè)，或 者制造行業(yè)，或者保險行業(yè)，電信、通訊這方面的行業(yè)，要有這方面的能力，你要有意識去積累。而不是要埋頭光顧著寫代碼，而是有意識的去參與一些需求這塊的 理解和分析，這是我認(rèn)為第一個。
　　第二個，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因為架構(gòu)師所需要具備的最大的、最強(qiáng) 的一個能力，就是能夠從很紛繁復(fù)雜的需求當(dāng)中，從很多細(xì)節(jié)實現(xiàn)當(dāng)中，能夠去抽象出一個共同的東西出來，能夠從不同的地方，能夠找到共同的地方，也就是所謂 的共性和可變性這樣一種分析，他們在這一方面的能力把握的非常好。然后這一方面的能力，把握抽象出來以后，還要把它形成為一個模型，形成出領(lǐng)域模型、分析 模型、設(shè)計模型，通過這個模型的方式來把它表達(dá)出來，就是我認(rèn)為要有意識的要積累這方面的能力。
　　第三個，我認(rèn)為應(yīng)該有意識的、有前瞻性的 去了解這方面的知識，不管是從網(wǎng)絡(luò)上，包括像咱們InfoQ也有一個架構(gòu)的專區(qū)，架構(gòu)專區(qū)有很多很優(yōu)秀的文章，都是國內(nèi)外一流的架構(gòu)師寫的一些文章，可以 有意識的去看這些方面的文章，或者是讀一些優(yōu)秀的書籍。那么從這方面來培養(yǎng)你在架構(gòu)這一塊的能力。
　　第四個我覺得還有一個交流，有意識的提 高交流，很多開發(fā)人員為什么沒有在最后成為架構(gòu)師，就是因為他們很多技術(shù)人員可能比較內(nèi)向，偏向于研究，偏向于和機(jī)器打交道，而忽略了和人打交道。而架構(gòu) 師，我剛才也說了，架構(gòu)師是在業(yè)務(wù)和實現(xiàn)的技術(shù)人員兩者之間搭建一個橋梁，這橋梁一方面是從書面的角度、文檔的角度來進(jìn)行協(xié)作、交流，另外一方面就是口頭 方面來交流，而我們開發(fā)人員在這一方面還有所欠缺。所以我認(rèn)為，開發(fā)人員要最后成長為一個架構(gòu)師，第一個你要把目標(biāo)定好，定好之后，就要有意識的往這個方 向去發(fā)展，要培養(yǎng)架構(gòu)師具備的這些能力。再根據(jù)多做一些項目，有效的、及時的去總結(jié)這些項目的經(jīng)驗，或者說及時的去學(xué)習(xí)一些，因為你可能是開發(fā)人員，但是 在你的項目組里邊，肯定有架構(gòu)師類似這樣的角色存在，那么你可以有意識的向這個架構(gòu)師去學(xué)習(xí)，或者說從他那個地方得到的一些東西、方案，你學(xué)會去思索，去 思考，這樣我覺得慢慢的從經(jīng)驗上去積累，從技術(shù)上去積累，從能力上去提高，慢慢的我想，給你一個好的機(jī)會，一定能會成為一名合格的，乃至于優(yōu)秀的架構(gòu)師。
　　那您剛才說的這幾點中，其中哪一點是比較難以把握的？對一個程序員來說，比較困難的反面具體有哪些？
　　困難應(yīng)該還是抽象的能力和大局觀的能力。因為我們要求開發(fā)人員的能力，就是要求他具體的實現(xiàn)能力，把握細(xì)節(jié)，某一個算法的一個實現(xiàn)，然后某一個業(yè)務(wù)流程，他 怎么去實現(xiàn)，或者某一個技術(shù)，不管是什么語言，或者什么平臺，某一個技術(shù)，比如說安全，或者是寫一個Web Service，或者是寫一個權(quán)限管理。在這一塊來說，他們的能力是很強(qiáng)的，但是怎么把它提取到更高的抽象能力和大局觀這塊，我覺得很多開發(fā)人員都比較欠 缺。
　　那您剛才也提到了對技術(shù)和業(yè)務(wù)對于架構(gòu)師的影響，架構(gòu)師需要成為技術(shù)專家嗎？或者是他也需要成為業(yè)務(wù)專家嗎？為什么？
　　首先從技術(shù)角度先說一下，對于架構(gòu)師我的看法是首先要專，然后是博。就是第一個，必須得深入去了解你所擅長的某一個框架，某一個平臺，一定要專。我說所謂的 專，不是說把它每個細(xì)節(jié)都掌握得很清楚，而是要把它內(nèi)在的原理搞得很清楚，這樣即使碰到一個新的問題，你也可以能夠很快的解決。因為架構(gòu)師在基礎(chǔ)這塊，要 樹立起技術(shù)的權(quán)威，如果你設(shè)計出來的模型你自己都不清楚，我打個比方來說，你對通訊的協(xié)議都不清楚，你怎么去做架構(gòu)設(shè)計，你怎么去把握它，所以必須得專。
　　但是，還有一個很重要的就是要博，因為我們做架構(gòu)、做軟件，不一定是，一直做項目都會只用一個平臺，只用一門技術(shù)，而且現(xiàn)在的項目，其實有一個發(fā)展，是多語 言、多平臺共存的這樣一種發(fā)展，很多項目我們看到都有這種趨勢。那么如果說你只懂一門技術(shù)，只鉆一門框架，只鉆一門平臺，那么當(dāng)需要你去集成多個系統(tǒng)的時 候，你可能就束手無策了，所以一定要博。那么博的意思是說，由于軟件，不管是什么平臺，不管是什么框架，不管是什么語言，其實它的原理是相通的。由于你專 了，所以你對它的語言、原理、平臺的機(jī)制都很清楚，你要再去快速的掌握其他的技術(shù)，是非常容易的。但是又有區(qū)別，你需要去把握它不同的地方，同時你還可以 取長補(bǔ)短，你可以用另外一個技術(shù)的優(yōu)勢來彌足你現(xiàn)在所用的技術(shù)的缺陷，所以這是我對技術(shù)方面的認(rèn)為。
　　而從業(yè)務(wù)來說，你要成為一位行業(yè)的專 家，當(dāng)然是最好，但是人的精力是有限的。一般來說我們有兩種情況，一種情況就是如果這個架構(gòu)師，他一直只做一個方向，就是他一直做汽車制造這塊，那他可能 隨著經(jīng)驗的積累，慢慢慢慢的，他可能會成為一個汽車行業(yè)專家。但是事實上這種情況是很少的，很多架構(gòu)師可能會面對另外一個新的項目，比如說你原來做汽車制 造，現(xiàn)在讓你做金融的，那你該怎么辦？所以我們一般的做法是，如果一個大的公司、大的團(tuán)隊，我們會有專門的領(lǐng)域?qū)＜遥深I(lǐng)域?qū)＜襾碡?fù)責(zé)業(yè)務(wù)這塊，或者由客 戶來負(fù)責(zé)業(yè)務(wù)這塊。但是我們的架構(gòu)師也必須要對業(yè)務(wù)要有一定的了解，至少你要把一些行業(yè)的術(shù)語要搞清楚，這樣你才能夠和你的客戶和領(lǐng)域?qū)＜以跍贤ㄉ蠜]有任 何的問題，所以我不認(rèn)為說，每個架構(gòu)師都必須得成為一個業(yè)務(wù)專家，但是至少你在做這個架構(gòu)之前，你必須要了解這個業(yè)務(wù)，了解這個行業(yè)。
　　下面我們談一下如何來評價架構(gòu)的優(yōu)劣，有沒有什么切實可用的定量或者定性的指標(biāo)？您在之前的項目中是如何來評價系統(tǒng)架構(gòu)的好壞的？
　　這個問題我覺得，應(yīng)該說也是一個難題。我們也看到有很多項目，包括有很多很牛的架構(gòu)師，開發(fā)團(tuán)隊也很好，公司也很好，但是失敗了，那原因有很多，架構(gòu)這一塊其實是一個至關(guān)重要的。架構(gòu)一般我認(rèn)為從功能需求方面和非功能需求方面，可以分成這兩大方面。
　　從功能需求方面來說，如何去衡量架構(gòu)師是成功的、是好的，其實很簡單，就是要滿足功能、滿足客戶需求。那我們可以利用一些方法，比如說需求矩陣、用需求跟蹤 這些方面，或者通過原形這些角度來和客戶進(jìn)行溝通，通過客戶這邊來了解我們這個架構(gòu)方案在功能需求方面是否滿足需求。然后我們可以利用一些方法，比如驅(qū)動 設(shè)計，或者通過用力這些方式去驅(qū)動，把領(lǐng)域模式，也就是所謂的業(yè)務(wù)模型，把它建好。
　　從非功能性需求來說，其實是架構(gòu)的一個難題，提到有安 全方面、性能方面、可擴(kuò)展性、可伸縮性，要求都很多。比如我們現(xiàn)在，都知道像Twitter、 FaceBook，他們的業(yè)務(wù)都很簡單，像Twitter就很簡單，我follow你，然后你去follow我，那業(yè)務(wù)很簡單。但是作為一個 Twitter的架構(gòu)師要求很高，要求最高的可能在性能、安全穩(wěn)定性這塊，因為訪問的人很多，所以性能這塊如何去衡量，就需要有一些衡量的指標(biāo)，比如響應(yīng) 時間之類的。在業(yè)界有很多解決這種非功能性需求方面的通用的一些方法，比如從性能角度來說，一般是利用緩存，在硬件方面不能再高的改善的情況之下，最重要 的可能就是利用緩存，不管是用普通的緩存，還是用分布式緩沖。另外就是考慮可伸縮性，通過集群的方式，增加服務(wù)器的方式來提高這種性能。這些東西呢，我們 就是在做架構(gòu)的時候，我覺得在前期就要考慮好。
　　而且我覺得還有一個方法，就是把每一個功能、非功能性的因素，在權(quán)衡或者評價這個架構(gòu)是否 合適的時候，可以把它的因素擴(kuò)大化，比如原來客戶只要求能夠承擔(dān)十萬人同時上線，你可以把它放大，你放大到一百萬人，當(dāng)同時上線的人數(shù)達(dá)到一百萬人的時 候，這個架構(gòu)會不會出問題，通過這樣一種方式，就是把某一個因素擴(kuò)大化，來衡量你的架構(gòu)。另外一個預(yù)先做調(diào)研，預(yù)先做架構(gòu)，架構(gòu)這塊我可以先做，先做出一 個原形出來，架構(gòu)的原形，我們通過一些測試手段，通過壓力測試，這方面的一些測試手段，來權(quán)衡這個架構(gòu)是否有問題。
　　那就像你剛才說的，一個系統(tǒng)做到最后，往往會因為一些非功能性的因為成為它的一個瓶頸，像安全、可伸縮性，那架構(gòu)師在這個階段會起到什么作用？
　　應(yīng)該說這個時候架構(gòu)師扮演的是救火人員、消防人員的這樣一個角色，其實做到后面出問題，本身從職責(zé)來看，本來就是架構(gòu)師的問題，你之前沒考慮到，比如我們做 一個醫(yī)保項目，之前你不考慮，網(wǎng)絡(luò)斷開的情況之下，怎么來處理應(yīng)對這種情況，比如說突然網(wǎng)絡(luò)斷了，難道就讓這個系統(tǒng)停掉嗎，讓它不能支撐這種斷線的、離線 的這種方式，如果沒考慮，肯定就有問題。所以首先第一點，其實也是剛才我說的，最開始就要考慮去這些問題，我們都說要考慮未來，在功能上來說，去考慮未來 很困難的，不可能今天去考慮到未來很多年后功能的變化，敏捷這個角度來說也是這樣去分析，我們只說今天要做的事情。但是從非功能性需求方面，你可以適當(dāng)?shù)?考慮一下未來，考慮一下未來在性能上、安全上、在可伸縮性方面、可擴(kuò)展性方面，他的要求，所以你先要去考慮。
　　如果你預(yù)先去考慮到這些東 西，那么后來出現(xiàn)問題的可能性就會少很多，當(dāng)然如果真是出現(xiàn)的話，怎么辦？這個時候其實沒有其他的辦法，只有是架構(gòu)師的這種經(jīng)驗。另外架構(gòu)師不要搞的太固 步自封，或者過于的自信，覺得丟面子，去求助于別人，其實架構(gòu)師不是所有都懂，比如在硬件、網(wǎng)絡(luò)、安全，會有專門的網(wǎng)絡(luò)專家、硬件專家和安全專家，我們稱 為叫基礎(chǔ)設(shè)施，基礎(chǔ)設(shè)施也有架構(gòu)師，你作為這個項目的主要負(fù)責(zé)架構(gòu)師，大項目有一個架構(gòu)師團(tuán)隊，小的項目你可以去尋求幫助，尋求其他的公司或者我們公司的 其他人，尋求幫助，盡快的解決這個問題。在出現(xiàn)這個問題的時候，首先要找到原因，找到它的癥結(jié)所在，然后解決方案的提出，你可以根據(jù)你的經(jīng)驗，同時也要尋 求幫助，盡快的解決這個問題。我覺得很多架構(gòu)師就是面子觀念，我都是很No.1的，我是Leader，怎么我還去尋求其他人的幫助？但事實上每個架構(gòu)師都 有他的短板。
　　那架構(gòu)師需要參與到日常的編碼工作嗎？
　　我到是覺得需要。
　　那架構(gòu)師如何來保持技術(shù)的敏銳度？
　　這個我覺得就是剛才你提到一個問題，就是需不需要編碼，我覺得編碼也是能夠提高他的技術(shù)敏銳度。但是這個編碼，我的理解是這樣的，架構(gòu)最好是寫一些編碼，第 一個最好是寫整個解決方案的大體上的一些編碼，而不是去摳這些具體的算法，一些細(xì)節(jié)的實現(xiàn)，比如說我甚至可以寫一個框架性的東西出來，然后具體的實現(xiàn)由開 發(fā)人員去填，另外比較困難的東西，可以由你來編碼去解決。還有從面向?qū)ο蟮慕嵌葋碚f，你可以寫一些基類或者抽象類，把一些共同的東西提取出來。如何保持敏 銳度呢，首先編碼這個角度來說，我們要隨時磨煉，我知道像我們很多世界一流的，象Kent Beck、Martin Fowler這些人，他們每天都還在寫代碼，就是要提高這方面能力，如果長期不寫，就有可能到真正去做項目的時候，碰到一個問題需要你來寫的時候，你寫不 出來。
　　最后對于有志于成長為架構(gòu)師這些眾多的開發(fā)者來說，你有沒有什么比較好的指導(dǎo)建議能夠幫助大家能夠快速高效的成長，其中當(dāng)然彎路是必不可少，如何來避免少走彎路呢？
　　第一個就是，要認(rèn)清自己，就說你的特長是什么，你的性格，你自己要有充分的了解，如果你確實在協(xié)調(diào)能力方面、組織能力方面、口頭表達(dá)能力方面、交流能力方 面、抽象能力方面你達(dá)不到，你可以選擇另外路子。而不是覺得架構(gòu)師好，你就一定要去做，其實在這個行業(yè)有很多角色都是非常好的，走到最后成為專家照樣是能 夠得到很好的事業(yè)，第一個要認(rèn)清自己；第二個要認(rèn)清目標(biāo)，認(rèn)清了自己之后，你還要認(rèn)清目標(biāo)，你的目標(biāo)是什么。而且你這個目標(biāo)有一個近期的短期和長期目標(biāo)， 你在近一年要做什么事情，過三年、五年你要達(dá)到一個什么樣的高度，這是第二個。
　　第三，要找到適合自己的方法，因為每個人的能力不一樣，特 長不一樣，學(xué)習(xí)方法可能都不一樣，那么你的方法是什么，你要找到。比如說你可以通過多去閱讀源代碼，閱讀一些開源的項目，或者說你可以多看書，多做項目之 后，你可以在網(wǎng)上多找一些相關(guān)的文檔，這些都是一些好的學(xué)習(xí)方法，像我現(xiàn)在每天保持閱讀網(wǎng)絡(luò)上的一些文章，或者是閱讀書籍，特別有的書籍，是一些很一流 的，戰(zhàn)斗在一線的架構(gòu)師，寫的一些心得體會的總結(jié)。有的東西，可能在我們做的項目根本就沒辦法碰得到，但是在將來的項目中有可能會碰到，如果你還寄希望于 在將來的時候碰到問題的時候你再去找，那就會出現(xiàn)很大的問題，所以這是我說的第三個要找到自己學(xué)習(xí)的方法。
　　第四，未雨綢繆，你要事先做好 準(zhǔn)備，打下堅實的基礎(chǔ)；最后一個，我認(rèn)為最重要的是，基礎(chǔ)很關(guān)鍵，不要好高騖遠(yuǎn)，不要一下子我要成為架構(gòu)師了，好，我現(xiàn)在就去面向?qū)ο笏枷胛叶疾惶私猓?設(shè)計模式我都不太了解，好，我現(xiàn)在就去搞架構(gòu)模式，我去做架構(gòu)的研究，我去分析這些架構(gòu)的整個實現(xiàn)的原理，你根本就沒有辦法去掌握，所以你先要腳踏實地的 先把最關(guān)鍵、最基礎(chǔ)的東西先掌握好，就像我剛才說的要先專后博。先把這個東西研究的很透，而且不要抱著一個思想，就說我知道了就行了，要知其然，而不知其 所以然，這樣就會有很大的問題，我們要去把它研究透。包括像現(xiàn)在，就拿C#這種語言來說，你可能覺得這門語言你很清楚了，但事實上這個C#里面，涉及到框 架的，比如說PC垃圾回收怎么運(yùn)行機(jī)制，內(nèi)存的管理是怎么去管理的，多線程是怎么處理的，并發(fā)是怎么去解決的，有很多很多東西需要深入的去分析，而不是盲 目的知道C#的語法就夠了，這五點對于開發(fā)者來說是一個比較重要的，應(yīng)該說是比較重要的一個能力。
　　好，非常感謝您接受我們的采訪。

it知識庫：如何評價架構(gòu)的優(yōu)劣，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。