引言

計算機(jī)科學(xué)是一門應(yīng)用科學(xué)，它的知識體系是典型的倒三角結(jié)構(gòu)，所用的基礎(chǔ)知識并不多，只是隨著應(yīng)用領(lǐng)域和方向的不同，產(chǎn)生了很多的分支，所以說編程并不是一件很困難的事情，一個高中生經(jīng)過特定的訓(xùn)練就可以做得到。但是，會編程和編好程絕對是兩碼事，同樣的程序員，有的人幾年之后成為了架構(gòu)師，有的人卻還在不停地coding，只不過ctrl-c、ctrl-v用得更加純熟了。在中國，編程人員最終的歸途無外乎兩條：一是轉(zhuǎn)向技術(shù)管理，它的終點是CTO；二是繼續(xù)深入，它的終點是首席架構(gòu)師，成為CEO的人畢竟是少數(shù)。如果你現(xiàn)在還是個普通的程序員，希望繼續(xù)在技術(shù)這條路上前進(jìn)的話，我想你還是應(yīng)該先補(bǔ)充一點軟件工程的思想，學(xué)習(xí)一點有關(guān)設(shè)計模式的知識，只有具備這些能力，你才能從整體和宏觀層面來考慮問題、分析問題和解決問題。本人Coding了很多年，中間走了不少彎路，雖然最終沒什么大成就，但總算有一些心得，很愿意把自己的一些經(jīng)驗?zāi)贸鰜砀蠹曳窒?，這或許對你的發(fā)展有所幫助。

由程序員轉(zhuǎn)為架構(gòu)師，最繞不開的概念就算是面向?qū)ο?OO)了。記得在大學(xué)的時候，我們專業(yè)開了一門課叫《面向?qū)ο蟮木幊獭?。那個時候，我們剛剛學(xué)了一門C語言，開發(fā)環(huán)境用的還是DOS下的Turbo C，半點項目開發(fā)的經(jīng)驗都沒有，純粹的空對空。所以，一學(xué)期下來，我始終處于一種懵懂狀態(tài)，既沒領(lǐng)會面向過程和面向?qū)ο蟮降子惺裁磪^(qū)別，也沒搞懂面向?qū)ο竽軒硎裁春锰帯?/P>

面向過程(OP)和面向?qū)ο?OO)

1 蛋炒飯和蓋澆飯

有人這么形容OP和OO的不同：用面向過程的方法寫出來的程序是一份蛋炒飯，而用面向?qū)ο髮懗鰜淼某绦蚴且环萆w澆飯。所謂蓋澆飯，北京叫蓋飯，東北叫燴飯，廣東叫碟頭飯，就是在一碗白米飯上面澆上一份蓋菜，你喜歡什么菜，你就澆上什么菜。我覺得這個比喻還是比較貼切的。

蛋炒飯制作的細(xì)節(jié)，我不太清楚，因為我沒當(dāng)過廚師，也不會做飯，但最后的一道工序肯定是把米飯和雞蛋混在一起炒勻。蓋澆飯呢，則是把米飯和蓋菜分別做好，你如果要一份紅燒肉蓋飯呢，就給你澆一份紅燒肉；如果要一份青椒土豆蓋澆飯，就給澆一份青椒土豆絲。

蛋炒飯的好處就是入味均勻，吃起來香。如果恰巧你不愛吃雞蛋，只愛吃青菜的話，那么唯一的辦法就是全部倒掉，重新做一份青菜炒飯了。蓋澆飯就沒這么多麻煩，你只需要把上面的蓋菜撥掉，更換一份蓋菜就可以了。蓋澆飯的缺點是入味不均，可能沒有蛋炒飯那么香。

到底是蛋炒飯好還是蓋澆飯好呢？其實這類問題都很難回答，非要比個上下高低的話，就必須設(shè)定一個場景，否則只能說是各有所長。如果大家都不是美食家，沒那么多講究，那么從飯館角度來講的話，做蓋澆飯顯然比蛋炒飯更有優(yōu)勢，他可以組合出來任意多的組合，而且不會浪費。

軟件工程

