要想從一名普通程序員發(fā)展成為優(yōu)秀的架構(gòu)師，“個(gè)人特性”與“技術(shù)技能”缺一不可；而“技術(shù)專業(yè)能力”、“人際關(guān)系能力”和“業(yè)務(wù)能力”更是優(yōu)秀架構(gòu)師重要的三種能力。

文 / 周愛(ài)民（《程序員》2008年4月刊）

引子

究竟是什么讓你在同一個(gè)位置上——例如程序員或技術(shù)負(fù)責(zé)人——工作了三年、五年或者更久，而 仍然得不到任何的發(fā)展空間？你覺(jué)得自己已成為技術(shù)圈中的大牛，并信心滿滿地去拿明天就要頒發(fā)的某某大獎(jiǎng)，然而卻仍然停留在同樣的技術(shù)職位上，去年到今年漲 的薪水甚至填不平物價(jià)升幅？于是，你開始對(duì)老板不滿，對(duì)員工不滿，對(duì)昨天升職的那個(gè)同事不滿……你開始計(jì)劃明天就要跑單，或者準(zhǔn)備考慮提出加薪卻又心懷忐 忑。

如果技術(shù)人員有發(fā)展的軌跡，那么他要么“看透工具的本質(zhì)，把關(guān)注點(diǎn)轉(zhuǎn)移到‘團(tuán)隊(duì)’的圈子里去 ”，要么“順著代碼鋪就的道路，亦步亦趨地成為良匠大師”。僅以技術(shù)方向而言，你大概可以做到架構(gòu)師、總架構(gòu)師甚至首席架構(gòu)師；但問(wèn)題是：你現(xiàn)在還只是一 個(gè)程序員。那要如何才能踏上通往架構(gòu)師之路呢？本文為你解析一個(gè)架構(gòu)師的能力模型。

你能不能做一個(gè)好的架構(gòu)師？

架構(gòu)師不是界定一個(gè)技術(shù)高下的職位名稱，而是一個(gè)職務(wù)。所謂職務(wù)，包括職——職位，務(wù)——工作。前者決定了你具備哪些資源，可以影響到怎樣的范圍，以及面向的機(jī)構(gòu)，后者則簡(jiǎn)單地是你需要完成的工作列表。

所以我說(shuō)“架構(gòu)師”不是指“一個(gè)能做架構(gòu)的人”。前者是把架構(gòu)師當(dāng)職能，后者是當(dāng)工人。能做 一份工作列表中的事，并不等于就成為相應(yīng)職位上的人。在管理體系里面，你的個(gè)人特性決定了你在哪個(gè)位置，而技術(shù)技能只是做事實(shí)施的必需。架構(gòu)師這個(gè)職務(wù)， 同時(shí)要求較高的個(gè)人素質(zhì)和技術(shù)能力，因此它的進(jìn)取之路總結(jié)起來(lái)就是：做人、做事，做架構(gòu)師。

因此“模型”由“個(gè)人特性”和“技術(shù)技能”兩個(gè)方面構(gòu)成，在第一張圖中，我特別說(shuō)明“個(gè)人特性”既包括人際關(guān)系的能力，也包括（具體）業(yè)務(wù)能力；“技術(shù)技能”也是如此。所以個(gè)人特性主要與“做人”有關(guān)，部分地也包含“做事”的要素。

                                            圖1 架構(gòu)師能力模型

