（原創）談談架構師的職責（一）

　　很早就想寫一篇文章來談談架構師的職責了，由於本身作架構設計也有幾年了，有得有失，想以此文來談談本身對架構師職責的認識。架構師這個話題很大，在這裏不打算深刻詳談，只是簡要的談談，想到哪裏說到哪裏。在談架構師以前我想談談什麼是架構，關於架構有不少種專業的定義，我這裏就用最好理解的一種定義來介紹架構是什麼，架構就是決策。從技術選型，到架構選型，從業務建模到系統建模，無一不是在作着決策。

要成爲一個好的架構師，首先要掌握一些基本理論和技能：

• 面向對象設計的理論。若是連面向對象的基本理論都不知道就開始作設計，那是很糟糕的，爲何要這樣設計，這樣設計有什麼好處，不是憑空瞎想的，都是有理論依據的，若是設計連一點依據都沒有，那確定是拙劣的設計。
• 設計模式。設計模式是架構師的基本功，設計模式用來解耦組件內對象之間的關係，用好了，後期的開發階段將很順利，用很差則會致使過多的複雜性，下降架構質量，甚至致使開發計劃延期。設計模式每每和業務聯繫得很緊密，若是連設計模式都不懂就作設計，那早晚要栽跟頭。
• UML理論及其工具。這個是作設計最基本的要求了，若是UML理論都不懂，UML視圖都不會畫，又怎麼完成得了設計？曾看到有人用excell畫的幾個框圖就說這是架構，而後吐沫橫飛的講解所謂的架構，其實這種所謂的設計連玩具都稱不上。一個完整的設計至少要包含五種UML圖，業務流程圖、用例圖、活動圖、組件圖、類圖。
• 架構模式。架構設計的時候經常須要參考借鑑一些經典的架構模式，由於這些架構模式就是前人總結的用來解決實際問題的，有很是重要的借鑑意義，能夠避免少走不少彎路，尤爲是在系統設計的時候，參考一些架構模式經常能事半功倍。
• 重構。架構也是須要不斷重構的，沒有完美的架構，只有不斷折中、不斷切合實際需求的架構，這是一個不斷完善的過程，完善的一個重要手段就是重構。
• 代碼質量理論。架構師不只僅是畫幾個圖而已，架構師須要參與技術攻關和核心模塊的開發，並關注開發過程當中的代碼質量，高質量的代碼會讓架構的實現錦上添花。

　　上面說到的這些基本理論和技能也不是一朝一夕就能掌握的，須要一個不斷學習、實踐和思考的過程，當你某一天掌握了這些基本理論和技能以後，相信你作架構設計的時候天然也是胸有成竹。不過，即便你具有了上面提到的這些理論和技能、技術很不錯的狀況下，依然不能保證能作出一個成功的設計，由於還有一些要求你須要達到，不然，同樣作不出成功的架構，而這些要求並不是都是技術上的要求。

　　架構師除了是一個優秀的技術工程師以外還應該如下下角色：

• 應該是好的產品工程師

　　若是覺得本身掌握了上面提到那些基本技能，就必定能設計出牛X的架構，那是至關錯誤的想法，包括我曾經都這麼認爲。這也是搞技術的人的通病，只對技術感興趣，認爲作出一些牛X的技術就很牛了，就能搞定一切了。其實技術只是手段，關鍵是要能作出好的產品，而要作出好的產品就須要對產品、對業務很精通，若是對於產品和業務的理解不深刻，作出的東西極可能就不是用戶想要的，甚至是失敗的產品，這種例子現實中太多了，不要認爲技術是萬能的，要清楚的意識到，技術是服務於產品的。架構師應該是好的產品工程師的另一個理由是，不懂業務就不能作架構，若是不懂業務，那麼設計出來的東西必定是失敗的，由於業務流程、業務規則、業務細節等等都是變化點，若是設計之初都無論不顧，甚至不深刻挖掘，那麼到最後，甚至在快完工以前，一個細小的業務規就是壓死駱駝的最後一根稻草了。這個我是吃過虧的，之前作的一個項目，最開始我只是粗略的瞭解了業務就開始作設計，等到設計開發快完了，發現有一個業務規則沒有處理，而這個業務規則致使以前的抽象變得支離破碎，而接着是其它的業務規則又致使原來的設計被破壞，並且還難於修改，幾乎陷於泥潭，最終費很大力氣修改完成，卻發現和本身設計之初的理念相去甚遠，連我本身都驚訝我怎麼精心設計出這麼一個醜陋的東西出來，最後不得不推倒重來。這些教訓讓我深入的體會到好的架構師必定要先成爲一個優秀的產品工程師。

• 架構師還應該是一名好的推銷員。