蓋澆飯的好處就是“菜”“飯”分離，從而提高了制作蓋澆飯的靈活性。飯不滿意就換飯，菜不滿意換菜。用軟件工程的專業(yè)術(shù)語就是“可維護(hù)性”比較好，“飯”和“菜”的耦合度比較低。蛋炒飯將“蛋”“飯”攪和在一起，想換“蛋”“飯”中任何一種都很困難，耦合度很高，以至于“可維護(hù)性”比較差。軟件工程追求的目標(biāo)之一就是可維護(hù)性，可維護(hù)性主要表現(xiàn)在3個方面：可理解性、可測試性和可修改性。面向?qū)ο蟮闹饕锰幘褪秋@著的改善了軟件的可維護(hù)性。

面向過程(OP)和面向?qū)ο?OO)是不是就是指編碼的兩種方式呢？不是！你拿到了一個用戶需求，比如有人要找你編個軟件，你是不是需要經(jīng)過需求分析，然后進(jìn)行總體/詳細(xì)設(shè)計，最后編碼，才能最終寫出軟件，交付給用戶。這個過程是符合人類基本行為方式的：先想做什么，再想如何去做，最后才是做事情。有的同學(xué)說：“我沒按照你說的步驟做啊，我是直接編碼的”。其實，你一定會經(jīng)歷了這三個階段，只不過你潛意識里沒有分得那么清楚。對于拿到需求就編碼的人，可能編著編著，又得倒回去重新琢磨，還是免不了這些過程，

以O(shè)O為例，對應(yīng)于軟件開發(fā)的過程，OO衍生出3個概念：OOA、OOD和OOP。采用面向?qū)ο筮M(jìn)行分析的方式稱為OOA，采用面向?qū)ο筮M(jìn)行設(shè)計的方式稱為OOD，采用面向?qū)ο筮M(jìn)行編碼的方式稱為OOP。面向過程(OP)和面向?qū)ο?OO)本質(zhì)的區(qū)別在于分析方式的不同，最終導(dǎo)致了編碼方式的不同。

面向過程編程(OPP) 和面向?qū)ο缶幊?OOP)的關(guān)系

關(guān)于面向過程的編程(OPP)和面向?qū)ο蟮木幊?OOP),給出這它們的定義的人很多，您可以從任何資料中找到很專業(yè)的解釋，但以我的經(jīng)驗來看，講的相對枯燥一點，不是很直觀。除非您已經(jīng)有了相當(dāng)?shù)姆e累，否則說起來還是比較費勁。

我是個老程序員出身，雖然現(xiàn)在的日常工作更多傾向了管理，但至今依然保持編碼的習(xí)慣，這句話什么意思呢？我跟大家溝通應(yīng)該沒有問題。無論你是在重復(fù)我走過的路，或者已經(jīng)走在了我的前面，大家都會有那么一段相同的經(jīng)歷，都會在思想層面上有一種理解和默契，所以我還是會盡量按照大多數(shù)人的常規(guī)思維寫下去。

面向過程的編程(OPP)產(chǎn)生在前，面向?qū)ο蟮木幊?OOP)產(chǎn)生在后，所以面向?qū)ο蟮木幊?OOP)一定會繼承前者的一些優(yōu)點，并摒棄前者存在的一些缺點，這是符合人類進(jìn)步的自然規(guī)律。兩者在各自的發(fā)展和演變過程中，也一定會相互借鑒，互相融合，來吸收對方優(yōu)點，從而出現(xiàn)在某些方面的趨同性，這些是必然的結(jié)果。即使兩者有更多的相似點，也不會改變它們本質(zhì)上的不同，因為它們的出發(fā)點就完全是兩種截然不同的思維方式。關(guān)于兩者的關(guān)系，我的觀點是這樣的：面向?qū)ο缶幊?OOP)在局部上一定是面向過程(OP)的，面向過程的編程(OPP)在整體上應(yīng)該借鑒面向?qū)ο?OO)的思想。這一段說的的確很空洞，而且也一定會有引來爭議，不過，我勸您還是在閱讀了后面的內(nèi)容之后，再來評判我觀點的正確與否。

象C++、C#、Java等都是面向?qū)ο蟮恼Z言，c,php(暫且這么說，因為php4以后就支持OO)都是面向過程的語言，那么是不是我用C++寫的程序一定就是面向?qū)ο?，用c寫的程序一定就是面向過程呢？這種觀點顯然是沒有真正吃透兩者的區(qū)別。語言永遠(yuǎn)是一種工具，前輩們每創(chuàng)造出來的一種語言，都是你用來實現(xiàn)想法的利器。我覺得好多人用C#,Java寫出來的代碼，要是仔細(xì)看看，那實際就是用面向?qū)ο?OO)的語言寫的面向過程(OP)的程序。

