1、引言 　　機算機科學是一門應用科學，它的知識體系是典型的倒三角結(jié)構(gòu)苹威，所用的基礎(chǔ)知識并不多调违，只是隨著應用領(lǐng)域和方向的不同，產(chǎn)生了很多的分支，所以說編程并不是一件很困難的事情玷过，一個高中生經(jīng)過特定的訓練就可以做得到。但是，會編程和編好程絕對是兩碼事祸挪，同樣的程序員，有的人幾年之后成為了架構(gòu)師票顾，有的人卻還在不停地coding含鳞，只不過ctrl-c鸭廷、ctrl-v用得更加純熟了。在中國熔吗，編程人員最終的歸途無外乎兩條：一是轉(zhuǎn)向技術(shù)管理辆床，它的終點是CTO；二是繼續(xù)深入桅狠，它的終點是首席架構(gòu)師讼载，成為CEO的人畢竟是少數(shù)。如果你現(xiàn)在還是個普通的程序員中跌，希望繼續(xù)在技術(shù)這條路上前進的話咨堤，我想你還是應該先補充一點軟件工程的思想漩符，學習一點有關(guān)設(shè)計模式的知識陨仅，只有具備這些能力览祖，你才能從整體和宏觀層面來考慮問題耐薯、分析問題和解決問題痢虹。本人Coding了很多年畔勤，中間走了不少彎路仔掸，雖然最終沒什么大成就，但總算有一些心得起暮，很愿意把自己的一些經(jīng)驗拿出來跟大家分享卖氨，這或許對你的發(fā)展有所幫助。

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

2氓仲、面向過程(OP)和面向?qū)ο?OO) 2.1 蛋炒飯和蓋澆飯 　　有人這么形容OP和OO的不同：用面向過程的方法寫出來的程序是一份蛋炒飯，而用面向?qū)ο髮懗鰜淼某绦蚴且环萆w澆飯得糜。所謂蓋澆飯敬扛，北京叫蓋飯，東北叫燴飯朝抖，廣東叫碟頭飯啥箭，就是在一碗白米飯上面澆上一份蓋菜，你喜歡什么菜槽棍，你就澆上什么菜捉蚤。我覺得這個比喻還是比較貼切的抬驴。 　　蛋炒飯制作的細節(jié)炼七，我不太清楚，因為我沒當過廚師布持，也不會做飯豌拙，但最后的一道工序肯定是把米飯和雞蛋混在一起炒勻。蓋澆飯呢题暖，則是把米飯和蓋菜分別做好按傅，你如果要一份紅燒肉蓋飯呢捉超，就給你澆一份紅燒肉；如果要一份青椒土豆蓋澆飯唯绍，就給澆一份青椒土豆絲拼岳。 　　蛋炒飯的好處就是入味均勻，吃起來香况芒。如果恰巧你不愛吃雞蛋惜纸，只愛吃青菜的話，那么唯一的辦法就是全部倒掉绝骚，重新做一份青菜炒飯了耐版。蓋澆飯就沒這么多麻煩，你只需要把上面的蓋菜撥掉压汪，更換一份蓋菜就可以了粪牲。蓋澆飯的缺點是入味不均，可能沒有蛋炒飯那么香止剖。 　　到底是蛋炒飯好還是蓋澆飯好呢腺阳？其實這類問題都很難回答，非要比個上下高低的話穿香，就必須設(shè)定一個場景舌狗，否則只能說是各有所長。如果大家都不是美食家扔水，沒那么多講究痛侍，那么從飯館角度來講的話，做蓋澆飯顯然比蛋炒飯更有優(yōu)勢魔市，他可以組合出來任意多的組合主届，而且不會浪費。

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

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

以O(shè)O為例阔涉，對應于軟件開發(fā)的過程，OO衍生出3個概念：OOA捷绒、OOD和OOP瑰排。采用面向?qū)ο筮M行分析的方式稱為OOA，采用面向?qū)ο筮M行設(shè)計的方式稱為OOD暖侨，采用面向?qū)ο筮M行編碼的方式稱為OOP椭住。面向過程(OP)和面向?qū)ο?OO)本質(zhì)的區(qū)別在于分析方式的不同，最終導致了編碼方式的不同字逗。

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

