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

標籤：http   使用   ar   strong   問題   代碼   on   c   工作   

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

最近開始學習如何成為一名合格的架構師。首先參照別人的觀點，在結合自己的實際經驗，寫出自己對如何成為一名架構師的理解，希望大家熱心於與援手，能夠指點一二。

　　溝通能力和自我表達

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

　　有一定的魄力和感染力

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

　　有廣闊的知識領域

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

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

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

　　多方位思考分析能力

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

　　當我們具備了這些條件的時候就可以選擇成為架構師了。這時候我們就應該知道軟體架構師應該做些什麼，不應該做些什麼，也就是軟體架構師的職責範圍。

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

　　需求整理分析

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

　　系統分解

　　在收集完資訊後，架構師需要將使用者需求轉化為軟體需求，同時要補充非業務需求，如健壯性，擴充性等等。如何區分和化解使用者需求與軟體需求，如何有效把握使用者需求與軟體需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是只有架構師參與的工作。

　　技術選型

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

　　系統設計

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

　　培訓與指導

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

　　保持溝通

　　溝通是保證項目順利開展的有效保障。架構師要從多方面跟蹤項目進度，及時與專案經理或直屬領導彙報項目進展，與技術開發人員溝通遇到的問題，如果是反覆式開發法，還需要與使用者溝通需求變更。

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

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