“有效溝通”以及“學(xué)會(huì)談判”與做具體的事無(wú)關(guān)，是個(gè)人能力特性的公共方面。前者是過(guò)程，后 者是知道如何定目標(biāo)與求結(jié)果。而“風(fēng)險(xiǎn)與防備”是做事過(guò)程控制的關(guān)鍵，與前面兩項(xiàng)正好構(gòu)成了一個(gè)做事基本能力的完整體系?；旧?，這三項(xiàng)個(gè)人特性都是一個(gè) “普通程序員”所不具備的，甚至在大多數(shù)情況下，普通程序員并不愿意去具備這樣的個(gè)人特性，因?yàn)樵谠S多陷于技術(shù)泥淖的開發(fā)人員看來(lái)：溝通總是會(huì)使事情變得 更加麻煩，談判則徒耗時(shí)間而無(wú)濟(jì)于事。然而事實(shí)上，在整個(gè)的架構(gòu)決策過(guò)程中，架構(gòu)師需要不停地溝通與談判。將“架構(gòu)”變成“決策”的過(guò)程，其實(shí)就是對(duì)各個(gè) 技術(shù)角色（及其思想）兼容并包的過(guò)程，你需要不斷地協(xié)調(diào)需求、實(shí)現(xiàn)之間的各種問(wèn)題，也需要面對(duì)各種投資者（時(shí)間、資金、人才等方面的決策者）進(jìn)行談判，以 確定項(xiàng)目的規(guī)模——沒(méi)有規(guī)模也就沒(méi)有范圍，沒(méi)有范圍如何展開設(shè)計(jì)呢？

一部分開發(fā)人員會(huì)認(rèn)為上述過(guò)程是“項(xiàng)目經(jīng)理”的事情，但真的如此嗎？當(dāng)你作為一個(gè)更高級(jí)別的架構(gòu)師，以至于要影響到多個(gè)項(xiàng)目的決策時(shí)，你就全然不會(huì)有這種感受了。因?yàn)檫@種情況下，你的決策將先于項(xiàng)目的啟動(dòng)，或者說(shuō)你已經(jīng)不單單是一個(gè)技術(shù)角色了。

設(shè)計(jì)是架構(gòu)能力的一部分，但架構(gòu)師不是設(shè)計(jì)師——看清楚二者之間的不同，你才真正邁出了架構(gòu)師職業(yè)生涯的第一步。

抽象是思維能力、模型化是表達(dá)能力

個(gè)人特性中另一個(gè)非常重要的方面是“抽象思維”，而這是與架構(gòu)師角色直接相關(guān)的一種能力。這種能力既有職業(yè)技能特征，又是普遍性的能力。

所謂普遍性的能力，是指“抽象”在我們——作為人這種個(gè)體的——生活中無(wú)處不在。例如我們說(shuō) 花、草，說(shuō)桌、椅……我們用語(yǔ)言去指稱任何一個(gè)既已存在的（可以脫離我們的語(yǔ)言而自然存在的）事物時(shí)，就用到了抽象。說(shuō)“桌子”的時(shí)候，既沒(méi)有描述桌子的 具體形式，也沒(méi)有說(shuō)明它的規(guī)格，但我們用這個(gè)名詞時(shí)，所有人都知道“桌子是什么”。所以，名詞概念是整個(gè)抽象邏輯系統(tǒng)中的主體。如果失去了這些名詞定義， 我們基本上不能說(shuō)話，也不能描述任何東西——那便到了“只可意會(huì)不可言傳”的境地。

用現(xiàn)有的成熟語(yǔ)匯去描述你的系統(tǒng)時(shí)，大多數(shù)人會(huì)理解你所表達(dá)的含義，例如我們說(shuō)“這個(gè)系統(tǒng)設(shè) 計(jì)為一個(gè)三層結(jié)構(gòu)”。然而架構(gòu)師面臨的系統(tǒng)在許多細(xì)節(jié)上并不見(jiàn)得能夠用成熟的語(yǔ)匯去描述，因此必須自已構(gòu)建一個(gè)抽象系統(tǒng)，這就需要概念抽象能力、概念表達(dá) 能力和基于概念的邏輯表達(dá)能力。