架構(gòu)師之路(2)詳解面向過程

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

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

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

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

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

那是不是面向過程就不好窜醉，也沒有存在的必要了？我從來沒有這樣說過艺谆。事實上榨惰，面向過程的編程(OPP)已經(jīng)存在了幾十年了，現(xiàn)在依然有很多人在使用静汤。它的優(yōu)點就是邏輯不復雜的情況下很容易理解琅催，而且運行效率遠高于面向?qū)ο螅∣O）編寫的程序。所以虫给，系統(tǒng)級的應用或準實時系統(tǒng)中藤抡，依然采用面向過程的編程(OPP)。當然抹估，很多編程高手以及大師級的人物缠黍，他們由于對于系統(tǒng)整體的掌控能力很強，也喜歡使用面向過程的編程(OPP)药蜻，比如像Apache,QMail,PostFix,ICE等等這些比較經(jīng)典的系統(tǒng)都是OPP的產(chǎn)物瓷式。 　　象php這些腳本語言，主要用于web開發(fā)语泽，對于一些業(yè)務邏輯相對簡單的系統(tǒng)贸典，也常使用面向過程的編程(OPP)，這也是php無法跨入到企業(yè)級應用開發(fā)的原因之一踱卵，不過php5目前已經(jīng)能夠很好的支持OO了廊驼。

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

我舉個例子來說明面向過程的編程方式: 　　用戶需求：老板讓我寫個通用計算器牛郑。 　　最終用戶就是老板，我作為程序員敬鬓，任務就是寫一個計算器程序淹朋。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:rn"); scanf("%d",&nNum1); printf("Please input the operator:rn"); scanf("%s",&cOpr); printf("Please input the second number:rn"); 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; }

拋開細節(jié)不講，我想大多數(shù)人差不多都會這么實現(xiàn)吧数尿，很清晰仑性，很簡單，充分體現(xiàn)了“簡單就是美”的原則右蹦，面向過程的編程就是這樣有條理的按照順序來逐步實現(xiàn)用戶需求虏缸。 　　凡是做過程序的人都知道，用戶需求從來都不會是穩(wěn)定的嫩实，最多只能夠做到“相對穩(wěn)定”刽辙。用戶可能會隨時提出加個功能，減個功能的要求甲献，也可能會要求改動一下流程宰缤，程序員最煩的就是頻繁地變動需求，尤其是程序已經(jīng)寫了大半了，但這種情況是永遠無法避免的慨灭，也不能完全歸罪到客戶或者需求分析師朦乏。

以我們上面的代碼為例，用戶可能會提出類似的要求： 　　首先氧骤，你程序中實現(xiàn)了“加法”和“減法”呻疹，我還想讓它也能計算“乘法”、“除法”筹陵。 　　其次刽锤，你現(xiàn)在的人機界面太簡單了，我還想要個Windows計算器的界面或者Mac計算器的界面朦佩。 　　用戶需求開始多了并思，我得琢磨琢磨該如何去寫這段代碼了。我今天加了“乘”“除”的運算语稠，明天保不齊又得讓我加個“平方”宋彼、“立方”的運算，這要是把所有的運算都窮盡了仙畦，怎么也得寫個千八百行代碼吧输涕。還有，用戶要求界面能夠更換慨畸，還得寫一大堆界面生成的代碼莱坎，又得來個千八百行。以后先口，這么多代碼堆在一起型奥，怎么去維護，找個變量得半天碉京，看懂了代碼得半天厢汹，萬一不小心改錯了，還得調(diào)半天谐宙。另外烫葬，界面設(shè)計我也不擅長，得找個更專業(yè)的人來做凡蜻，做完了之后再加進來吧搭综。這個過程也就是“軟件危機”產(chǎn)生的過程。伴隨著軟件廣泛地應用于各個領(lǐng)域划栓，軟件開發(fā)的規(guī)模變得越來越大兑巾，復雜度越來越高，而其用戶的需求越來越不穩(wěn)定