所以，即使給關(guān)羽一根木棍，給你一桿青龍偃月刀，他照樣可以打得你滿頭是包。你就是扛著個偃月刀，也成不了關(guān)羽，因為你缺乏關(guān)羽最本質(zhì)的東西---絕世武功。同樣的道理，如果你沒有領(lǐng)會OO思想，怎么可能寫得出真正的OO程序呢？面向?qū)ο?OO)和面向過程(OP)絕對是兩種截然不同的思維方式。

那是不是面向過程就不好，也沒有存在的必要了？我從來沒有這樣說過。事實上，面向過程的編程(OPP)已經(jīng)存在了幾十年了，現(xiàn)在依然有很多人在使用。它的優(yōu)點就是邏輯不復(fù)雜的情況下很容易理解，而且運行效率遠(yuǎn)高于面向?qū)ο螅∣O）編寫的程序。所以，系統(tǒng)級的應(yīng)用或準(zhǔn)實時系統(tǒng)中，依然采用面向過程的編程(OPP)。當(dāng)然，很多編程高手以及大師級的人物，他們由于對于系統(tǒng)整體的掌控能力很強(qiáng)，也喜歡使用面向過程的編程(OPP)，比如像Apache,QMail,PostFix,ICE等等這些比較經(jīng)典的系統(tǒng)都是OPP的產(chǎn)物。

象php這些腳本語言，主要用于web開發(fā)，對于一些業(yè)務(wù)邏輯相對簡單的系統(tǒng)，也常使用面向過程的編程(OPP)，這也是php無法跨入到企業(yè)級應(yīng)用開發(fā)的原因之一，不過php5目前已經(jīng)能夠很好的支持OO了。

#p#

詳解面向過程的編程(OPP)

在面向?qū)ο蟪霈F(xiàn)之前，我們采用的開發(fā)方法都是面向過程的編程(OPP)。面向過程的編程中最常用的一個分析方法是“功能分解”。我們會把用戶需求先分解成模塊，然后把模塊分解成大的功能，再把大的功能分解成小的功能，整個需求就是按照這樣的方式，最終分解成一個一個的函數(shù)。這種解決問題的方式稱為“自頂向下”，原則是“先整體后局部”，“先大后小”，也有人喜歡使用“自下向上”的分析方式，先解決局部難點，逐步擴(kuò)大開來，最后組合出來整個程序。其實，這兩種方式殊路同歸，最終都能解決問題，但一般情況下采用“自頂向下”的方式還是較為常見，因為這種方式最容易看清問題的本質(zhì)。

我舉個例子來說明面向過程的編程方式:

用戶需求：老板讓我寫個通用計算器。

最終用戶就是老板，我作為程序員，任務(wù)就是寫一個計算器程序。OK，很簡單，以下就是用C語言完成的計算器：

假定程序的文件名為：main.c。

int main(int argc, char *argv[]){
//變量初始化
int nNum1,nNum2;
char cOpr;
int nResult;
nNum1 = nNum2 = 0;
cOpr = 0;
nResult = 0;
//輸入數(shù)據(jù)
printf("Please input the first number:\r\n");
scanf("%d",&nNum1);
printf("Please input the operator:\r\n");
scanf("%s",&cOpr);
printf("Please input the second number:\r\n");
scanf("%d",&nNum2);
//計算結(jié)果
if( cOpr == '+' ){
nResult = nNum1 + nNum2;
}else if( cOpr == '-' ){
nResult = nNum1 - nNum2;
}else{
printf("Unknown operator!");
return -1;
}
//輸出結(jié)果
printf("The result is %d!",nResult);
return 0;
}

拋開細(xì)節(jié)不講，我想大多數(shù)人差不多都會這么實現(xiàn)吧，很清晰，很簡單，充分體現(xiàn)了“簡單就是美”的原則，面向過程的編程就是這樣有條理的按照順序來逐步實現(xiàn)用戶需求。

凡是做過程序的人都知道，用戶需求從來都不會是穩(wěn)定的，最多只能夠做到“相對穩(wěn)定”。用戶可能會隨時提出加個功能，減個功能的要求，也可能會要求改動一下流程，程序員最煩的就是頻繁地變動需求，尤其是程序已經(jīng)寫了大半了，但這種情況是永遠(yuǎn)無法避免的，也不能完全歸罪到客戶或者需求分析師。