概念抽象能力是一種思維能力。簡(jiǎn)單地說(shuō)，就是“把目標(biāo)分解或概括清楚”：你要么概而言之“它 是什么”，要么詳細(xì)地說(shuō)明“它包括什么”。必須使用大量的語(yǔ)匯來(lái)陳述這個(gè)“什么”，這不單單是表達(dá)為文字，也表達(dá)為你在思想過(guò)程中的一個(gè)完整系統(tǒng)。通常用 的方法是“映射系統(tǒng)”。例如你可以用數(shù)學(xué)中的“數(shù)軸”來(lái)映射“實(shí)數(shù)域”。將目標(biāo)系統(tǒng)形式化為一個(gè)概念化的、可討論的結(jié)構(gòu)系統(tǒng)后，你的抽象過(guò)程就基本結(jié)束 了。

                                            圖2 能力模型中的個(gè)人特性

然而這個(gè)“抽象系統(tǒng)”可能只構(gòu)建在你的思維意識(shí)里，還必須把它描繪出來(lái)。因?yàn)椴荒苤皇悄阕约核伎记宄?，系統(tǒng)就能設(shè)計(jì)完成。這個(gè)“描繪”就依賴于后面兩種表達(dá)能力，一種是描繪概念實(shí)體，一種是描繪實(shí)體上的邏輯——有趣的是，這似乎又回到了“程序＝結(jié)構(gòu)＋算法”。

現(xiàn)在大家回過(guò)頭來(lái)看看UML，或者更多種類的ML（建模語(yǔ)言），他們就用于表達(dá)這兩個(gè)方面的東西：要么是概念實(shí)體（例如用一個(gè)框表明系統(tǒng)邊界），要么是實(shí)體上的邏輯（例如用箭頭表明邏輯時(shí)序）。

所以大家應(yīng)該清楚，我們?cè)偃绾畏Q贊UML，它也只是一種對(duì)模型化系統(tǒng)的“表達(dá)能力”，你只能把它當(dāng)一種輔助表達(dá)的工具去使用，它本身既不能幫助思考，也不見(jiàn)得能作為抽象過(guò)程中的或抽象思維環(huán)境中的參考。

任何一個(gè)優(yōu)秀的架構(gòu)師都有自己獨(dú)特的思考方式，這決定了他如何抽象系統(tǒng)，以及如何“創(chuàng)造性地 ”設(shè)計(jì)與構(gòu)畫這個(gè)系統(tǒng)。這種“獨(dú)特的思考方式”貫徹他從孩童開始的整個(gè)成長(zhǎng)過(guò)程，直至他形成獨(dú)立的社會(huì)觀、人生觀與世界觀。他認(rèn)識(shí)世界的方式和接受世界的 能力決定于他如何思考，也反映了他這種思考方式的“獨(dú)特性”。但這并不表明他有特立獨(dú)行的行為特性（我們這里只說(shuō)他的思考方式），我們不應(yīng)介意他是否用某 種語(yǔ)言（例如UML或者形式化編程語(yǔ)言）來(lái)表達(dá)他的思考結(jié)果。

推動(dòng)：設(shè)計(jì)做大，實(shí)施做小

架構(gòu)師首先是把問(wèn)題的真正目標(biāo)確定下來(lái)，然后變成系統(tǒng)設(shè)計(jì)、平臺(tái)設(shè)計(jì)或架構(gòu)設(shè)計(jì)。而在此之后 設(shè)計(jì)輸出將會(huì)有兩個(gè)方向的發(fā)展，一是被忠實(shí)地貫徹下來(lái)，二是被變形地發(fā)展下去。兩個(gè)方向都存在致命的危險(xiǎn)：架構(gòu)最終能否被完整實(shí)現(xiàn)。對(duì)前者來(lái)說(shuō)，可能是架 構(gòu)設(shè)計(jì)過(guò)度，或設(shè)計(jì)本身出現(xiàn)了錯(cuò)誤；后者則是對(duì)架構(gòu)直接的傷害。