根據(jù)用戶提出的兩個需求忠荞，面向過程的編程該如何去應對呢蒋歌？想大家都很清楚怎么去改帅掘。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:rn"); scanf("%d",nNum1); printf("Please input the operator:rn"); scanf("%s",cOpr); printf("Please input the second number:rn"); 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)就是將用戶需求進行“功能分解”府框。把用戶需求先分解成模塊(.h,.c)吱窝，再把模塊(.h,.c)分解成大的功能(function)，然后把大的功能(function)分解成小的功能(function)迫靖，如此類推院峡。

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

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

有的人把面向過程定義為：算法 + 數(shù)據(jù)結(jié)構(gòu)俺孙，我覺得也很準確。面向?qū)ο蟮木幊讨兴惴ㄊ呛诵闹兰郑瑪?shù)據(jù)處于從屬地位睛榄，數(shù)據(jù)隨算法而流動。所以采用面向過程的方式進行編程想帅，一般在動手之前场靴，都要編寫一份流程圖或是數(shù)據(jù)流圖。

如果大家對本文有意見盡可爭論港准，歡迎大家隨時拍磚旨剥。我有著鋼鐵一樣的心臟和城墻一樣的臉皮，承受能力極強浅缸，所以無論是支持意見還是反對反對意見轨帜，我都會認真閱讀，只要不是色情淫穢和反動言論衩椒，我盡量不刪貼蚌父。由于個人能力和時間有限蚕礼，也只能寫到這樣的水平了，大家諒解梢什。我的資料里有qq號奠蹬，加為好友后就可以看到，我的qq對任何人開放嗡午。 架

構(gòu)師之路(3)架構(gòu)師的職責

架構(gòu)師的職責 　　近來看到CSDN上有個CTO俱樂部囤躁，里面聊得是不亦樂乎。我懷著無比崇敬的態(tài)度荔睹，拜讀了一下牛人們的發(fā)言狸演。里面有個哥們發(fā)起一個話題：“CTO, 你多久沒有寫程序了？”僻他。有人回答：“不寫代碼的CTO,屬于......這公司問題大了!”宵距。看到這里吨拗，我就趕緊撤了满哪，怕忍不住反駁幾句，反而遭到牛人們的群毆劝篷。試想哨鸭，一個上點規(guī)模的IT公司，還得靠CTO來寫程序的話娇妓，那是不是才叫問題大了呢像鸡。當然，我沒有做過CTO哈恰，所以我有我的不同看法只估，而且還愿意表達出來，無知者無畏着绷。我情愿相信：我所理解的CTO跟這位CTO所理解的是兩回事蛔钙。所以我想，如果有人能把CTO的職責給標準化了蓬戚，也許就不會有這么多的爭論了夸楣。 　　同樣的道理，關(guān)于架構(gòu)師的定義子漩，大家也有著不同的理解豫喧。什么是架構(gòu)師？架構(gòu)師有哪些職責幢泼？我覺得有必要提前明確一下紧显，要不然大家溝通起來也會產(chǎn)生類似問題，子說子理缕棵，卯說卯理孵班，但是壓根說得不是一碼子事涉兽。

1 什么是架構(gòu)師 　　曾經(jīng)有這么個段子： 　　甲：我已經(jīng)應聘到一家中型軟件公司了，今天上班的時候篙程，全公司的人都來歡迎我枷畏。 　　乙：羨慕ing，都什么人來了虱饿？ 　　甲：CEO拥诡、COO、CTO氮发、All of 程序員渴肉，還有會計、司機都來了爽冕。 　　乙：哇仇祭，他們太重視你了，人才啊颈畸，這么多人迎接你乌奇！ 　　甲：沒有啊，就一個人承冰！ 　　乙：靠华弓，#%￥$%...

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

