最近開始學(xué)習(xí)如何成為一名合格的架構(gòu)師。首先參照別人的觀點(diǎn)，在結(jié)合自己的實(shí)際經(jīng)驗(yàn)，寫出自己對(duì)如何成為一名架構(gòu)師的理解，希望大家熱心于與援手，能夠指點(diǎn)一二。

　　溝通能力和自我表達(dá)

　　我認(rèn)為溝通能力是基本中的基本，最為重要，最為普遍的素質(zhì)。技術(shù)人員好像容易忽略，想成為架構(gòu)師就不能忽略。因?yàn)榧軜?gòu)師要做的第一件事就是與團(tuán)隊(duì)成員、項(xiàng)目經(jīng)理、客戶認(rèn)同溝通，獲得認(rèn)同。我知道，這對(duì)于現(xiàn)在做技術(shù)，以后想轉(zhuǎn)做架構(gòu)的人也許很難。對(duì)本人也是如此。也許你會(huì)注意到雖然你兢兢業(yè)業(yè)，老黃牛的做了很多事，但每次升遷的總是那些平時(shí)最活躍的人。拋除其他方面的因素，領(lǐng)導(dǎo)之所以選這種人，是因?yàn)轭I(lǐng)導(dǎo)認(rèn)為他能與人打交道——也就是溝通，而我只能做事，只是個(gè)好員工。雖然我自認(rèn)為也擅長(zhǎng)溝通，但沒(méi)有表現(xiàn)出來(lái)，別人如何得知。溝通是雙向的，一方面要能夠理解對(duì)方的意思，另一方面也要讓對(duì)方理解你的意思。所以如果要成為架構(gòu)師，首先要勇于表達(dá)自我，然后仔細(xì)聆聽對(duì)方的話語(yǔ)。不可抱有"酒香不怕巷子深"的觀點(diǎn)，不然結(jié)果就是"懷才不遇，圖子傷悲"了。

　　有一定的魄力和感染力

　　架構(gòu)師要與很多人打交道，其中不乏領(lǐng)導(dǎo)，刁鉆的客戶，技術(shù)狂人。而架構(gòu)師是有職無(wú)官，但又要推動(dòng)整個(gè)團(tuán)隊(duì)的技術(shù)進(jìn)展，能在壓力下作出關(guān)鍵性的決策，并將其貫徹到底。這就需要架構(gòu)師具有一定的魄力和感染力，依此來(lái)排除工作過(guò)程中一些個(gè)人情緒帶來(lái)的影響，從而保證工作順利進(jìn)行。其實(shí)這點(diǎn)就算不做架構(gòu)師，在日常生活中，相信大家也有所體會(huì)。面對(duì)有感染力的人，他哭你悲，他傷你哀；面對(duì)有魄力的人的鏗鏘話語(yǔ)，相信他的話你不會(huì)不聽；反之，面對(duì)一個(gè)亦步亦趨，唯唯諾諾的人，你如何敢相信他的話，又如敢與他共事！

　　有廣闊的知識(shí)領(lǐng)域

　　架構(gòu)師的職責(zé)有些特殊，多少有點(diǎn)需要?jiǎng)?chuàng)新的要求。雖然有很多現(xiàn)成的架構(gòu)，但放到具體行業(yè)又有不同，不能生搬硬套。那么這時(shí)候你就需要專業(yè)的架構(gòu)知識(shí)，豐富的業(yè)務(wù)領(lǐng)域知識(shí)，開闊的眼界。依此才能跳出架構(gòu)和業(yè)務(wù)，從旁看清楚事實(shí)，從而將理論架構(gòu)與實(shí)際業(yè)務(wù)完美結(jié)合。我認(rèn)為，要做的這點(diǎn)，架構(gòu)師不僅要努力學(xué)習(xí)架構(gòu)和業(yè)務(wù)知識(shí)，也要把眼光放得更遠(yuǎn)。"世事洞明皆學(xué)問(wèn)"，也許靈感正來(lái)自與軟件毫不相干的東西。

　　有過(guò)硬的技術(shù)能力和豐富的編程經(jīng)驗(yàn)