所以架構(gòu)師必須參與實(shí)施的全程——尤其是在架構(gòu)被映射為目標(biāo)系統(tǒng)的前期。在這個(gè)階段中，架構(gòu) 師的任務(wù)就是推動(dòng)架構(gòu)實(shí)施，以保證在項(xiàng)目全程的設(shè)計(jì)／架構(gòu)／體系的一致性。除了直接跟設(shè)計(jì)師或設(shè)計(jì)團(tuán)隊(duì)溝通，以保證他們的設(shè)計(jì)在你可以控制的范圍之內(nèi)以 外，架構(gòu)師還必須有階段化設(shè)計(jì)的能力。這種能力用于將一個(gè)原本規(guī)模宏大的架構(gòu)設(shè)計(jì)，變成較小的、易于實(shí)施的、對(duì)開發(fā)團(tuán)隊(duì)來(lái)說(shuō)可控的關(guān)鍵點(diǎn)。例如在體系層次 的規(guī)劃上，設(shè)計(jì)可能是獨(dú)立、異質(zhì)的、可遷移的存儲(chǔ)框架來(lái)實(shí)現(xiàn)數(shù)據(jù)層，但在（前期的）實(shí)施上，這里可能被表達(dá)為本地?cái)?shù)據(jù)庫(kù)，并要求前端開發(fā)人員必須通過(guò)一個(gè) 清晰的數(shù)據(jù)交互層來(lái)訪問(wèn)——例如一組數(shù)據(jù)存取接口，或一個(gè)獨(dú)立數(shù)據(jù)服務(wù)組件。開發(fā)人員可能在這里遇到障礙：因?yàn)橐ㄟ^(guò)這些中間層來(lái)訪問(wèn)本地?cái)?shù)據(jù)庫(kù)，純粹是 多余的。然而，正是這“多余的工作”提供了系統(tǒng)彈性，為并行團(tuán)隊(duì)開發(fā)公共存儲(chǔ)服務(wù)爭(zhēng)取了周期，也為將來(lái)的靈活部署與數(shù)據(jù)遷移提供了可能。

這里的關(guān)鍵就在于，無(wú)論原始系統(tǒng)設(shè)定有多大，實(shí)施時(shí)總是在“做小”。每一個(gè)局部的實(shí)施塊都是 可控的，并為它在整個(gè)體系空間中留下了位置和接口，這樣才可能由“小的部分”做大。一個(gè)大系統(tǒng)的架構(gòu)師可能同時(shí)在考慮許多個(gè)項(xiàng)目中的、不同位置的架構(gòu)，并 且清楚這些項(xiàng)目最終的總體規(guī)模。而這，就是平臺(tái)架構(gòu)師和體系架構(gòu)師所涉的領(lǐng)域。

                                            圖3 架構(gòu)師模型圖中的“實(shí)現(xiàn)能力”

架構(gòu)真的是“好不好”的問(wèn)題嗎？如同我對(duì)工程的理解一樣，架構(gòu)問(wèn)題的根本，也并不在于它是否 完美或漂亮，而是在于是否合用。因此架構(gòu)師必須對(duì)實(shí)施架構(gòu)的團(tuán)隊(duì)以及實(shí)施過(guò)程有充分了解，知道他們的能力缺陷，知道實(shí)現(xiàn)過(guò)程要消耗的資源，清楚每個(gè)環(huán)節(jié)可 能的故障以及先兆。只有這樣，架構(gòu)師才能設(shè)計(jì)一個(gè)讓這個(gè)團(tuán)隊(duì)能實(shí)現(xiàn)，而且在實(shí)現(xiàn)過(guò)程中能受控的架構(gòu)。

要知道，你作為架構(gòu)師被請(qǐng)來(lái)，不是畫幾張圖紙交給項(xiàng)目經(jīng)理，說(shuō)：你們?nèi)プ霭?，做不出?lái)是你們 不會(huì)做。即使你可以身體力行，在這個(gè)團(tuán)隊(duì)中教大家、培養(yǎng)大家，那么公司的開銷呢？風(fēng)險(xiǎn)呢？這些東西難道就不考慮了？項(xiàng)目的周期因?yàn)閷?shí)現(xiàn)的復(fù)雜程度而無(wú)法控 制時(shí)，項(xiàng)目就死掉了。那么，追根究底來(lái)說(shuō)，是不是架構(gòu)師的問(wèn)題？是啊，你為什么會(huì)做了一份“不合用”的架構(gòu)呢？——你都不知道項(xiàng)目如何開發(fā)、由誰(shuí)實(shí)施、如 何管理等等，又如何能面對(duì)這些實(shí)際環(huán)境去設(shè)計(jì)架構(gòu)呢？

