很早就想寫一篇文章來談談架構師的職責了，因為自己做架構設計也有幾年了，有得有失，想以此文來談談自己對架構師職責的認識。架構師這個話題很大，在這裡不打算深入詳談，只是簡要的談談，想到**說到**。在談架構師之前我想談談什麼是架構，關於架構有很多種專業的定義，我這裡就用最好理解的一種定義來介紹架構是什麼，架構就是決策。從技術選型，到架構選型，從業務建模到系統建模，無一不是在做著決策。
要成為乙個好的架構師，首先要掌握一些基本理論和技能：
上面說到的這些基本理論和技能也不是一朝一夕就能掌握的，需要乙個不斷學習、實踐和思考的過程，當你某一天掌握了這些基本理論和技能之後，相信你做架構設計的時候自然也是成竹在胸。不過，即使你具備了上面提到的這些理論和技能、技術很不錯的情況下，依然不能保證能做出乙個成功的設計，因為還有一些要求你需要達到，否則，一樣做不出成功的架構，而這些要求並非都是技術上的要求。
架構師除了是乙個優秀的技術工程師之外還應該以下下角色：
如果以為自己掌握了上面提到那些基本技能，就一定能設計出牛x的架構，那是相當錯誤的想法，包括我曾經都這麼認為。這也是搞技術的人的通病，只對技術感興趣，認為做出一些牛x的技術就很牛了，就能搞定一切了。其實技術只是手段，關鍵是要能做出好的產品，而要做出好的產品就需要對產品、對業務很精通，如果對於產品和業務的理解不深入，做出的東西很可能就不是使用者想要的，甚至是失敗的產品，這種例子現實中太多了，不要認為技術是萬能的，要清楚的意識到，技術是服務於產品的。架構師應該是好的產品工程師的另外乙個理由是，不懂業務就不能做架構，如果不懂業務，那麼設計出來的東西一定是失敗的，因為業務流程、業務規則、業務細節等等都是變化點，如果設計之初都不管不顧，甚至不深入挖掘，那麼到最後，甚至在快完工之前，乙個細小的業務規就是壓死駱駝的最後一根稻草了。這個我是吃過虧的，以前做的乙個專案，最開始我只是粗略的了解了業務就開始做設計，等到設計開發快完了，發現有乙個業務規則沒有處理，而這個業務規則導致之前的抽象變得支離破碎，而接著是其它的業務規則又導致原來的設計被破壞，而且還難於修改，幾乎陷於泥潭，最終費很大力氣修改完成，卻發現和自己設計之初的理念相去甚遠，連我自己都驚訝我怎麼精心設計出這麼乙個醜陋的東西出來，最後不得不推倒重來。這些教訓讓我深刻的體會到好的架構師一定要先成為乙個優秀的產品工程師。
是的，你沒看錯，架構師就應該是一名出色的推銷員，當你開始設計的時候，首先你需要向你的領導推銷你的設計理念，要向領導描繪出設計藍圖，獲得領導的認同很重要，往往乙個專案的方向都是領導決定的，領導不認同，專案是沒法做下去的。但是這裡有乙個問題，往往領導都不懂技術，他們可能很精於產品，而對技術不感興趣，所以架構師要從產品的角度向領導來介紹架構設計，而不能從技術的角度去介紹，這才是你們溝通的基礎。
向領導推銷完設計之後還需要向產品人員推銷你的設計，為什麼要向產品人員推銷設計呢？這很重要，因為需求很大一部分來自於產品工程師，向產品工程師推銷你的設計，目的是讓產品工程師了解你的設計細節，及時發現設計的錯誤，甚至還會發現你沒有考慮的問題、細節和需求，越早發現這些問題越有助於後面的設計和開發，避免在後期大改或者推倒重來。向產品工程師推銷你的設計的時候同樣不要從技術的角度來推銷。更多的是從業務的角度來告訴他們，比如我這樣設計是為了處理某種複雜的業務，通過這種設計我們能很方便的處理這些複雜的邏輯，還容易擴充套件。業務才是你和產品工程師的共同語言。
向產品工程師推銷完你的設計之後，就應該向專案組的開發人員推銷的設計了，這同樣很重要，因為架構設計最終是需要他們完成的，架構的實現，最重要的是開發人員，如果開發人員不理解你的設計，甚至有牴觸情緒，那麼破壞架構的事情經常就會發生，士氣低落，不能團結一致，最終會導致專案的失敗，所以架構師一定要向開發人員推銷設計。開發人員理解並認同設計是專案成功的關鍵因素之一。如和向開發人員推銷設計呢？從純技術的角度來推銷。從物件導向的基本理論開始介紹你為什麼要這樣設計，這樣設計的好處在**，而開發人員是如何從中受益等等，我相信有理有據的技術交流是最容易博得開發人員的認同。而且乙個優秀的架構必定是乙個受開發人員歡迎與支援的架構，只要大家都認同的架構才是好的架構。
怎麼樣，現在知道架構師為什麼還必須是乙個好的推銷員了吧，只有大家認同了你的設計理念，你才可能設計乙個成功的架構。
開發人員不像產品工程師那樣不懂技術，開發人員是懂技術的，都會有自己的想法，如果遇到某個值得商榷的地方時，開發人員會提出自己的見解，這時就需要做折中了，從開發人員的角度去考慮，是否需要修改，如果要修改，則盡量在不改變大的設計原則基礎上做小幅改動，讓大家達成共識。最終的目標是讓開發人員認同設計，並樂於在這個架構上開發，這是非常重要的，也是保證乙個架構成功實現的重要因素。如果開發工程師受限自己知識水平，不理解架構設計的思想，這時，架構師就需要做些技術培訓了，通過這些技術培訓來讓開發工程師明白設計的理念，最終認同設計。我一直在強調溝通和認同，因為這真的很重要，kent beck曾提出，程式設計師的程式設計價值觀是：溝通、簡單和靈活。這是非常重要的概念，為什麼我們需要程式設計價值觀，因為價值觀決定了行為，有什麼樣的價值觀就有什麼樣的行為，如果程式設計師認為程式的可理解性、簡單性很重要，那麼他的**風格肯定是易讀易懂的，而這些恰恰是軟體的品質屬性，如果大家都認同這些理念，自覺按照這些思想去寫**，軟體的質量自然就提高了。相反，如果大家不認同這些理念，都按照自己的想法去做，那麼最終得到是乙個混亂的混合體，會導致軟體專案的失敗。只有大家都有乙個共同的程式設計價值觀，共同的理念，才可能高質量的完成乙個軟體專案，因此架構開發的第一步是要達成共識，讓大家認同設計。
專案開發過程中，應該經常審查**，架構師要確保大家是按照乙個方向前進，要確保沒有人在破壞架構，破壞架構是很危險的，不僅僅會導致**慢慢腐化，還會形成破窗效應，危害很大。當開發過程中發現設計考慮不周甚至有問題，要有勇氣去重構，而不是縫縫補補，要記住架構的乙個重要目的是讓開發人員的日子變得美好，如果開發人員用起來都覺得彆扭，那這個架構又怎麼能成為乙個成功的架構呢。開發過程中，如果遇到技術難題，架構師應該充當救火隊員的角色，身先士卒主動去解決，因為這是技術調研和技術選型時，考慮不周導致的，身先士卒的去解決技術難題問題還可以讓大家對架構更有信心。
未完待續...
後面還會繼續談到架構師分內的一些事情和架構設計的目標。
架構師的職責
架構師的職責 每個公司對於架構師的職責定位不同,一般來說架構師的職責主要體現在以下幾方面 1.負責公司系統的架構設計 研發工作 2.承擔從業務向技術轉換的橋梁作用 3.協助專案經理制定專案計畫和控制專案進度 4.負責輔助並指導 sa 系統分析師 開展設計工作 5.負責組織技術研究和攻關工作 6.負責...
架構師的職責範圍
架構師的職責範圍很難界定。我想成為一名優秀的架構師，寫這篇文章是為了明確方向。1 設計框架。例如開發乙個struts spring框架。這種類別是最高端別，開發乙個通用的框架給所有應用使用，要求在需求分析 系統設計 程式開發等各個方面都具備豐富經驗。2 企業整合。例如實行統一的技術標準，安全標準，使...
軟體架構師的「不歸之路「 架構師的職責
軟體架構師的 不歸之路 架構師的職責 架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個專案，使設計的專案盡量效率高，開發容易，維護方便，公升級簡單。架構師的主要責任是提供開發人員和專案經理之間的共用溝通 他們負責讓業務規則及需求與工程實踐及限制相適應，以確保成功。架構師的職責就...