　　廣闊的知識(shí)領(lǐng)域是廣度的要求，因?yàn)闆](méi)有廣度就成了井底之蛙。然而有了廣度還要有深度。人的精力有限，但至少要精通1~2門技術(shù)。有深度才能把握細(xì)節(jié)，才能保證自己的設(shè)計(jì)不是天馬行空，不切實(shí)際。有豐富的編程經(jīng)驗(yàn)，主要是希望保持一種代碼感覺(jué)，能夠和開發(fā)人員進(jìn)行有效的溝通，了解團(tuán)隊(duì)的情況。當(dāng)然這并不是要求自己成為一門技術(shù)專家，只要能夠保持對(duì)代碼的感覺(jué)就行。因?yàn)閮?yōu)秀的技術(shù)選型可能有很多，適應(yīng)于團(tuán)隊(duì)的缺未必。

　　多方位思考分析能力

　　收集到客戶需求和技術(shù)團(tuán)隊(duì)的反饋后，就要求架構(gòu)師能夠?qū)@些資料進(jìn)行系統(tǒng)分析，制訂可行的解決方法。制訂可行的架構(gòu)，不僅要求你要從客戶的角度考慮，也要從開發(fā)，機(jī)器等多方面考慮。這就要求你具備一定的抽象思維，多方位分析能力。只有具備這樣的能力，架構(gòu)師才能看清系統(tǒng)整體，掌控全局。如何具備這些能力？首要的是經(jīng)驗(yàn)，自己的，別人的均可，這點(diǎn)最重要。創(chuàng)新固然讓人興奮，然前人之鑒才更為穩(wěn)妥，另外，相信大家都聽過(guò)＂聽君一席話，勝讀十年書＂這句話，由此可知經(jīng)驗(yàn)有多么重要；其次要學(xué)習(xí)。

　　當(dāng)我們具備了這些條件的時(shí)候就可以選擇成為架構(gòu)師了。這時(shí)候我們就應(yīng)該知道軟件架構(gòu)師應(yīng)該做些什么，不應(yīng)該做些什么，也就是軟件架構(gòu)師的職責(zé)范圍。

　　由于國(guó)內(nèi)外軟件土壤差別巨大，適合國(guó)外的一些理論在國(guó)內(nèi)不一定行的通，而國(guó)內(nèi)的一些資料往往都是根據(jù)國(guó)外的資料直接搬過(guò)來(lái)用的，這也直接導(dǎo)致國(guó)外的軟件架構(gòu)師在國(guó)內(nèi)變得水土不服。今天本篇隨筆的內(nèi)容則是在一些培訓(xùn)資料的基礎(chǔ)上，加上自己的思考，總結(jié)出來(lái)的適合國(guó)情的軟件架構(gòu)師職責(zé)范圍。

　　需求整理分析

