最近開始學(xué)習(xí)如何成為一名合格的架構(gòu)師。首先參照別人的觀點，在結(jié)合自己的實際經(jīng)驗，寫出自己對如何成為一名架構(gòu)師的理解，希望大家熱心于與援手，能夠指點一二。
溝通能力和自我表達(dá)
我認(rèn)為溝通能力是基本中的基本，最為重要，最為普遍的素質(zhì)。技術(shù)人員好像容易忽略，想成為架構(gòu)師就不能忽略。因為架構(gòu)師要做的第一件事就是與團隊成員、項目經(jīng)理、客戶認(rèn)同溝通，獲得認(rèn)同。我知道，這對于現(xiàn)在做技術(shù)，以后想轉(zhuǎn)做架構(gòu)的人也許很難。對本人也是如此。也許你會注意到雖然你兢兢業(yè)業(yè)，老黃牛的做了很多事，但每次升遷的總是那些平時最活躍的人。拋除其他方面的因素，領(lǐng)導(dǎo)之所以選這種人，是因為領(lǐng)導(dǎo)認(rèn)為他能與人打交道——也就是溝通，而我只能做事，只是個好員工。雖然我自認(rèn)為也擅長溝通，但沒有表現(xiàn)出來，別人如何得知。溝通是雙向的，一方面要能夠理解對方的意思，另一方面也要讓對方理解你的意思。所以如果要成為架構(gòu)師，首先要勇于表達(dá)自我，然后仔細(xì)聆聽對方的話語。不可抱有"酒香不怕巷子深"的觀點，不然結(jié)果就是"懷才不遇，圖子傷悲"了。
有一定的魄力和感染力
架構(gòu)師要與很多人打交道，其中不乏領(lǐng)導(dǎo)，刁鉆的客戶，技術(shù)狂人。而架構(gòu)師是有職無官，但又要推動整個團隊的技術(shù)進(jìn)展，能在壓力下作出關(guān)鍵性的決策，并將其貫徹到底。這就需要架構(gòu)師具有一定的魄力和感染力，依此來排除工作過程中一些個人情緒帶來的影響，從而保證工作順利進(jìn)行。其實這點就算不做架構(gòu)師，在日常生活中，相信大家也有所體會。面對有感染力的人，他哭你悲，他傷你哀；面對有魄力的人的鏗鏘話語，相信他的話你不會不聽；反之，面對一個亦步亦趨，唯唯諾諾的人，你如何敢相信他的話，又如敢與他共事！
有廣闊的知識領(lǐng)域
架構(gòu)師的職責(zé)有些特殊，多少有點需要創(chuàng)新的要求。雖然有很多現(xiàn)成的架構(gòu)，但放到具體行業(yè)又有不同，不能生搬硬套。那么這時候你就需要專業(yè)的架構(gòu)知識，豐富的業(yè)務(wù)領(lǐng)域知識，開闊的眼界。依此才能跳出架構(gòu)和業(yè)務(wù)，從旁看清楚事實，從而將理論架構(gòu)與實際業(yè)務(wù)完美結(jié)合。我認(rèn)為，要做的這點，架構(gòu)師不僅要努力學(xué)習(xí)架構(gòu)和業(yè)務(wù)知識，也要把眼光放得更遠(yuǎn)。"世事洞明皆學(xué)問"，也許靈感正來自與軟件毫不相干的東西。
有過硬的技術(shù)能力和豐富的編程經(jīng)驗
廣闊的知識領(lǐng)域是廣度的要求，因為沒有廣度就成了井底之蛙。然而有了廣度還要有深度。人的精力有限，但至少要精通1~2門技術(shù)。有深度才能把握細(xì)節(jié)，才能保證自己的設(shè)計不是天馬行空，不切實際。有豐富的編程經(jīng)驗，主要是希望保持一種代碼感覺，能夠和開發(fā)人員進(jìn)行有效的溝通，了解團隊的情況。當(dāng)然這并不是要求自己成為一門技術(shù)專家，只要能夠保持對代碼的感覺就行。因為優(yōu)秀的技術(shù)選型可能有很多，適應(yīng)于團隊的缺未必。
多方位思考分析能力
收集到客戶需求和技術(shù)團隊的反饋后，就要求架構(gòu)師能夠?qū)@些資料進(jìn)行系統(tǒng)分析，制訂可行的解決方法。制訂可行的架構(gòu)，不僅要求你要從客戶的角度考慮，也要從開發(fā)，機器等多方面考慮。這就要求你具備一定的抽象思維，多方位分析能力。只有具備這樣的能力，架構(gòu)師才能看清系統(tǒng)整體，掌控全局。如何具備這些能力？首要的是經(jīng)驗，自己的，別人的均可，這點最重要。創(chuàng)新固然讓人興奮，然前人之鑒才更為穩(wěn)妥，另外，相信大家都聽過＂聽君一席話，勝讀十年書＂這句話，由此可知經(jīng)驗有多么重要；其次要學(xué)習(xí)。
當(dāng)我們具備了這些條件的時候就可以選擇成為架構(gòu)師了。這時候我們就應(yīng)該知道軟件架構(gòu)師應(yīng)該做些什么，不應(yīng)該做些什么，也就是軟件架構(gòu)師的職責(zé)范圍。
由于國內(nèi)外軟件土壤差別巨大，適合國外的一些理論在國內(nèi)不一定行的通，而國內(nèi)的一些資料往往都是根據(jù)國外的資料直接搬過來用的，這也直接導(dǎo)致國外的軟件架構(gòu)師在國內(nèi)變得水土不服。今天本篇隨筆的內(nèi)容則是在一些培訓(xùn)資料的基礎(chǔ)上，加上自己的思考，總結(jié)出來的適合國情的軟件架構(gòu)師職責(zé)范圍。
需求整理分析
有人認(rèn)為架構(gòu)師是在需求規(guī)格說明書完成后介入的，但我認(rèn)為架構(gòu)師要從項目最開始的階段就參與進(jìn)來。理由有很多：首先，第一手的信息損失最少，架構(gòu)師能夠更好的把握需求；其次，分析人員在與客戶交流時，往往不會深入挖掘需求，因為有很多隱藏的需求客戶自己都不見得意識的到，而架構(gòu)師則可以依靠敏感的軟件嗅覺發(fā)現(xiàn)這些需求，減少以后的變數(shù)；第三，分析人員往往脫離開發(fā)團隊，盲目接受客戶需求，而架構(gòu)師能夠清楚把握現(xiàn)有的研發(fā)團隊能做什么，不能做什么，提前預(yù)知風(fēng)險，降低項目失敗的機率。
系統(tǒng)分解
在收集完信息后，架構(gòu)師需要將用戶需求轉(zhuǎn)化為軟件需求，同時要補充非業(yè)務(wù)需求，如健壯性，擴展性等等。如何區(qū)分和化解用戶需求與軟件需求，如何有效把握用戶需求與軟件需求的區(qū)別，是系統(tǒng)分解的核心。這是最考驗架構(gòu)師的地方，也是只有架構(gòu)師參與的工作。
技術(shù)選型
這一步要根據(jù)對軟件需求決定項目該使用何種架構(gòu)，開發(fā)模型，及依賴選項。如使用多層架構(gòu)還是分布式架構(gòu)，是瀑布模型還是RUP，是使用 MySQL還是SQLServer，是否需要使用企業(yè)庫，是否需要使用ORM。但是，架構(gòu)師對項目的技術(shù)選型要提供多種不同的方案，并為每種不同方案提供詳細(xì)說明文檔，用來闡述每種方案的優(yōu)勢，劣勢，可行性等內(nèi)容。這些文檔供項目經(jīng)理或領(lǐng)導(dǎo)決策最終的技術(shù)選型。
系統(tǒng)設(shè)計
依據(jù)軟件需求和技術(shù)選型，架構(gòu)師需要和軟件工程師一起將軟件需求落實到軟件詳細(xì)設(shè)計說明書中。架構(gòu)師負(fù)責(zé)將軟件需求分解，重組織為子項目，子系統(tǒng)，組件和模塊，以及它們之間的邏輯關(guān)系，從而形成不同的邏輯組成部分，最后還需要確定各個子系統(tǒng)及組件間的接口。這些都是作為進(jìn)一步的團隊分工的依據(jù)。同系統(tǒng)分解一樣，系統(tǒng)設(shè)計是考驗架構(gòu)師能力的重要職責(zé)。
培訓(xùn)與指導(dǎo)
在軟件詳細(xì)設(shè)計說明書完成后，為保證項目的順利進(jìn)行，架構(gòu)師需要對整個團隊進(jìn)行技術(shù)培訓(xùn)，讓團隊中的每個人明白自己的職責(zé)范圍，該做什么，不該做什么。在項目實施過程中，架構(gòu)師需要參與到具體開發(fā)過程中，給與每個開發(fā)人員有效指導(dǎo)，以避免團隊成員對系統(tǒng)設(shè)計的誤解而造成項目的延誤。在我看來，這點對于新手比較多的團隊尤為重要。因為國內(nèi)新手的一個通病是眼高手低，剛學(xué)會了一點點就認(rèn)為自己什么都會；當(dāng)他們拿到真正的設(shè)計時又往往不知所措，畏首畏尾。
保持溝通
溝通是保證項目順利開展的有效保障。架構(gòu)師要從多方面跟蹤項目進(jìn)度，及時與項目經(jīng)理或直屬領(lǐng)導(dǎo)匯報項目進(jìn)展，與技術(shù)開發(fā)人員溝通遇到的問題，如果是迭代開發(fā)，還需要與用戶溝通需求變更。
以上是一個項目開發(fā)過程中架構(gòu)師需要承擔(dān)的主要職責(zé)，相比一些培訓(xùn)指導(dǎo)，我認(rèn)為，架構(gòu)師需要更深入地參與到項目中。 原文鏈接
聯(lián)系客服