以我們上面的代碼為例，用戶可能會提出類似的要求：

首先，你程序中實現(xiàn)了“加法”和“減法”，我還想讓它也能計算“乘法”、“除法”。

其次，你現(xiàn)在的人機(jī)界面太簡單了，我還想要個Windows計算器的界面或者M(jìn)ac計算器的界面。

用戶需求開始多了，我得琢磨琢磨該如何去寫這段代碼了。我今天加了“乘”“除”的運算，明天保不齊又得讓我加個“平方”、“立方”的運算，這要是把所有的運算都窮盡了，怎么也得寫個千八百行代碼吧。還有，用戶要求界面能夠更換，還得寫一大堆界面生成的代碼，又得來個千八百行。以后，這么多代碼堆在一起，怎么去維護(hù)，找個變量得半天，看懂了代碼得半天，萬一不小心改錯了，還得調(diào)半天。另外，界面設(shè)計我也不擅長，得找個更專業(yè)的人來做，做完了之后再加進(jìn)來吧。這個過程也就是“軟件危機(jī)”產(chǎn)生的過程。伴隨著軟件廣泛地應(yīng)用于各個領(lǐng)域，軟件開發(fā)的規(guī)模變得越來越大，復(fù)雜度越來越高，而其用戶的需求越來越不穩(wěn)定。

根據(jù)用戶提出的兩個需求，面向過程的編程該如何去應(yīng)對呢？我想大家都很清楚怎么去改。Very easy，把“計算”和“界面”分開做成兩個獨立的函數(shù)，封裝到不同的文件中。

假定程序的文件名為：main.c。

#include "interface.h"
#include "calculate.h"
int main(int argc, char *argv[]){
//變量初始化
int nNum1,nNum2;
char cOpr;
int nResult;
nNum1 = nNum2 = 0;
cOpr = 0;
nResult = 0;
//輸入數(shù)據(jù)
if( getParameters(&nNum1,&nNum2,&cOpr) == -1 )
return -1;
//計算結(jié)果
if( calcMachine(nNum1,nNum2,cOpr,&nResult) == -1 )
return -1;
//輸出結(jié)果
printf("The result is %d!",nResult);
return 0;
}
interface.h:
int getParameters(int *nNum1,int * nNum2,char *cOpr);
interface.c:
int getParameters(int *nNum1,int * nNum2,char *cOpr){
printf("Please input the first number:\r\n");
scanf("%d",nNum1);
printf("Please input the operator:\r\n");
scanf("%s",cOpr);
printf("Please input the second number:\r\n");
scanf("%d",nNum2);
return 0;
}
calculate.h:
int calcMachine(int nNum1,int nNum2,char cOpr, int *nResult);
calculate.c:
int calcMachine(int nNum1,int nNum2,char cOpr,int *nResult){
if( cOpr == '+' ){
*nResult = nNum1 + nNum2;
}else if( cOpr == '-' ){
*nResult = nNum1 - nNum2;
}else{
printf("Unknown operator!");
return -1;
};
return 0;
}

面向過程的編程(OPP)就是將用戶需求進(jìn)行“功能分解”。把用戶需求先分解成模塊(.h,.c)，再把模塊(.h,.c)分解成大的功能(function)，然后把大的功能(function)分解成小的功能(function)，如此類推。

功能分解是一項很有技術(shù)含量的工作，它不僅需要分解者具有豐富的實戰(zhàn)經(jīng)驗，而且需要科學(xué)的理論作為指導(dǎo)。如何分解，分解原則是什么，模塊粒度多大合適？這些都是架構(gòu)師的要考慮的問題，也是我們后面要著重講的內(nèi)容。

面向過程的編程(OPP)優(yōu)點是程序順序執(zhí)行，流程清晰明了。它的缺點是主控程序承擔(dān)了太多的任務(wù)，各個模塊都需要主控程序進(jìn)行控制和調(diào)度，主控和模塊之間的承擔(dān)的任務(wù)不均衡。

有的人把面向過程定義為：算法 + 數(shù)據(jù)結(jié)構(gòu)，我覺得也很準(zhǔn)確。面向過程的編程中算法是核心，數(shù)據(jù)處于從屬地位，數(shù)據(jù)隨算法而流動。所以采用面向過程的方式進(jìn)行編程，一般在動手之前，都要編寫一份流程圖或是數(shù)據(jù)流圖。

