淺談軟件架構師的素質與職責

原文：http://www.nowamagic.net/internet/internet_DutyOfSoftwareArchitect.php

最近開始學習如何成爲一名合格的架構師。首先參照別人的觀點，在結合本身的實際經驗，寫出本身對如何成爲一名架構師的理解，但願你們熱心於與援手，可以指點一二。

　　溝通能力和自我表達

　　我認爲溝通能力是基本中的基本，最爲重要，最爲廣泛的素質。技術人員好像容易忽略，想成爲架構師就不能忽略。由於架構師要作的第一件事就是與團隊成員、項目經理、客戶認同溝通，得到認同。我知道，這對於如今作技術，之後想轉作架構的人也許很難。對本人也是如此。也許你會注意到雖然你兢兢業業，老黃牛的作了不少事，但每次升遷的老是那些平時最活躍的人。拋除其餘方面的因素，領導之因此選這種人，是由於領導認爲他能與人打交道——也就是溝通，而我只能作事，只是個好員工。雖然我自認爲也擅長溝通，但沒有表現出來，別人如何得知。溝通是雙向的，一方面要可以理解對方的意思，另外一方面也要讓對方理解你的意思。因此若是要成爲架構師，首先要敢於表達自我，而後仔細聆聽對方的話語。不可抱有"酒香不怕巷子深"的觀點，否則結果就是"懷才不遇，圖子傷悲"了。

　　有必定的魄力和感染力

　　架構師要與不少人打交道，其中不乏領導，刁鑽的客戶，技術狂人。而架構師是有職無官，但又要推進整個團隊的技術進展，能在壓力下做出關鍵性的決策，並將其貫徹到底。這就須要架構師具備必定的魄力和感染力，依此來排除工做過程當中一些我的情緒帶來的影響，從而保證工做順利進行。其實這點就算不作架構師，在平常生活中，相信你們也有所體會。面對有感染力的人，他哭你悲，他傷你哀；面對有魄力的人的鏗鏘話語，相信他的話你不會不聽；反之，面對一個亦步亦趨，惟惟諾諾的人，你如何敢相信他的話，又如敢與他共事！

　　有廣闊的知識領域

　　架構師的職責有些特殊，多少有點須要創新的要求。雖然有不少現成的架構，但放到具體行業又有不一樣，不能生搬硬套。那麼這時候你就須要專業的架構知識，豐富的業務領域知識，開闊的眼界。依此才能跳出架構和業務，從旁看清楚事實，從而將理論架構與實際業務完美結合。我認爲，要作的這點，架構師不只要努力學習架構和業務知識，也要把眼光放得更遠。"世事洞明皆學問"，也許靈感正來自與軟件絕不相干的東西。

　　有過硬的技術能力和豐富的編程經驗

　　廣闊的知識領域是廣度的要求，由於沒有廣度就成了井底之蛙。然而有了廣度還要有深度。人的精力有限，但至少要精通1~2門技術。有深度才能把握細節，才能保證本身的設計不是天馬行空，不切實際。有豐富的編程經驗，主要是但願保持一種代碼感受，可以和開發人員進行有效的溝通，瞭解團隊的狀況。固然這並非要求本身成爲一門技術專家，只要可以保持對代碼的感受就行。由於優秀的技術選型可能有不少，適應於團隊的缺未必。

　　多方位思考分析能力

　　收集到客戶需求和技術團隊的反饋後，就要求架構師可以對這些資料進行系統分析，制訂可行的解決方法。制訂可行的架構，不只要求你要從客戶的角度考慮，也要從開發，機器等多方面考慮。這就要求你具有必定的抽象思惟，多方位分析能力。只有具有這樣的能力，架構師才能看清系統總體，掌控全局。如何具有這些能力？首要的是經驗，本身的，別人的都可，這點最重要。創新當然讓人興奮，然前人之鑑才更爲穩妥，另外，相信你們都聽過＂聽君一席話，勝讀十年書＂這句話，由此可知經驗有多麼重要；其次要學習。

　　當咱們具有了這些條件的時候就能夠選擇成爲架構師了。這時候咱們就應該知道軟件架構師應該作些什麼，不該該作些什麼，也就是軟件架構師的職責範圍。

　　因爲國內外軟件土壤差異巨大，適合國外的一些理論在國內不必定行的通，而國內的一些資料每每都是根據國外的資料直接搬過來用的，這也直接致使國外的軟件架構師在國內變得水土不服。今天本篇隨筆的內容則是在一些培訓資料的基礎上，加上本身的思考，總結出來的適合國情的軟件架構師職責範圍。

　　需求整理分析

　　有人認爲架構師是在需求規格說明書完成後介入的，但我認爲架構師要從項目最開始的階段就參與進來。理由有不少：首先，第一手的信息損失最少，架構師可以更好的把握需求；其次，分析人員在與客戶交流時，每每不會深刻挖掘需求，由於有不少隱藏的需求客戶本身都不見得意識的到，而架構師則能夠依靠敏感的軟件嗅覺發現這些需求，減小之後的變數；第三，分析人員每每脫離開發團隊，盲目接受客戶需求，而架構師可以清楚把握現有的研發團隊能作什麼，不能作什麼，提早預知風險，下降項目失敗的機率。

　　系統分解

　　在收集完信息後，架構師須要將用戶需求轉化爲軟件需求，同時要補充非業務需求，如健壯性，擴展性等等。如何區分和化解用戶需求與軟件需求，如何有效把握用戶需求與軟件需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是隻有架構師參與的工做。

　　技術選型

　　這一步要根據對軟件需求決定項目該使用何種架構，開發模型，及依賴選項。如使用多層架構仍是分佈式架構，是瀑布模型仍是RUP，是使用MySQL仍是SQLServer，是否須要使用企業庫，是否須要使用ORM。可是，架構師對項目的技術選型要提供多種不一樣的方案，併爲每種不一樣方案提供詳細說明文檔，用來闡述每種方案的優點，劣勢，可行性等內容。這些文檔供項目經理或領導決策最終的技術選型。

　　系統設計

　　依據軟件需求和技術選型，架構師須要和軟件工程師一塊兒將軟件需求落實到軟件詳細設計說明書中。架構師負責將軟件需求分解，重組織爲子項目，子系統，組件和模塊，以及它們之間的邏輯關係，從而造成不一樣的邏輯組成部分，最後還須要肯定各個子系統及組件間的接口。這些都是做爲進一步的團隊分工的依據。同系統分解同樣，系統設計是考驗架構師能力的重要職責。

　　培訓與指導

　　在軟件詳細設計說明書完成後，爲保證項目的順利進行，架構師須要對整個團隊進行技術培訓，讓團隊中的每一個人明白本身的職責範圍，該作什麼，不應作什麼。在項目實施過程當中，架構師須要參與到具體開發過程當中，給與每一個開發人員有效指導，以免團隊成員對系統設計的誤解而形成項目的延誤。在我看來，這點對於新手比較多的團隊尤其重要。由於國內新手的一個通病是眼高手低，剛學會了一點點就認爲本身什麼都會；當他們拿到真正的設計時又每每不知所措，畏首畏尾。

　　保持溝通

　　溝通是保證項目順利開展的有效保障。架構師要從多方面跟蹤項目進度，及時與項目經理或直屬領導彙報項目進展，與技術開發人員溝通遇到的問題，若是是迭代開發，還須要與用戶溝通需求變動。

　　以上是一個項目開發過程當中架構師須要承擔的主要職責，相比一些培訓指導，我認爲，架構師須要更深刻地參與到項目中。