• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>

    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>

            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            

    
            

            




            







												


        


            


            牽著老婆滿街逛
            

            嚴以律己,寬以待人. 三思而后行.
            
GMail/GTalk: yanglinbo#google.com;
            
MSN/Email: tx7do#yahoo.com.cn;
            
QQ: 3 0 3 3 9 6 9 2 0 .
            

            




            
	
					
	
            
		
            
			做人、做事，做架構(gòu)師——架構(gòu)師能力模型解析
		
            
		架構(gòu)師，“個人特性”與“技術(shù)技能”缺一不可；而“技術(shù)專業(yè)能力”、“人際關(guān)系能力”和“業(yè)務(wù)能力”更是優(yōu)秀架構(gòu)師重要的三種能力。



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



            引子

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

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

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

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

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

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



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

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

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

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

            抽象是思維能力、模型化是表達能力

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

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

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

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



                                                        圖2 能力模型中的個人特性

            然而這個“抽象系統(tǒng)”可能只構(gòu)建在你的思維意識里，還必須把它描繪出來。因為不能只是你自己思考清楚，系統(tǒng)就能設(shè)計完成。這個“描繪”就依賴于后面兩種表達能力，一種是描繪概念實體，一種是描繪實體上的邏輯——有趣的是，這似乎又回到了“程序＝結(jié)構(gòu)＋算法”。

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

            所以大家應(yīng)該清楚，我們再如何稱贊UML，它也只是一種對模型化系統(tǒng)的“表達能力”，你只能把它當一種輔助表達的工具去使用，它本身既不能幫助思考，也不見得能作為抽象過程中的或抽象思維環(huán)境中的參考。

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

            推動：設(shè)計做大，實施做小

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

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

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



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

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

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

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

            局部與全局

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

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

            所以當架構(gòu)決策談及“全局”時，其目標并不見得是“保障當前項目”，而又必須由當前項目去完成。

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

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

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

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

            其它

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

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

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

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

            作者簡介

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

		
            
			posted on 2009-10-20 14:56 楊粼波 閱讀(651) 評論(0)  編輯 收藏 引用  
		
            
	
            
	
	





            
	    
    




            



            


            

	
            
		
		
            只有注冊用戶登錄后才能發(fā)表評論。
            
		
            
		
				
		
		
		
            
		
            			
		
		
		
		
            
		
            
			
		
            
		
            
			
		
            
		
            
			
            網(wǎng)站導(dǎo)航:
			博客園  
			IT新聞  
			BlogJava  			
			博問  
			Chat2DB  
			管理
			
            		
		
            
		
            
			
				

            


            

            		
		
            
	
            	

            



            

				

            



    
    







            
	   
	



人妻精品久久无码区|
国产一区二区精品久久|
伊色综合久久之综合久久|
久久久噜噜噜久久中文字幕色伊伊|
久久一日本道色综合久久|
99久久精品国产一区二区三区
|
99精品伊人久久久大香线蕉|
国产精品成人99久久久久|
久久99热这里只有精品66|
7777久久亚洲中文字幕|
欧美久久久久久午夜精品|
人妻精品久久无码区|
亚洲国产精品成人久久蜜臀
|
久久精品综合一区二区三区|
99精品久久精品一区二区|
久久国产精品免费|
国产午夜福利精品久久2021|
日本欧美国产精品第一页久久|
波多野结衣中文字幕久久|
四虎国产精品免费久久|
久久本道伊人久久|
久久人人爽爽爽人久久久|
欧美伊人久久大香线蕉综合|
国产综合成人久久大片91|
国产精品青草久久久久婷婷|
亚洲精品美女久久777777|
久久伊人五月丁香狠狠色|
久久久久无码中|
久久久久久A亚洲欧洲AV冫|
国产精品久久久久影院色|
日韩乱码人妻无码中文字幕久久
|
狠狠色丁香婷婷综合久久来|
一本色道久久88精品综合|
亚洲?V乱码久久精品蜜桃|
久久精品亚洲男人的天堂|
国产亚州精品女人久久久久久|
精品久久香蕉国产线看观看亚洲|
久久久久亚洲AV无码麻豆|
久久精品夜夜夜夜夜久久|
久久精品人人槡人妻人人玩AV|
亚洲香蕉网久久综合影视|