很早就想寫一篇文章來談談架構師的職責了，因為自己做架構設計也有幾年了，有得有失，想以此文來談談自己對架構師職責的認識。架構師這個話題很大，在這里不打算深入詳談，只是簡要的談談，想到哪里說到哪里。在談架構師之前我想談談什么是架構，關於架構有很多種專業的定義，我這里就用最好理解的一種定義來介紹架構是什么，架構就是決策。從技術選型，到架構選型，從業務建模到系統建模，無一不是在做着決策。
要成為一個好的架構師，首先要掌握一些基本理論和技能：
- 面向對象設計的理論。如果連面向對象的基本理論都不知道就開始做設計，那是很糟糕的，為什么要這樣設計，這樣設計有什么好處，不是憑空瞎想的，都是有理論依據的，如果設計連一點依據都沒有，那肯定是拙劣的設計。
- 設計模式。設計模式是架構師的基本功，設計模式用來解耦組件內對象之間的關系，用好了，后期的開發階段將很順利，用不好則會導致過多的復雜性，降低架構質量，甚至導致開發計划延期。設計模式往往和業務聯系得很緊密，如果連設計模式都不懂就做設計，那遲早要栽跟頭。
- UML理論及其工具。這個是做設計最基本的要求了，如果UML理論都不懂，UML視圖都不會畫，又怎么完成得了設計？曾看到有人用excell畫的幾個框圖就說這是架構，然后吐沫橫飛的講解所謂的架構，其實這種所謂的設計連玩具都稱不上。一個完整的設計至少要包含五種UML圖，業務流程圖、用例圖、活動圖、組件圖、類圖。
- 架構模式。架構設計的時候常常需要參考借鑒一些經典的架構模式，因為這些架構模式就是前人總結的用來解決實際問題的，有非常重要的借鑒意義，可以避免少走很多彎路，尤其是在系統設計的時候，參考一些架構模式常常能事半功倍。
- 重構。架構也是需要不斷重構的，沒有完美的架構，只有不斷折中、不斷切合實際需求的架構，這是一個不斷完善的過程，完善的一個重要手段就是重構。
- 代碼質量理論。架構師不僅僅是畫幾個圖而已，架構師需要參與技術攻關和核心模塊的開發，並關注開發過程中的代碼質量，高質量的代碼會讓架構的實現錦上添花。
上面說到的這些基本理論和技能也不是一朝一夕就能掌握的，需要一個不斷學習、實踐和思考的過程，當你某一天掌握了這些基本理論和技能之后，相信你做架構設計的時候自然也是成竹在胸。不過，即使你具備了上面提到的這些理論和技能、技術很不錯的情況下，依然不能保證能做出一個成功的設計，因為還有一些要求你需要達到，否則，一樣做不出成功的架構，而這些要求並非都是技術上的要求。
架構師除了是一個優秀的技術工程師之外還應該以下下角色：
- 應該是好的產品工程師
如果以為自己掌握了上面提到那些基本技能，就一定能設計出牛X的架構，那是相當錯誤的想法，包括我曾經都這么認為。這也是搞技術的人的通病，只對技術感興趣，認為做出一些牛X的技術就很牛了，就能搞定一切了。其實技術只是手段，關鍵是要能做出好的產品，而要做出好的產品就需要對產品、對業務很精通，如果對於產品和業務的理解不深入，做出的東西很可能就不是用戶想要的，甚至是失敗的產品，這種例子現實中太多了，不要認為技術是萬能的，要清楚的意識到，技術是服務於產品的。架構師應該是好的產品工程師的另外一個理由是，不懂業務就不能做架構，如果不懂業務，那么設計出來的東西一定是失敗的，因為業務流程、業務規則、業務細節等等都是變化點，如果設計之初都不管不顧，甚至不深入挖掘，那么到最后，甚至在快完工之前，一個細小的業務規就是壓死駱駝的最后一根稻草了。這個我是吃過虧的，以前做的一個項目，最開始我只是粗略的了解了業務就開始做設計，等到設計開發快完了，發現有一個業務規則沒有處理，而這個業務規則導致之前的抽象變得支離破碎，而接着是其它的業務規則又導致原來的設計被破壞，而且還難於修改，幾乎陷於泥潭，最終費很大力氣修改完成，卻發現和自己設計之初的理念相去甚遠，連我自己都驚訝我怎么精心設計出這么一個丑陋的東西出來，最后不得不推倒重來。這些教訓讓我深刻的體會到好的架構師一定要先成為一個優秀的產品工程師。
- 架構師還應該是一名好的推銷員。
是的，你沒看錯，架構師就應該是一名出色的推銷員，當你開始設計的時候，首先你需要向你的領導推銷你的設計理念，要向領導描繪出設計藍圖，獲得領導的認同很重要，往往一個項目的方向都是領導決定的，領導不認同，項目是沒法做下去的。但是這里有一個問題，往往領導都不懂技術，他們可能很精於產品，而對技術不感興趣，所以架構師要從產品的角度向領導來介紹架構設計，而不能從技術的角度去介紹，這才是你們溝通的基礎。
向領導推銷完設計之后還需要向產品人員推銷你的設計，為什么要向產品人員推銷設計呢？這很重要，因為需求很大一部分來自於產品工程師，向產品工程師推銷你的設計，目的是讓產品工程師了解你的設計細節，及時發現設計的錯誤，甚至還會發現你沒有考慮的問題、細節和需求，越早發現這些問題越有助於后面的設計和開發，避免在后期大改或者推倒重來。向產品工程師推銷你的設計的時候同樣不要從技術的角度來推銷。更多的是從業務的角度來告訴他們，比如我這樣設計是為了處理某種復雜的業務，通過這種設計我們能很方便的處理這些復雜的邏輯，還容易擴展。業務才是你和產品工程師的共同語言。
向產品工程師推銷完你的設計之后，就應該向項目組的開發人員推銷的設計了，這同樣很重要，因為架構設計最終是需要他們完成的，架構的實現，最重要的是開發人員，如果開發人員不理解你的設計，甚至有抵觸情緒，那么破壞架構的事情經常就會發生，士氣低落，不能團結一致，最終會導致項目的失敗，所以架構師一定要向開發人員推銷設計。開發人員理解並認同設計是項目成功的關鍵因素之一。如和向開發人員推銷設計呢？從純技術的角度來推銷。從面向對象的基本理論開始介紹你為什么要這樣設計，這樣設計的好處在哪里，而開發人員是如何從中受益等等，我相信有理有據的技術交流是最容易博得開發人員的認同。而且一個優秀的架構必定是一個受開發人員歡迎與支持的架構，只要大家都認同的架構才是好的架構。
怎么樣，現在知道架構師為什么還必須是一個好的推銷員了吧，只有大家認同了你的設計理念，你才可能設計一個成功的架構。
- 架構師還應該是好的培訓師
開發人員不像產品工程師那樣不懂技術，開發人員是懂技術的，都會有自己的想法，如果遇到某個值得商榷的地方時，開發人員會提出自己的見解，這時就需要做折中了，從開發人員的角度去考慮，是否需要修改，如果要修改，則盡量在不改變大的設計原則基礎上做小幅改動，讓大家達成共識。最終的目標是讓開發人員認同設計，並樂於在這個架構上開發，這是非常重要的，也是保證一個架構成功實現的重要因素。如果開發工程師受限自己知識水平，不理解架構設計的思想，這時，架構師就需要做些技術培訓了，通過這些技術培訓來讓開發工程師明白設計的理念，最終認同設計。我一直在強調溝通和認同，因為這真的很重要，kent beck曾提出，程序員的編程價值觀是：溝通、簡單和靈活。這是非常重要的概念，為什么我們需要編程價值觀，因為價值觀決定了行為，有什么樣的價值觀就有什么樣的行為，如果程序員認為程序的可理解性、簡單性很重要，那么他的代碼風格肯定是易讀易懂的，而這些恰恰是軟件的品質屬性，如果大家都認同這些理念，自覺按照這些思想去寫代碼，軟件的質量自然就提高了。相反，如果大家不認同這些理念，都按照自己的想法去做，那么最終得到是一個混亂的混合體，會導致軟件項目的失敗。只有大家都有一個共同的編程價值觀，共同的理念，才可能高質量的完成一個軟件項目，因此架構開發的第一步是要達成共識，讓大家認同設計。
- 應該是好的QA和救火隊員
項目開發過程中，應該經常審查代碼，架構師要確保大家是按照一個方向前進，要確保沒有人在破壞架構，破壞架構是很危險的，不僅僅會導致代碼慢慢腐化，還會形成破窗效應，危害很大。當開發過程中發現設計考慮不周甚至有問題，要有勇氣去重構，而不是縫縫補補，要記住架構的一個重要目的是讓開發人員的日子變得美好，如果開發人員用起來都覺得別扭，那這個架構又怎么能成為一個成功的架構呢。開發過程中，如果遇到技術難題，架構師應該充當救火隊員的角色，身先士卒主動去解決，因為這是技術調研和技術選型時，考慮不周導致的，身先士卒的去解決技術難題問題還可以讓大家對架構更有信心。
未完待續...
后面還會繼續談到架構師分內的一些事情和架構設計的目標。