#p#

3 架構(gòu)師的職責(zé)

近來看到CSDN上有個CTO俱樂部，里面聊得是不亦樂乎。我懷著無比崇敬的態(tài)度，拜讀了一下牛人們的發(fā)言。里面有個哥們發(fā)起一個話題：“CTO, 你多久沒有寫程序了？”。有人回答：“不寫代碼的CTO,屬于......這公司問題大了!”?？吹竭@里，我就趕緊撤了，怕忍不住反駁幾句，反而遭到牛人們的群毆。試想，一個上點規(guī)模的IT公司，還得靠CTO來寫程序的話，那是不是才叫問題大了呢。當(dāng)然，我沒有做過CTO，所以我有我的不同看法，而且還愿意表達(dá)出來，無知者無畏。我情愿相信：我所理解的CTO跟這位CTO所理解的是兩回事。所以我想，如果有人能把CTO的職責(zé)給標(biāo)準(zhǔn)化了，也許就不會有這么多的爭論了。

同樣的道理，關(guān)于架構(gòu)師的定義，大家也有著不同的理解。什么是架構(gòu)師？架構(gòu)師有哪些職責(zé)？我覺得有必要提前明確一下，要不然大家溝通起來也會產(chǎn)生類似問題，子說子理，卯說卯理，但是壓根說得不是一碼子事。

1 什么是架構(gòu)師

曾經(jīng)有這么個段子：

甲：我已經(jīng)應(yīng)聘到一家中型軟件公司了，今天上班的時候，全公司的人都來歡迎我。

乙：羨慕ing，都什么人來了？

甲：CEO、COO、CTO、All of 程序員，還有會計、司機(jī)都來了。

乙：哇，他們太重視你了，人才啊，這么多人迎接你！

甲：沒有啊，就一個人！

乙：靠，#%￥$%...

很多的創(chuàng)業(yè)公司，一人身兼數(shù)職的情形還是很常見的。至少，我是經(jīng)歷過的，一個人包辦了所有的開發(fā)過程，連測試我都做了，絕對的一條龍，但是經(jīng)常踩鋼絲、騎獨輪車總會有失足的時候，結(jié)果有一次，從我手里發(fā)出去的光盤母盤，含有病毒僵尸，以至于被迫收回已經(jīng)推上市場的2萬張光盤，從那之后，我的心臟就開始變得無比堅強(qiáng)，現(xiàn)在就是整個后臺服務(wù)都癱瘓了，我也只是微微一笑。其實，一個人身兼架構(gòu)師和程序員，甚至多種角色，沒什么不妥，后面還會講這個話題，這種現(xiàn)象不是中國特色，跟國外是完全接軌的。我曾經(jīng)跟米國的一個工程師在msn中聊過類似的話題，發(fā)現(xiàn)他們的路子跟咱們沒什么不同，在IT這個行業(yè)，我們跟世界的差距只有1天，他們剛弄出來的新東西，我們這里第2天保準(zhǔn)見得到。

架構(gòu)師這個稱呼不是拍腦袋想出來的，是有國際標(biāo)準(zhǔn)（ISO/IEC 42010）可查的。架構(gòu)師是軟件開發(fā)活動中的眾多角色之一，它可能是一個人、一個小組，也可能是一個團(tuán)隊。微軟對架構(gòu)師有一個分類參考，我們參考一下，他們把架構(gòu)師分為4種：企業(yè)架構(gòu)師EA(Enterprise Architect)、基礎(chǔ)結(jié)構(gòu)架構(gòu)師IA(Infrastructure Architect)、特定技術(shù)架構(gòu)TSA(Technology-Specific Architect)和解決方案架構(gòu)師SA (Solution Architect)。微軟的這個分類是按照架構(gòu)師專注的領(lǐng)域不同而劃分的。