所以這一部分能力，是要在你的開發(fā)經(jīng)驗(yàn)、團(tuán)隊(duì)經(jīng)驗(yàn)以及用人識(shí)人的經(jīng)驗(yàn)中去找的。參考模型圖的“實(shí)現(xiàn)能力”下的“設(shè)計(jì)能力→了解你的主要溝通對(duì)象”和“架構(gòu)推行”等分支，對(duì)你或有一些可用的提示。

局部與全局

架構(gòu)是一個(gè)從全局到局部的過(guò)程，而實(shí)施正好反過(guò)來(lái)，是從局部到全局。這也正是“設(shè)計(jì)做大，實(shí)施做小”的另一個(gè)層面的含義。設(shè)計(jì)大才可以見(jiàn)到全局，才知道此全局對(duì)彼全局的影響；實(shí)施小才可能關(guān)注細(xì)節(jié)，才談得上品質(zhì)與控制。

事實(shí)上，大多數(shù)情況下架構(gòu)是在為“當(dāng)前項(xiàng)目之外”去考慮，這可以看成全局關(guān)注的一個(gè)組成部分。因此我們需要界定所謂“全局”的范圍：超出公司或整個(gè)產(chǎn)品系列、產(chǎn)品線或規(guī)劃的范圍才是多余的。

所以當(dāng)架構(gòu)決策談及“全局”時(shí)，其目標(biāo)并不見(jiàn)得是“保障當(dāng)前項(xiàng)目”，而又必須由當(dāng)前項(xiàng)目去完成。

一個(gè)經(jīng)常被用到的例子是：如果僅為當(dāng)前項(xiàng)目考慮，那么只需要做成DLL模塊；如果為產(chǎn)品線考慮，可能會(huì)是“管道＋插件”的結(jié)構(gòu)形式。而“管道＋插件”的形式顯然比做成DLL模塊更費(fèi)時(shí)，這個(gè)時(shí)間成本（以及其它成本）就變成了當(dāng)前項(xiàng)目的無(wú)謂開銷。

這種全局策略對(duì)局部計(jì)劃的影響是大多數(shù)公司不能忍受的，也被很多團(tuán)隊(duì)所垢病。然而這卻是架構(gòu) 師角色對(duì)體系的“近乎必然”的影響——如果你試圖在體系中引用架構(gòu)師這個(gè)角色的話。一些情況下，體系能夠容納這種影響，例如“技術(shù)架構(gòu)師”試圖推動(dòng)某種插 件框架，而正好開發(fā)人員對(duì)這項(xiàng)技術(shù)感興趣，那就順其自然地花點(diǎn)工夫去實(shí)現(xiàn)了。但如果不是這樣，實(shí)施者或?qū)嵤﹫F(tuán)隊(duì)看不到“多余的部分”對(duì)他們的價(jià)值時(shí)，來(lái)自 局部的抵觸就產(chǎn)生了。

這種情況下，平衡這些抵觸就成了架構(gòu)推行的實(shí)務(wù)之一。在我看來(lái)，“平衡”是全局的藝術(shù)和局部 的技術(shù)。也就是說(shuō)，一方面架構(gòu)師要學(xué)會(huì)游說(shuō)，另一方面也要尋求更為簡(jiǎn)潔的、成本更小的實(shí)現(xiàn)技術(shù)。只有當(dāng)整個(gè)體系都意識(shí)到（你所推行的）架構(gòu)的重要性，而且 實(shí)施成本在他們可以接受的范圍之內(nèi)時(shí)，他們才會(huì)積極行動(dòng)起來(lái)。