　　是的，你沒看錯，架構師就應該是一名出色的推銷員，當你開始設計的時候，首先你須要向你的領導推銷你的設計理念，要向領導描繪出設計藍圖，得到領導的認同很重要，每每一個項目的方向都是領導決定的，領導不認同，項目是無法作下去的。可是這裏有一個問題，每每領導都不懂技術，他們可能很精於產品，而對技術不感興趣，因此架構師要從產品的角度向領導來介紹架構設計，而不能從技術的角度去介紹，這纔是大家溝通的基礎。

　　向領導推銷完設計以後還須要向產品人員推銷你的設計，爲何要向產品人員推銷設計呢？這很重要，由於需求很大一部分來自於產品工程師，向產品工程師推銷你的設計，目的是讓產品工程師瞭解你的設計細節，及時發現設計的錯誤，甚至還會發現你沒有考慮的問題、細節和需求，越早發現這些問題越有助於後面的設計和開發，避免在後期大改或者推倒重來。向產品工程師推銷你的設計的時候一樣不要從技術的角度來推銷。更多的是從業務的角度來告訴他們，好比我這樣設計是爲了處理某種複雜的業務，經過這種設計咱們能很方便的處理這些複雜的邏輯，還容易擴展。業務纔是你和產品工程師的共同語言。

　　向產品工程師推銷完你的設計以後，就應該向項目組的開發人員推銷的設計了，這一樣很重要，由於架構設計最終是須要他們完成的，架構的實現，最重要的是開發人員，若是開發人員不理解你的設計，甚至有抵觸情緒，那麼破壞架構的事情常常就會發生，士氣低落，不能團結一致，最終會致使項目的失敗，因此架構師必定要向開發人員推銷設計。開發人員理解並認同設計是項目成功的關鍵因素之一。如和向開發人員推銷設計呢？從純技術的角度來推銷。從面向對象的基本理論開始介紹你爲何要這樣設計，這樣設計的好處在哪裏，而開發人員是如何從中受益等等，我相信有理有據的技術交流是最容易博得開發人員的認同。並且一個優秀的架構一定是一個受開發人員歡迎與支持的架構，只要你們都認同的架構纔是好的架構。

　　怎麼樣，如今知道架構師爲何還必須是一個好的推銷員了吧，只有你們認同了你的設計理念，你纔可能設計一個成功的架構。

• 架構師還應該是好的培訓師

　　開發人員不像產品工程師那樣不懂技術，開發人員是懂技術的，都會有本身的想法，若是遇到某個值得商榷的地方時，開發人員會提出本身的看法，這時就須要作折中了，從開發人員的角度去考慮，是否須要修改，若是要修改，則儘可能在不改變大的設計原則基礎上作小幅改動，讓你們達成共識。最終的目標是讓開發人員認同設計，並樂於在這個架構上開發，這是很是重要的，也是保證一個架構成功實現的重要因素。若是開發工程師受限本身知識水平，不理解架構設計的思想，這時，架構師就須要作些技術培訓了，經過這些技術培訓來讓開發工程師明白設計的理念，最終認同設計。我一直在強調溝通和認同，由於這真的很重要，kent beck曾提出，程序員的編程價值觀是：溝通、簡單和靈活。這是很是重要的概念，爲何咱們須要編程價值觀，由於價值觀決定了行爲，有什麼樣的價值觀就有什麼樣的行爲，若是程序員認爲程序的可理解性、簡單性很重要，那麼他的代碼風格確定是易讀易懂的，而這些偏偏是軟件的品質屬性，若是你們都認同這些理念，自覺按照這些思想去寫代碼，軟件的質量天然就提升了。相反，若是你們不認同這些理念，都按照本身的想法去作，那麼最終獲得是一個混亂的混合體，會致使軟件項目的失敗。只有你們都有一個共同的編程價值觀，共同的理念，纔可能高質量的完成一個軟件項目，所以架構開發的第一步是要達成共識，讓你們認同設計。

• 應該是好的QA和救火隊員

　　項目開發過程當中，應該常常審查代碼，架構師要確保你們是按照一個方向前進，要確保沒有人在破壞架構，破壞架構是很危險的，不只僅會致使代碼慢慢腐化，還會造成破窗效應，危害很大。當開發過程當中發現設計考慮不周甚至有問題，要有勇氣去重構，而不是縫縫補補，要記住架構的一個重要目的是讓開發人員的日子變得美好，若是開發人員用起來都以爲彆扭，那這個架構又怎麼能成爲一個成功的架構呢。開發過程當中，若是遇到技術難題，架構師應該充當救火隊員的角色，一馬當先主動去解決，由於這是技術調研和技術選型時，考慮不周致使的，一馬當先的去解決技術難題問題還可讓你們對架構更有信心。

 

未完待續...

後面還會繼續談到架構師份內的一些事情和架構設計的目標。