架構(gòu)師這個稱呼不是拍腦袋想出來的，是有國際標準（ISO/IEC 42010）可查的缸榄。架構(gòu)師是軟件開發(fā)活動中的眾多角色之一渤弛，它贍蓯且桓鋈恕⒁桓魴∽樯醮部贍蓯且桓鐾哦铀稀Ｎ⑷磯約芄故τ幸桓齜擲嗖慰跡頤遣慰家幌攏前鴨芄故Ψ治?種：企業(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的職責是決定整個公司的技術(shù)路線和技術(shù)發(fā)展方向碉输。蓋茨給自己的Title就是首席軟件架構(gòu)師籽前，網(wǎng)易丁磊也喜歡這么稱呼自己，實際上就是EA角色敷钾；IA的工作就是提煉和優(yōu)化技術(shù)方面積累和沉淀形成的基礎(chǔ)性的枝哄、公共的、可復用的框架和組件阻荒，這些都是一個技術(shù)型公司傳承下來的最寶貴的財富之一挠锥；特定技術(shù)架構(gòu)師TSA，他們主要從事類似安全架構(gòu)侨赡、存儲架構(gòu)等專項技術(shù)的規(guī)劃和設(shè)計工作蓖租；SA的工作則專于解決方案的規(guī)劃和設(shè)計，“解決方案”這個詞在中國已經(jīng)到了嚴重泛濫的程度羊壹，大忽悠們最喜歡把它掛在嘴邊蓖宦。所謂解決方案，就是把產(chǎn)品舶掖、技術(shù)或理論球昨，不斷地進行組合，來創(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)師的職責 　　架構(gòu)師主要職責有4條： 1尘颓、確認需求 　　在項目開發(fā)過程中，架構(gòu)師是在需求規(guī)格說明書完成后介入的晦譬，需求規(guī)格說明書必須得到架構(gòu)師的認可。架構(gòu)師需要和分析人員反復交流互广，以保證自己完整并準確地理解用戶需求敛腌。

2、系統(tǒng)分解 　　依據(jù)用戶需求惫皱，架構(gòu)師將系統(tǒng)整體分解為更小的子系統(tǒng)和組件像樊，從而形成不同的邏輯層或服務。隨后旅敷，架構(gòu)師會確定各層的接口生棍，層與層相互之間的關(guān)系。架構(gòu)師不僅要對整個系統(tǒng)分層媳谁，進行“縱向”分解涂滴，還要對同一邏輯層分塊友酱，進行“橫向”分解。 　　軟件架構(gòu)師的功力基本體現(xiàn)于此柔纵，這是一項相對復雜的工作缔杉。

3、技術(shù)選型 　　架構(gòu)師通過對系統(tǒng)的一系列的分解搁料，最終形成了軟件的整體架構(gòu)或详。技術(shù)選擇主要取決于軟件架構(gòu)。 Web Server運行在Windows上還是Linux上郭计？數(shù)據(jù)庫采用MSSql霸琴、Oracle還是Mysql？需要不需要采用MVC或者Spring等輕量級的框架昭伸？前端采用富客戶端還是瘦客戶端方式沈贝？類似的工作，都需要在這個階段提出勋乾，并進行評估宋下。 　　架構(gòu)師對產(chǎn)品和技術(shù)的選型僅僅限于評估，沒有決定權(quán)辑莫，最終的決定權(quán)歸項目經(jīng)理学歧。架構(gòu)師提出的技術(shù)方案為項目經(jīng)理提供了重要的參考信息，項目經(jīng)理會從項目預算各吨、人力資源枝笨、時間進度等實際情況進行權(quán)衡，最終進行確認揭蜒。

4横浑、制定技術(shù)規(guī)格說明 　　架構(gòu)師在項目開發(fā)過程中，是技術(shù)權(quán)威屉更。他需要協(xié)調(diào)所有的開發(fā)人員徙融，與開發(fā)人員一直保持溝通，始終保證開發(fā)者依照它的架構(gòu)意圖去實現(xiàn)各項功能瑰谜。 　　架構(gòu)師不僅要保持與開發(fā)者的溝通欺冀，也需要與項目經(jīng)理、需求分析員萨脑，甚至與最終用戶保持溝通隐轩。所以，對于架構(gòu)師來講渤早，不僅有技術(shù)方面的要求职车，還有人際交流方面的要求。

3 架構(gòu)師的誤區(qū) 1、架構(gòu)師就是項目經(jīng)理 　　架構(gòu)師不是項目經(jīng)理悴灵。項目經(jīng)理側(cè)重于預算控制扛芽、時間進度控制、人員管理称勋、與外部聯(lián)系和協(xié)調(diào)等等工作胸哥，具備管理職能。一般小型項目中赡鲜，常見項目經(jīng)理兼架構(gòu)師空厌。

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

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ū)分兩者的根本標準。