EA的職責(zé)是決定整個公司的技術(shù)路線和技術(shù)發(fā)展方向。蓋茨給自己的Title就是首席軟件架構(gòu)師，網(wǎng)易丁磊也喜歡這么稱呼自己，實際上就是EA角色；IA的工作就是提煉和優(yōu)化技術(shù)方面積累和沉淀形成的基礎(chǔ)性的、公共的、可復(fù)用的框架和組件，這些都是一個技術(shù)型公司傳承下來的最寶貴的財富之一；特定技術(shù)架構(gòu)師TSA，他們主要從事類似安全架構(gòu)、存儲架構(gòu)等專項技術(shù)的規(guī)劃和設(shè)計工作；SA的工作則專于解決方案的規(guī)劃和設(shè)計，“解決方案”這個詞在中國已經(jīng)到了嚴(yán)重泛濫的程度，大忽悠們最喜歡把它掛在嘴邊。所謂解決方案，就是把產(chǎn)品、技術(shù)或理論，不斷地進(jìn)行組合，來創(chuàng)造出滿足用戶需求的選擇。售前工程師一般都是帶著它到客戶那里去發(fā)揮的。

大公司會把各種類型的架構(gòu)師分得很清楚，小公司一般就不那么講究了，架構(gòu)師多數(shù)是是IA+TSA+SA，一人包打天下，所以說大公司出專才，小公司出全才。

實際工作中，我們也經(jīng)常會見到另一種比較簡單的分類方式，把架構(gòu)師分為軟件架構(gòu)師和系統(tǒng)架構(gòu)師。軟件架構(gòu)師基本上是TSA+IA，這也是程序員最容易突破，最可能走上的一條道路，比如JAVA架構(gòu)師、DotNet架構(gòu)師、LAPM架構(gòu)師等等，我后面所講的內(nèi)容都是與軟件架構(gòu)師的相關(guān)的話題。系統(tǒng)架構(gòu)師實際上是SA+TSA，更著力于綜合運用已有的產(chǎn)品和技術(shù)，來實現(xiàn)客戶期望的需求。系統(tǒng)架構(gòu)師要求通曉軟、硬件兩方面的知識，所以它的知識體系相對龐雜。關(guān)于系統(tǒng)架構(gòu)師的話題，我們可以稍后再作討論。

2 架構(gòu)師的職責(zé)

架構(gòu)師需要參與項目開發(fā)的全部過程，包括需求分析、架構(gòu)設(shè)計、系統(tǒng)實現(xiàn)、集成、測試和部署各個階段，負(fù)責(zé)在整個項目中對技術(shù)活動和技術(shù)說明進(jìn)行指導(dǎo)和協(xié)調(diào)。

架構(gòu)師主要職責(zé)有4條：

1、確認(rèn)需求

在項目開發(fā)過程中，架構(gòu)師是在需求規(guī)格說明書完成后介入的，需求規(guī)格說明書必須得到架構(gòu)師的認(rèn)可。架構(gòu)師需要和分析人員反復(fù)交流，以保證自己完整并準(zhǔn)確地理解用戶需求。

2、系統(tǒng)分解

依據(jù)用戶需求，架構(gòu)師將系統(tǒng)整體分解為更小的子系統(tǒng)和組件，從而形成不同的邏輯層或服務(wù)。隨后，架構(gòu)師會確定各層的接口，層與層相互之間的關(guān)系。架構(gòu)師不僅要對整個系統(tǒng)分層，進(jìn)行“縱向”分解，還要對同一邏輯層分塊，進(jìn)行“橫向”分解。

軟件架構(gòu)師的功力基本體現(xiàn)于此，這是一項相對復(fù)雜的工作。

3、技術(shù)選型

架構(gòu)師通過對系統(tǒng)的一系列的分解，最終形成了軟件的整體架構(gòu)。技術(shù)選擇主要取決于軟件架構(gòu)。

Web Server運行在Windows上還是Linux上？數(shù)據(jù)庫采用MSSql、Oracle還是Mysql？需要不需要采用MVC或者Spring等輕量級的框架？前端采用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，并進(jìn)行評估。

架構(gòu)師對產(chǎn)品和技術(shù)的選型僅僅限于評估，沒有決定權(quán)，最終的決定權(quán)歸項目經(jīng)理。架構(gòu)師提出的技術(shù)方案為項目經(jīng)理提供了重要的參考信息，項目經(jīng)理會從項目預(yù)算、人力資源、時間進(jìn)度等實際情況進(jìn)行權(quán)衡，最終進(jìn)行確認(rèn)。

4、制定技術(shù)規(guī)格說明