所以所謂平衡，其實(shí)也是折衷的過(guò)程。構(gòu)架師只有眼中見(jiàn)大，才知道哪些折衷可以做，而哪些不 能。所謂設(shè)計(jì)評(píng)估（模型圖中的實(shí)現(xiàn)能力->設(shè)計(jì)能力->設(shè)計(jì)評(píng)估分支）并不是去分析一個(gè)設(shè)計(jì)結(jié)果好或不好，而是從中看到原始的需求，看到體系 全局的意圖，然后知道在將設(shè)計(jì)變得更為“適當(dāng)”時(shí)可以做哪些折衷。同樣的原因，架構(gòu)師也必須知道自己的決策會(huì)產(chǎn)生的影響，才能控制它們，以防它們變成團(tuán)隊(duì) 的災(zāi)難。有些時(shí)候，架構(gòu)師甚至需要拋棄一些特性，以使得項(xiàng)目能夠持續(xù)下去。因?yàn)楫a(chǎn)品的階段性產(chǎn)出只是整個(gè)戰(zhàn)略中的一個(gè)環(huán)節(jié)，而不是全部。

其它

“怎么做一個(gè)架構(gòu)師”這個(gè)問(wèn)題得分成兩個(gè)部分來(lái)看，一個(gè)是“做到”，一個(gè)是“做好”。由于架構(gòu)師本身不過(guò)是一個(gè)技術(shù)職位，所以時(shí)機(jī)成熟了自然會(huì)做得到。但問(wèn)題是，真有一天你被放在這個(gè)位置上了，你能做得好嗎？

我瀏覽過(guò)幾套所謂培訓(xùn)機(jī)構(gòu)的有關(guān)架構(gòu)師的教程，也翻閱過(guò)一些講架構(gòu)的書。我發(fā)現(xiàn)他們普遍地是 將架構(gòu)作為一種“職業(yè)技術(shù)”來(lái)講，就像培養(yǎng)程序員或者縫紉工一樣來(lái)教育。但就我的經(jīng)驗(yàn)來(lái)說(shuō)，架構(gòu)并不是一件純粹表現(xiàn)技術(shù)能力的工作，所以并不是翻幾本書學(xué) 幾種方法就可以投入“實(shí)戰(zhàn)”的。更深層的問(wèn)題是，架構(gòu)師其實(shí)不是“戰(zhàn)”出來(lái)的。昨天跟同事討論這個(gè)話題，他把我們這幾年來(lái)的一些思考用了三句話來(lái)概括，非 常精彩：從無(wú)到有的，是架構(gòu)；從表到里的，是抽象；從粗到細(xì)的，是設(shè)計(jì)。

那么到底什么是架構(gòu)呢？從上面的概括中你是看不到答案的。到底如何做架構(gòu)呢？從本文中你也是 看不到答案的。然而我說(shuō)，“你看不到答案”的根源其實(shí)是在于你的眼光與心性——后面這個(gè)詞換成現(xiàn)代白話，就是“思想”。真正阻礙了你成為優(yōu)秀架構(gòu)師的，也 許正是你既有的知識(shí)與思想方法，扔掉它們，接受一些全然有別的信息，也許正是良好的開端。

或許你現(xiàn)在正憤憤然：這篇文章怎么空洞無(wú)物？——我甚至能想象到一些讀者的表情。然而請(qǐng)?jiān)趩?wèn)題面前停下來(lái)，不要急于給出答案。正如你將“?”稍微變下形，它就成為了“!”一樣，問(wèn)題的本身，就是答案。

作者簡(jiǎn)介

周愛(ài)民（aimingoo），具有十余年的軟件開發(fā)、項(xiàng)目管理和團(tuán)隊(duì)建設(shè)的經(jīng)驗(yàn)，現(xiàn)擔(dān)任盛大網(wǎng)絡(luò)的平臺(tái)架構(gòu)師，著有《大道至簡(jiǎn)》、《Delphi源代碼分析》等。

原文地址： http://vipnews.csdn.net/newscontent.aspx?pointid=2008_05_30_150239242