4 架構(gòu)師的基本素質(zhì) 1淹办、溝通能力 　　為了提高效率眉枕，架構(gòu)師必須贏得團隊成員怜森、項目經(jīng)理速挑、客戶或用戶認同，這就需要架構(gòu)師具有較強的溝通能力副硅。溝通能力是人類最普遍性的素質(zhì)要求姥宝，技術(shù)人員好像容易忽略，想成為架構(gòu)師就不能忽略想许。千萬不要抱著這樣的觀念：懷才跟懷孕似的伶授，時間久了總會被人發(fā)現(xiàn)的。還是天橋上賣大力丸的哥們說得對：光說不練假把式流纹，光練不說傻把式糜烹。看看你周圍的頭頭腦腦們漱凝，哪一個不是此中高手疮蹦，我們千萬不要鄙視，認為這是阿諛奉承茸炒、投機鉆營愕乎，凡事都要看到積極的一面，“溝通”的確是一種能力壁公。我認為自己是一個略內(nèi)向的人感论，因為我是農(nóng)村出來的孩子，普通話都說不好紊册，以前或多或少帶有點自卑感比肄，幻想著是金子總會發(fā)光，所以在職業(yè)生涯中吃了不少虧。現(xiàn)在芳绩，我深深懂得了溝通的重要性掀亥，我會很主動地跟同事們，跟老大們不定時地溝通妥色，感覺工作起來順暢多了搪花。 　　這一條我認為最為重要，所以排在首位嘹害。我甚至認為下面幾條都可以忽略撮竿，唯一這一條得牢記，而且要常常提醒自己吼拥。

2倚聚、領(lǐng)導能力 　　架構(gòu)師能夠推動整個團隊的技術(shù)進展，能在壓力下作出關(guān)鍵性的決策凿可，并將其貫徹到底惑折。架構(gòu)師如何來保證這種執(zhí)行力？這就需要架構(gòu)師具有領(lǐng)導能力枯跑。 　　架構(gòu)師的領(lǐng)導能力的取得跟項目經(jīng)理不太一樣惨驶。項目經(jīng)理主要負責解決行政管理，這種能力與技術(shù)關(guān)系不大敛助，他有人權(quán)和財權(quán)粗卜，再扯上一張“領(lǐng)導”的虎皮，采用“胡蘿卜加大棒”的方式纳击，基本上可以保證執(zhí)行力续扔。架構(gòu)師在項目里面可能更多地使用非正式的領(lǐng)導力，也就是我們常說的影響力焕数，里面包括個人魅力纱昧、技術(shù)能力、知識傳遞等等堡赔。

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

4器联、技術(shù)深度和廣度 　　架構(gòu)師最好精通1-2個技術(shù)，具備這種技術(shù)能力可以更加深入的理解有關(guān)架構(gòu)的工作原理婿崭，也可以拉近和開發(fā)人員的距離拨拓，并形成團隊中的影響力。 　　架構(gòu)師的技術(shù)知識廣度也很重要氓栈，需要了解盡可能多的技術(shù)渣磷，所謂見多識廣，只有這樣授瘦，才可能綜合各種技術(shù)醋界，選擇更加適合項目的解決方案。有的人說提完，架構(gòu)師技術(shù)廣度的要求高于技術(shù)深度的要求形纺，這是很有道理的。

總而言之，一句話：架構(gòu)師是項目團隊中的技術(shù)權(quán)威。 　　面向過程和面向?qū)ο筮@兩個基本概念束倍，不僅架構(gòu)師需要非常清楚脆诉，程序員、設(shè)計師也要非常清楚藻治，這也是系統(tǒng)分析、設(shè)計和編碼最基本的常識。我接觸的程序員戏羽，很多人只停留在一種“似是而非”的程度，這是不行的楼吃，想要繼續(xù)前進始花，就得把基礎(chǔ)夯實妄讯，所以我覺得很有必要先回回爐，補補課酷宵。

后記：在講面向?qū)ο笾皩懥诉@么一篇亥贸，主要就是要把前面漏下的功課補上。

架構(gòu)師之路(4)詳解面向?qū)ο?/strong>