　　有人認(rèn)為架構(gòu)師是在需求規(guī)格說(shuō)明書完成后介入的，但我認(rèn)為架構(gòu)師要從項(xiàng)目最開始的階段就參與進(jìn)來(lái)。理由有很多：首先，第一手的信息損失最少，架構(gòu)師能夠更好的把握需求；其次，分析人員在與客戶交流時(shí)，往往不會(huì)深入挖掘需求，因?yàn)橛泻芏嚯[藏的需求客戶自己都不見得意識(shí)的到，而架構(gòu)師則可以依靠敏感的軟件嗅覺(jué)發(fā)現(xiàn)這些需求，減少以后的變數(shù)；第三，分析人員往往脫離開發(fā)團(tuán)隊(duì)，盲目接受客戶需求，而架構(gòu)師能夠清楚把握現(xiàn)有的研發(fā)團(tuán)隊(duì)能做什么，不能做什么，提前預(yù)知風(fēng)險(xiǎn)，降低項(xiàng)目失敗的機(jī)率。

　　系統(tǒng)分解

　　在收集完信息后，架構(gòu)師需要將用戶需求轉(zhuǎn)化為軟件需求，同時(shí)要補(bǔ)充非業(yè)務(wù)需求，如健壯性，擴(kuò)展性等等。如何區(qū)分和化解用戶需求與軟件需求，如何有效把握用戶需求與軟件需求的區(qū)別，是系統(tǒng)分解的核心。這是最考驗(yàn)架構(gòu)師的地方，也是只有架構(gòu)師參與的工作。

　　技術(shù)選型

　　這一步要根據(jù)對(duì)軟件需求決定項(xiàng)目該使用何種架構(gòu)，開發(fā)模型，及依賴選項(xiàng)。如使用多層架構(gòu)還是分布式架構(gòu)，是瀑布模型還是RUP，是使用MySQL還是SQLServer，是否需要使用企業(yè)庫(kù)，是否需要使用ORM。但是，架構(gòu)師對(duì)項(xiàng)目的技術(shù)選型要提供多種不同的方案，并為每種不同方案提供詳細(xì)說(shuō)明文檔，用來(lái)闡述每種方案的優(yōu)勢(shì)，劣勢(shì)，可行性等內(nèi)容。這些文檔供項(xiàng)目經(jīng)理或領(lǐng)導(dǎo)決策最終的技術(shù)選型。

　　系統(tǒng)設(shè)計(jì)

　　依據(jù)軟件需求和技術(shù)選型，架構(gòu)師需要和軟件工程師一起將軟件需求落實(shí)到軟件詳細(xì)設(shè)計(jì)說(shuō)明書中。架構(gòu)師負(fù)責(zé)將軟件需求分解，重組織為子項(xiàng)目，子系統(tǒng)，組件和模塊，以及它們之間的邏輯關(guān)系，從而形成不同的邏輯組成部分，最后還需要確定各個(gè)子系統(tǒng)及組件間的接口。這些都是作為進(jìn)一步的團(tuán)隊(duì)分工的依據(jù)。同系統(tǒng)分解一樣，系統(tǒng)設(shè)計(jì)是考驗(yàn)架構(gòu)師能力的重要職責(zé)。

　　培訓(xùn)與指導(dǎo)

　　在軟件詳細(xì)設(shè)計(jì)說(shuō)明書完成后，為保證項(xiàng)目的順利進(jìn)行，架構(gòu)師需要對(duì)整個(gè)團(tuán)隊(duì)進(jìn)行技術(shù)培訓(xùn)，讓團(tuán)隊(duì)中的每個(gè)人明白自己的職責(zé)范圍，該做什么，不該做什么。在項(xiàng)目實(shí)施過(guò)程中，架構(gòu)師需要參與到具體開發(fā)過(guò)程中，給與每個(gè)開發(fā)人員有效指導(dǎo)，以避免團(tuán)隊(duì)成員對(duì)系統(tǒng)設(shè)計(jì)的誤解而造成項(xiàng)目的延誤。在我看來(lái)，這點(diǎn)對(duì)于新手比較多的團(tuán)隊(duì)尤為重要。因?yàn)閲?guó)內(nèi)新手的一個(gè)通病是眼高手低，剛學(xué)會(huì)了一點(diǎn)點(diǎn)就認(rèn)為自己什么都會(huì)；當(dāng)他們拿到真正的設(shè)計(jì)時(shí)又往往不知所措，畏首畏尾。

　　保持溝通

　　溝通是保證項(xiàng)目順利開展的有效保障。架構(gòu)師要從多方面跟蹤項(xiàng)目進(jìn)度，及時(shí)與項(xiàng)目經(jīng)理或直屬領(lǐng)導(dǎo)匯報(bào)項(xiàng)目進(jìn)展，與技術(shù)開發(fā)人員溝通遇到的問(wèn)題，如果是迭代開發(fā)，還需要與用戶溝通需求變更。

　　以上是一個(gè)項(xiàng)目開發(fā)過(guò)程中架構(gòu)師需要承擔(dān)的主要職責(zé)，相比一些培訓(xùn)指導(dǎo)，我認(rèn)為，架構(gòu)師需要更深入地參與到項(xiàng)目中。

it知識(shí)庫(kù)：淺談軟件架構(gòu)師的素質(zhì)與職責(zé)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。