架構(gòu)師在項目開發(fā)過程中，是技術(shù)權(quán)威。他需要協(xié)調(diào)所有的開發(fā)人員，與開發(fā)人員一直保持溝通，始終保證開發(fā)者依照它的架構(gòu)意圖去實現(xiàn)各項功能。

架構(gòu)師與開發(fā)者溝通的最重要的形式是技術(shù)規(guī)格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現(xiàn)形式。通過架構(gòu)師提供的技術(shù)規(guī)格說明書，保證開發(fā)者可以從不同角度去觀察、理解各自承擔(dān)的子系統(tǒng)或者模塊。

架構(gòu)師不僅要保持與開發(fā)者的溝通，也需要與項目經(jīng)理、需求分析員，甚至與最終用戶保持溝通。所以，對于架構(gòu)師來講，不僅有技術(shù)方面的要求，還有人際交流方面的要求。

3 架構(gòu)師的誤區(qū)

1、架構(gòu)師就是項目經(jīng)理

架構(gòu)師不是項目經(jīng)理。項目經(jīng)理側(cè)重于預(yù)算控制、時間進(jìn)度控制、人員管理、與外部聯(lián)系和協(xié)調(diào)等等工作，具備管理職能。一般小型項目中，常見項目經(jīng)理兼架構(gòu)師。

2、架構(gòu)師負(fù)責(zé)需求分析

架構(gòu)師不是需求分析員。需求分析人員的工作是收集需求和分析需求，并與最終用戶、產(chǎn)品經(jīng)理保持聯(lián)系。架構(gòu)師只對最終的需求審核和確認(rèn)，提出需求不清和不完整的部分，他會跟需求分析員時刻保持聯(lián)系。架構(gòu)師是技術(shù)專家，不是業(yè)務(wù)專家。

3、架構(gòu)師從來不寫代碼

這是一個尚存爭論的問題。目前有兩種觀點：

觀點1：架構(gòu)師不寫代碼，寫代碼純體力活，架構(gòu)師寫代碼大材小用。架構(gòu)師把UML的各種視圖交給開發(fā)人員，如果有不明確的地方，可以與架構(gòu)師隨時溝通。

觀點2：架構(gòu)師本來自于程序員，只是比程序員站的層面更高，比程序員唯一多的是經(jīng)驗和知識，所以架構(gòu)師也免不了寫代碼。

我個人覺得這兩種說法是與架構(gòu)師的出身和所處的環(huán)境有關(guān)。

架構(gòu)師首先是一個技術(shù)角色，所以一定是來自于技術(shù)人員這個群體，比如系統(tǒng)架構(gòu)師，多是來自于運維人員，可能本身代碼寫得并不多，或者說寫不出來很漂亮的代碼。軟件架構(gòu)師多是來自于程序員，有著程序員的血統(tǒng)和情懷，所以在項目開發(fā)過程中，可能會寫一些核心代碼。我們的理想是架構(gòu)師不用寫代碼，但事實上有時候過于理想。架構(gòu)師寫不寫代碼，可能取決于公司的規(guī)模、文化、開發(fā)人員的素質(zhì)等現(xiàn)實情況。另外，架構(gòu)師也不是跟程序員界限分得那么清楚，按照能力也有高中低之分，寫不寫代碼不是區(qū)分兩者的根本標(biāo)準(zhǔn)。

4 架構(gòu)師的基本素質(zhì)

周星馳有個片子《喜劇之王》，劇中的尹天仇整天揣著本《演員的自我修養(yǎng)》，一個好演員不僅需要天賦，也需要一定的理論指導(dǎo)，無師自通的人畢竟是少數(shù)。架構(gòu)師的成長過程也是這樣。從普通程序員到高級程序員，再到架構(gòu)師，是一個經(jīng)驗積累和思想升華的過程。經(jīng)驗積累是一個方面，素質(zhì)培養(yǎng)是另一個方面，兩者相輔相成，所以我覺得有必要把架構(gòu)師的所要具備的素質(zhì)羅列一下，作為程序員努力的方向。

溝通能力

