|
|
這是我在今年上海參加亞太軟件研發團隊管理年會時，InfoQ對我的一次采訪內容(我自以為普通話還算行，聽了視頻，才覺得自己的普通話真是糟透了。而且在采訪之初，看得出來，我有些小小的緊張啊)。本次發言，僅代表個人觀點，未必正確。如有不妥，敬請指正。視頻請鏈接：張逸談如何評價架構的優劣
大家好，我現在是在亞太軟件研發團隊管理年會，坐在我旁邊的是《軟件設計精要與模式》的作者張逸。張逸你好。
你好。
能給我們讀者先介紹一下您自己嗎？
我叫張逸，是麥思博（MSUP）的金牌講師，主要負責架構和設計的培訓和咨詢工作。在今年的上半年，我剛剛完成我這本書的第二版。目前從讀者的反饋來看，這 個書本的情況還是比較滿意。我對開發和設計架構的經驗，大約有十年左右的時間，先后在中興通迅、惠普和中軟國際工作，擔任的職務也有普通的開發人員、軟件 開發工程師、架構師、項目經理、技術總監，在技術這塊很多角色我都擔任過，主要是在.NET方向有一定的經驗，是2006年到2010年連續四年的微軟的 MVP。同時，我主要是在基于架構和設計掌握了一定的知識，也愿意和大家一塊來分享架構和設計這一塊，我的一些心得體會，謝謝。
那您是如何看待架構師這個角色的？因為架構師都包括很多職責，那您認為他的主要的職責都有哪些，而其中最重要的又是什么？
說到架構師，從在技術方面講，它應該是很高的一個級別。我們都知道軟件的這個架構是從建筑學里邊引喻過來的，我們稱為架構Architecture，架構師 是Architect。那么相對于建筑行業來說，架構師就相對于是建筑的設計師。但是軟件行業，它跟建筑行業還有很大的區別，那么從我們業界來說，從幾個 不同的視角來看，一般的架構師可能會把它分解為，業務架構師、系統架構師、軟件架構師。那么整體來看，我可以打一個比方，比如說這個項目是坐在一個車上， 項目經理就是這個開車的司機，那么架構師，他的職責應該是來規定汽車的行駛的路線，保障在這個車在整個行駛過程中不會出現任何問題，并且能夠毫無障礙的最 后能夠達到我們的目標位置，我覺得架構師就應該在把握整個技術，這個項目的方向，行駛的方向。
那么他的職責，首先從技術方面，要非常滿足客戶需求。同時，在非功能需求方面，也能夠滿足要求的這樣一個解決方案。
第二，他是要在業務和技術人員兩者之間搭建一個很好的橋梁。在日本的外包開發里面，把架構師有時候稱為Bridge，橋梁的工程師，它的意思就是相當于把架 構、技術和業務之間搭建一個溝通的橋梁，怎么樣把業務需求給理解分析，得到我們的領域模型。同時，再把這個分析后得到的結果用模型設計出來。設計出來之 后，由我們的開發人員來進行實現，這是第二方面。
第三方面應該是一個技術的帶頭人，就是負責在項目當中出現的技術問題，我們的開發人員應該首先通過架構師得到比較好的指導的意見。
第四個應該是作為一個規劃師，就像我們整個改革開放有一個規劃，幾步走，分幾步走，這樣一個規劃。那么對架構師來說，更多的是著眼于大局，而不是細節的這種 實現，尤其是針對產品開發來說，產品研發來說，有一個產品線的這樣一個規劃，這個整體的規劃，我認為是架構師非常重要的一個職責。
那剛才您也提到了架構師與項目經理不同的職責，那如何來權衡一個好的團隊中架構師與項目經理之間的責權呢？
首先，不同的開發團隊，不同的開發周期，選擇不同的軟件開發生命周期，可能在職責方面，他們的關系方面是有些區別的。從傳統的軟件開發管理來說，比如說瀑布 式的、迭代的、RUP的，這些方面的組織結構相對來說，不是一個平行的結構，是有一個上下級的這種關系。但是在這種團隊里面，項目經理和架構師應該是兩個 不同的關系，一方面是一個上下級的關系，也就是說架構師還是要向項目經理來負責，項目經理負責安排架構師的一些工作，這是一方面的關系。
但是另外一個更重要的關系是，架構師和項目經理應該是一個Partner的關系，就是合作的這種關系。因為項目經理是負責整個項目管理這一塊，他更多的是操 心的是怎么完成項目的進度，進度的安排，任務的跟蹤，還有跟客戶的協調。而架構師則是從技術方面以及業務的分析方面來完成，所以他們兩個在這個層面上來 說，應該是一個平行的這種關系。但是在很多敏捷的團隊里邊，因為這個角色的劃分就不是很清晰。例如以Scrum來說，那么Scrum Master就相當于是我們傳統所謂的項目經理，但是他的管理的職責權限被弱化了很多，而更多的是起到一個指導以及配合的這樣一個作用。同時Scrum Master主要是負責把我們這個團隊，把Scrum這個團隊能夠更好的運作起來。那么在這個團隊里面，就沒有所謂架構師這樣一個職責，那么也許每個團隊 成員可能都會成為架構師。像這樣一個情況的話，根據我以前呆的項目來看的話，如果我們過于強化這種架構師的這種角色，有可能會對我們整個團隊，會造成一定 傷害。像這種情況，我們就需要每個團隊成員，發揮自己的這種自主能力，以平行的方式，在設計方面，更多的是以協作的方式，而不是以管理的方式來完成，這是 我的一個理解。
您剛才說會帶來一些傷害，是過于強調架構師帶來的傷害嗎？
因為之前，我在惠普有一個項目，我們在實施Scrum，但是我們原來有一種傳統的，由于在公司，實施Scrum也是第一次，大家都沒有經驗。我們當時我們的團 隊成員，在開發能力方面、經驗方面，還是有一定欠缺，所以當時由我來擔任整個團隊的架構師這個角色。但是在Scrum里面，本來是沒有這個角色的，但是由 于我們這個團隊的特殊情況，增加這個角色。結果后來導致什么呢，就是我們這個團隊，每個團隊成員的這種主動性、積極性有一定的影響，他會對架構師產生一種 依賴，覺得有什么問題都會去找我，出現了技術方面把握不好，乃至于從需求方面把握不好的，都會來找我，這樣就會導致我們沒有形成一個Team。我覺得這一 方面來說，可能會造成一些影響，其實這也是在敏捷，在咱們中國有些小的公司，或者來自于一些大的公司推廣起來，出現一個障礙的一個大的問題，就是我們團隊 成員，在能力上還很難達到每個人都夠完整的來完成業務的分析、設計，最后編碼實現一些測試。在宏觀這個角度來說，很多人不具備這個大局觀。因此，在架構方 面也有很多欠缺，這是我的一個心得體會。
很多架構師都是從程序員轉型過來的，在轉型的過程中，您認為哪些要素是比較重要的，哪些要素又是比較難于把握的，如何來應對這個轉型之痛呢？
這件事確實是存在一個問題，我也跟很多一些剛剛踏入這個行業的程序員有過溝通，首先我問到他們的理想，如果是選擇技術這塊，他們的理想都是架構師。這個問題 在我們這個行業來說是很突出的，我也和很多剛剛踏入這個行業的一些開發人員有過交流，我問到他們的理想，將來準備做什么，有的是想做管理，有的是想做技 術。那么想做技術的這些開發人員來說，他們都很向往這種架構師的角色，應該說架構師也確實是站在技術這塊是最高的級別。但是他們怎么成為架構師，在這個過 程當中，他們應該做什么事情，應該怎么去往這個方向努力，其實他們都很茫然。事實上我們也知道，現在我們這個行業很多架構師，尤其是做技術的這些架構師， 他們很多都是從開發人員這樣一步一步走上來的。
但是在這個過程當中，有的人就倒下了，有的人就一直就是成為一名普通的開發人員，或者軟件 工程師，沒有走上這樣一個層面。原因就在于，架構師需要的能力和開發人員需要的能力還是有區別的，我們要求架構師要有實現方面能力，這跟做建筑這塊不一 樣，建筑方面可以直接培養一個架構師，但是就我們這個行業來說，從學院里面培養出來一個架構師是不大可能的，是需要有很多經驗的積累，也是要有編碼的這樣 一些技巧，這是必須的。就是架構師必須要了解實現，但是如果停留在實現這個層面，就不可能成為一名合格的架構師，是因為架構師把握的更多的是大局的東西， 是一個更高層面的、抽象方面的知識。
怎么才能成為一名架構師呢，需要在這方面有意識的培養自己，第一個培養，就是從行業這塊，因為做我們 這個軟件行業，根據不同的領域，領域模型可能不一樣，業務流程不一樣，業務規則不一樣。那么如果你對這個行業的業務規則、業務流程不清楚，你也很難得到一 個好的理論模型，也就很難得到一個好的架構，所以從行業這方面，要有意識的培養這方面的能力。就是你可以集中在你公司所從事的一些行業，比如金融行業，或 者制造行業，或者保險行業，電信、通訊這方面的行業，要有這方面的能力，你要有意識去積累。而不是要埋頭光顧著寫代碼，而是有意識的去參與一些需求這塊的 理解和分析，這是我認為第一個。
第二個，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因為架構師所需要具備的最大的、最強 的一個能力，就是能夠從很紛繁復雜的需求當中，從很多細節實現當中，能夠去抽象出一個共同的東西出來，能夠從不同的地方，能夠找到共同的地方，也就是所謂 的共性和可變性這樣一種分析，他們在這一方面的能力把握的非常好。然后這一方面的能力，把握抽象出來以后，還要把它形成為一個模型，形成出領域模型、分析 模型、設計模型，通過這個模型的方式來把它表達出來，就是我認為要有意識的要積累這方面的能力。
第三個，我認為應該有意識的、有前瞻性的 去了解這方面的知識，不管是從網絡上，包括像咱們InfoQ也有一個架構的專區，架構專區有很多很優秀的文章，都是國內外一流的架構師寫的一些文章，可以 有意識的去看這些方面的文章，或者是讀一些優秀的書籍。那么從這方面來培養你在架構這一塊的能力。
第四個我覺得還有一個交流，有意識的提 高交流，很多開發人員為什么沒有在最后成為架構師，就是因為他們很多技術人員可能比較內向，偏向于研究，偏向于和機器打交道，而忽略了和人打交道。而架構 師，我剛才也說了，架構師是在業務和實現的技術人員兩者之間搭建一個橋梁，這橋梁一方面是從書面的角度、文檔的角度來進行協作、交流，另外一方面就是口頭 方面來交流，而我們開發人員在這一方面還有所欠缺。所以我認為，開發人員要最后成長為一個架構師，第一個你要把目標定好，定好之后，就要有意識的往這個方 向去發展，要培養架構師具備的這些能力。再根據多做一些項目，有效的、及時的去總結這些項目的經驗，或者說及時的去學習一些，因為你可能是開發人員，但是 在你的項目組里邊，肯定有架構師類似這樣的角色存在，那么你可以有意識的向這個架構師去學習，或者說從他那個地方得到的一些東西、方案，你學會去思索，去 思考，這樣我覺得慢慢的從經驗上去積累，從技術上去積累，從能力上去提高，慢慢的我想，給你一個好的機會，一定能會成為一名合格的，乃至于優秀的架構師。
那您剛才說的這幾點中，其中哪一點是比較難以把握的？對一個程序員來說，比較困難的反面具體有哪些？
困難應該還是抽象的能力和大局觀的能力。因為我們要求開發人員的能力，就是要求他具體的實現能力，把握細節，某一個算法的一個實現，然后某一個業務流程，他 怎么去實現，或者某一個技術，不管是什么語言，或者什么平臺，某一個技術，比如說安全，或者是寫一個Web Service，或者是寫一個權限管理。在這一塊來說，他們的能力是很強的，但是怎么把它提取到更高的抽象能力和大局觀這塊，我覺得很多開發人員都比較欠 缺。
那您剛才也提到了對技術和業務對于架構師的影響，架構師需要成為技術專家嗎？或者是他也需要成為業務專家嗎？為什么？
首先從技術角度先說一下，對于架構師我的看法是首先要專，然后是博。就是第一個，必須得深入去了解你所擅長的某一個框架，某一個平臺，一定要專。我說所謂的 專，不是說把它每個細節都掌握得很清楚，而是要把它內在的原理搞得很清楚，這樣即使碰到一個新的問題，你也可以能夠很快的解決。因為架構師在基礎這塊，要 樹立起技術的權威，如果你設計出來的模型你自己都不清楚，我打個比方來說，你對通訊的協議都不清楚，你怎么去做架構設計，你怎么去把握它，所以必須得專。
但是，還有一個很重要的就是要博，因為我們做架構、做軟件，不一定是，一直做項目都會只用一個平臺，只用一門技術，而且現在的項目，其實有一個發展，是多語 言、多平臺共存的這樣一種發展，很多項目我們看到都有這種趨勢。那么如果說你只懂一門技術，只鉆一門框架，只鉆一門平臺，那么當需要你去集成多個系統的時 候，你可能就束手無策了，所以一定要博。那么博的意思是說，由于軟件，不管是什么平臺，不管是什么框架，不管是什么語言，其實它的原理是相通的。由于你專 了，所以你對它的語言、原理、平臺的機制都很清楚，你要再去快速的掌握其他的技術，是非常容易的。但是又有區別，你需要去把握它不同的地方，同時你還可以 取長補短，你可以用另外一個技術的優勢來彌足你現在所用的技術的缺陷，所以這是我對技術方面的認為。
而從業務來說，你要成為一位行業的專 家，當然是最好，但是人的精力是有限的。一般來說我們有兩種情況，一種情況就是如果這個架構師，他一直只做一個方向，就是他一直做汽車制造這塊，那他可能 隨著經驗的積累，慢慢慢慢的，他可能會成為一個汽車行業專家。但是事實上這種情況是很少的，很多架構師可能會面對另外一個新的項目，比如說你原來做汽車制 造，現在讓你做金融的，那你該怎么辦？所以我們一般的做法是，如果一個大的公司、大的團隊，我們會有專門的領域專家，由領域專家來負責業務這塊，或者由客 戶來負責業務這塊。但是我們的架構師也必須要對業務要有一定的了解，至少你要把一些行業的術語要搞清楚，這樣你才能夠和你的客戶和領域專家在溝通上沒有任 何的問題，所以我不認為說，每個架構師都必須得成為一個業務專家，但是至少你在做這個架構之前，你必須要了解這個業務，了解這個行業。
下面我們談一下如何來評價架構的優劣，有沒有什么切實可用的定量或者定性的指標？您在之前的項目中是如何來評價系統架構的好壞的？
這個問題我覺得，應該說也是一個難題。我們也看到有很多項目，包括有很多很牛的架構師，開發團隊也很好，公司也很好，但是失敗了，那原因有很多，架構這一塊其實是一個至關重要的。架構一般我認為從功能需求方面和非功能需求方面，可以分成這兩大方面。
從功能需求方面來說，如何去衡量架構師是成功的、是好的，其實很簡單，就是要滿足功能、滿足客戶需求。那我們可以利用一些方法，比如說需求矩陣、用需求跟蹤 這些方面，或者通過原形這些角度來和客戶進行溝通，通過客戶這邊來了解我們這個架構方案在功能需求方面是否滿足需求。然后我們可以利用一些方法，比如驅動 設計，或者通過用力這些方式去驅動，把領域模式，也就是所謂的業務模型，把它建好。
從非功能性需求來說，其實是架構的一個難題，提到有安 全方面、性能方面、可擴展性、可伸縮性，要求都很多。比如我們現在，都知道像Twitter、 FaceBook，他們的業務都很簡單，像Twitter就很簡單，我follow你，然后你去follow我，那業務很簡單。但是作為一個 Twitter的架構師要求很高，要求最高的可能在性能、安全穩定性這塊，因為訪問的人很多，所以性能這塊如何去衡量，就需要有一些衡量的指標，比如響應 時間之類的。在業界有很多解決這種非功能性需求方面的通用的一些方法，比如從性能角度來說，一般是利用緩存，在硬件方面不能再高的改善的情況之下，最重要 的可能就是利用緩存，不管是用普通的緩存，還是用分布式緩沖。另外就是考慮可伸縮性，通過集群的方式，增加服務器的方式來提高這種性能。這些東西呢，我們 就是在做架構的時候，我覺得在前期就要考慮好。
而且我覺得還有一個方法，就是把每一個功能、非功能性的因素，在權衡或者評價這個架構是否 合適的時候，可以把它的因素擴大化，比如原來客戶只要求能夠承擔十萬人同時上線，你可以把它放大，你放大到一百萬人，當同時上線的人數達到一百萬人的時 候，這個架構會不會出問題，通過這樣一種方式，就是把某一個因素擴大化，來衡量你的架構。另外一個預先做調研，預先做架構，架構這塊我可以先做，先做出一 個原形出來，架構的原形，我們通過一些測試手段，通過壓力測試，這方面的一些測試手段，來權衡這個架構是否有問題。
那就像你剛才說的，一個系統做到最后，往往會因為一些非功能性的因為成為它的一個瓶頸，像安全、可伸縮性，那架構師在這個階段會起到什么作用？
應該說這個時候架構師扮演的是救火人員、消防人員的這樣一個角色，其實做到后面出問題，本身從職責來看，本來就是架構師的問題，你之前沒考慮到，比如我們做 一個醫保項目，之前你不考慮，網絡斷開的情況之下，怎么來處理應對這種情況，比如說突然網絡斷了，難道就讓這個系統停掉嗎，讓它不能支撐這種斷線的、離線 的這種方式，如果沒考慮，肯定就有問題。所以首先第一點，其實也是剛才我說的，最開始就要考慮去這些問題，我們都說要考慮未來，在功能上來說，去考慮未來 很困難的，不可能今天去考慮到未來很多年后功能的變化，敏捷這個角度來說也是這樣去分析，我們只說今天要做的事情。但是從非功能性需求方面，你可以適當的 考慮一下未來，考慮一下未來在性能上、安全上、在可伸縮性方面、可擴展性方面，他的要求，所以你先要去考慮。
如果你預先去考慮到這些東 西，那么后來出現問題的可能性就會少很多，當然如果真是出現的話，怎么辦？這個時候其實沒有其他的辦法，只有是架構師的這種經驗。另外架構師不要搞的太固 步自封，或者過于的自信，覺得丟面子，去求助于別人，其實架構師不是所有都懂，比如在硬件、網絡、安全，會有專門的網絡專家、硬件專家和安全專家，我們稱 為叫基礎設施，基礎設施也有架構師，你作為這個項目的主要負責架構師，大項目有一個架構師團隊，小的項目你可以去尋求幫助，尋求其他的公司或者我們公司的 其他人，尋求幫助，盡快的解決這個問題。在出現這個問題的時候，首先要找到原因，找到它的癥結所在，然后解決方案的提出，你可以根據你的經驗，同時也要尋 求幫助，盡快的解決這個問題。我覺得很多架構師就是面子觀念，我都是很No.1的，我是Leader，怎么我還去尋求其他人的幫助？但事實上每個架構師都 有他的短板。
那架構師需要參與到日常的編碼工作嗎？
我到是覺得需要。
那架構師如何來保持技術的敏銳度？
這個我覺得就是剛才你提到一個問題，就是需不需要編碼，我覺得編碼也是能夠提高他的技術敏銳度。但是這個編碼，我的理解是這樣的，架構最好是寫一些編碼，第 一個最好是寫整個解決方案的大體上的一些編碼，而不是去摳這些具體的算法，一些細節的實現，比如說我甚至可以寫一個框架性的東西出來，然后具體的實現由開 發人員去填，另外比較困難的東西，可以由你來編碼去解決。還有從面向對象的角度來說，你可以寫一些基類或者抽象類，把一些共同的東西提取出來。如何保持敏 銳度呢，首先編碼這個角度來說，我們要隨時磨煉，我知道像我們很多世界一流的，象Kent Beck、Martin Fowler這些人，他們每天都還在寫代碼，就是要提高這方面能力，如果長期不寫，就有可能到真正去做項目的時候，碰到一個問題需要你來寫的時候，你寫不 出來。
最后對于有志于成長為架構師這些眾多的開發者來說，你有沒有什么比較好的指導建議能夠幫助大家能夠快速高效的成長，其中當然彎路是必不可少，如何來避免少走彎路呢？
第一個就是，要認清自己，就說你的特長是什么，你的性格，你自己要有充分的了解，如果你確實在協調能力方面、組織能力方面、口頭表達能力方面、交流能力方 面、抽象能力方面你達不到，你可以選擇另外路子。而不是覺得架構師好，你就一定要去做，其實在這個行業有很多角色都是非常好的，走到最后成為專家照樣是能 夠得到很好的事業，第一個要認清自己；第二個要認清目標，認清了自己之后，你還要認清目標，你的目標是什么。而且你這個目標有一個近期的短期和長期目標， 你在近一年要做什么事情，過三年、五年你要達到一個什么樣的高度，這是第二個。
第三，要找到適合自己的方法，因為每個人的能力不一樣，特 長不一樣，學習方法可能都不一樣，那么你的方法是什么，你要找到。比如說你可以通過多去閱讀源代碼，閱讀一些開源的項目，或者說你可以多看書，多做項目之 后，你可以在網上多找一些相關的文檔，這些都是一些好的學習方法，像我現在每天保持閱讀網絡上的一些文章，或者是閱讀書籍，特別有的書籍，是一些很一流 的，戰斗在一線的架構師，寫的一些心得體會的總結。有的東西，可能在我們做的項目根本就沒辦法碰得到，但是在將來的項目中有可能會碰到，如果你還寄希望于 在將來的時候碰到問題的時候你再去找，那就會出現很大的問題，所以這是我說的第三個要找到自己學習的方法。
第四，未雨綢繆，你要事先做好 準備，打下堅實的基礎；最后一個，我認為最重要的是，基礎很關鍵，不要好高騖遠，不要一下子我要成為架構師了，好，我現在就去面向對象思想我都不太了解， 設計模式我都不太了解，好，我現在就去搞架構模式，我去做架構的研究，我去分析這些架構的整個實現的原理，你根本就沒有辦法去掌握，所以你先要腳踏實地的 先把最關鍵、最基礎的東西先掌握好，就像我剛才說的要先專后博。先把這個東西研究的很透，而且不要抱著一個思想，就說我知道了就行了，要知其然，而不知其 所以然，這樣就會有很大的問題，我們要去把它研究透。包括像現在，就拿C#這種語言來說，你可能覺得這門語言你很清楚了，但事實上這個C#里面，涉及到框 架的，比如說PC垃圾回收怎么運行機制，內存的管理是怎么去管理的，多線程是怎么處理的，并發是怎么去解決的，有很多很多東西需要深入的去分析，而不是盲 目的知道C#的語法就夠了，這五點對于開發者來說是一個比較重要的，應該說是比較重要的一個能力。
好，非常感謝您接受我們的采訪。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