為了提高效率，架構(gòu)師必須贏得團(tuán)隊成員、項目經(jīng)理、客戶或用戶認(rèn)同，這就需要架構(gòu)師具有較強(qiáng)的溝通能力。溝通能力是人類最普遍性的素質(zhì)要求，技術(shù)人員好像容易忽略，想成為架構(gòu)師就不能忽略。千萬不要抱著這樣的觀念：懷才跟懷孕似的，時間久了總會被人發(fā)現(xiàn)的。還是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式?？纯茨阒車念^頭腦腦們，哪一個不是此中高手，我們千萬不要鄙視，認(rèn)為這是阿諛奉承、投機(jī)鉆營，凡事都要看到積極的一面，“溝通”的確是一種能力。我認(rèn)為自己是一個略內(nèi)向的人，因為我是農(nóng)村出來的孩子，普通話都說不好，以前或多或少帶有點自卑感，幻想著是金子總會發(fā)光，所以在職業(yè)生涯中吃了不少虧?，F(xiàn)在，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感覺工作起來順暢多了。

這一條我認(rèn)為最為重要，所以排在首位。我甚至認(rèn)為下面幾條都可以忽略，唯一這一條得牢記，而且要常常提醒自己。

領(lǐng)導(dǎo)能力

架構(gòu)師能夠推動整個團(tuán)隊的技術(shù)進(jìn)展，能在壓力下作出關(guān)鍵性的決策，并將其貫徹到底。架構(gòu)師如何來保證這種執(zhí)行力？這就需要架構(gòu)師具有領(lǐng)導(dǎo)能力。

架構(gòu)師的領(lǐng)導(dǎo)能力的取得跟項目經(jīng)理不太一樣。項目經(jīng)理主要負(fù)責(zé)解決行政管理，這種能力與技術(shù)關(guān)系不大，他有人權(quán)和財權(quán)，再扯上一張“領(lǐng)導(dǎo)”的虎皮，采用“胡蘿卜加大棒”的方式，基本上可以保證執(zhí)行力。架構(gòu)師在項目里面可能更多地使用非正式的領(lǐng)導(dǎo)力，也就是我們常說的影響力，里面包括個人魅力、技術(shù)能力、知識傳遞等等。

抽象思維和分析能力

架構(gòu)師必須具備抽象思維和分析的能力，這是你進(jìn)行系統(tǒng)分析和系統(tǒng)分解的基本素質(zhì)。只有具備這樣的能力，架構(gòu)師才能看清系統(tǒng)的整體，掌控全局，這也是架構(gòu)師大局觀的形成基礎(chǔ)。你如何具備這種能力呢？一是來自于經(jīng)驗，二是來自于學(xué)習(xí)。架構(gòu)師不僅要具備在問題領(lǐng)域上的經(jīng)驗，也需要具備在軟件工程領(lǐng)域內(nèi)的經(jīng)驗。也就是說，架構(gòu)師必須能夠準(zhǔn)確得理解需求，然后用軟件工程的思想，把需求轉(zhuǎn)化和分解成可用計算機(jī)語言實現(xiàn)的程度。經(jīng)驗的積累是需要一個時間過程的，這個過程誰也幫不了你，是需要你去經(jīng)歷的。但是，如果你有意識地去培養(yǎng)，不斷吸取前人的經(jīng)驗的話，還是可以縮短這個周期的。這也是我寫作此系列的始動力之一。

技術(shù)深度和廣度

架構(gòu)師最好精通1-2個技術(shù)，具備這種技術(shù)能力可以更加深入的理解有關(guān)架構(gòu)的工作原理，也可以拉近和開發(fā)人員的距離，并形成團(tuán)隊中的影響力。

架構(gòu)師的技術(shù)知識廣度也很重要，需要了解盡可能多的技術(shù)，所謂見多識廣，只有這樣，才可能綜合各種技術(shù)，選擇更加適合項目的解決方案。有的人說，架構(gòu)師技術(shù)廣度的要求高于技術(shù)深度的要求，這是很有道理的。

總而言之，一句話：架構(gòu)師是項目團(tuán)隊中的技術(shù)權(quán)威。

面向過程和面向?qū)ο筮@兩個基本概念，不僅架構(gòu)師需要非常清楚，程序員、設(shè)計師也要非常清楚，這也是系統(tǒng)分析、設(shè)計和編碼最基本的常識。我接觸的程序員，很多人只停留在一種“似是而非”的程度，這是不行的，想要繼續(xù)前進(jìn)，就得把基礎(chǔ)夯實，所以我覺得很有必要先回回爐，補(bǔ)補(bǔ)課。

#p#

5 詳解面向?qū)ο蟮木幊?OOP)

1 什么是面向?qū)ο?/EM>