一、卓越的程序員

    1、每個好架構師都是一位出色的程序員

架構師,聽起來是如此神秘的一個稱號。尤其是在開發領域剛入門不久的菜鳥級程序員眼中,架構師都是高手,都是牛人,都是如此高高在上的存在。

不過,在搞了四、五年編程之後,程序員們往往早已失去了當年對這些“高級”職位的神秘感,甚至會對自己所在項目的架構師抱怨不已,背後裏稱他們是一群水王。所以有江南白衣曾撰文述說:“國內的架構師到了三十歲以後很多就往理論上跑,而國外的架構師在往上發展的同時保持下面的編程體驗,所以國內多水王,而國外則多大師。”

這就是我們今天這篇文章的論題:一個優秀的軟件架構師,首先一定是一個出色的程序員。

這句話按照Fred George先生的話來說,那就是“不編程的架構師的職業生涯是短暫的”。他說這句話的背景主要是針對有些架構師的設計與實現有斷層的問題而言的,因为如果架構師不去實踐,只是想當然的認为“沒問題,這個想法能實現”,那麼對於項目的落實而言是個很大的隱患。支付寶架構師馮大輝也表示過,架構師是一個比較“虛”的崗位,主要的問題都在“落地”的過程中。

 

而一個架構師確認一個想法究竟能不能落地的最直接的方法,就是自己編寫代碼,嘗試“實現一個系統最難實現的一部分”(Fred George)。看看Fred,他自己就是最好的示範:年紀一大把了,仍然每天都在編寫代碼。事實上,我們可以列舉出一個長長的頂級架構師的列表,你會發現他們沒有一個不是頂級的程序員。

我們可以列舉出一個長長的頂級架構師的列表,你會發現他們沒有一個不是頂級的程序員
我們可以列舉出一個長長的頂級架構師的列表,你會發現他們沒有一個不是頂級的程序員

不過這在邏輯上或許沒有多少說服力,因为似乎這並不能證明一位資深架構師憑自己的經驗感覺不能夠知道一個想法能不能落實。如果你覺得上面這些只是某些西方老頭兒對編程的古怪癖好,那麼不妨看看eBay的架構師Randy Shoup先生是如何總結架構師在項目中的職責的:

1. 產品團隊要做一個新產品,架構師開工了。架構師要幫助產品團隊把可行性、技術需求以及權衡取舍等因素一一剖析清楚。

2. 技術需求出來了,架構師的主要工作開始了:設計整體的技術實現步驟。Randy在後面補充說“大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作”,而認为自己應獨自完成這個步驟則是新手架構師常見的誤區。

3. 與開發團隊一起,完成設計與實施的細節

4. 與開發團隊和運維團隊一起,完成部署的過程

5. 與運維團隊一起,進行部署之後的維護和故障排除

在這個過程中,一個架構師至少有一半以上的工作是需要與開發團隊一起進行的。按照Randy的描述,這是“一個架構師不能將實施細節拋之腦後”的體現。而且與開發團隊一起工作,命令式的領導方式並不被推崇,一個架構師必須通過自己的個人影響力來對開發團隊進行指導工作。而什麼是影響力?說的直白一些,就是通過自己寫代碼以及和其他成員一起寫代碼,來指導團隊成員實現每個架構細節的思路。

 

只要稍微思考一下,就會明白此舉的重要性。如果一個架構師靠命令管理開發團隊,告訴他們“要實現這個模塊”,“要實現那個功能”,而團隊也嘗試照辦。可是或許是架構師的要求太高了,或許是團隊的開發實力不夠,團隊成員便會向架構師求助:您看這個我們不知道如何實現,您能否指導一下?架構師可能知道怎麼處理,也可能沒有仔細思考過這個問題,但又覺得自己做大事者不拘泥於小節也,於是一皺眉頭扔下一句:這是你們的事,你們自己解决!

然後就是矛盾的開始了。架構師只覺得團隊技術不夠,而團隊則對架構師愈發不滿。項目黃了不說,開發團隊中也會傳出各種說法,比如說“此君其實是個一行代碼也不會寫的大忽悠!”

架構師,你會寫代碼麼?

綜上所述,便映證了Fred的那句斷言:“不編程的架構師的職業生涯是短暫的”。一個架構師不僅要會寫代碼,還必須要能夠寫出自己設計的系統中最難實現的那段代碼。這样他才能夠放心的把“落地”的這個重擔交给開發團隊來做。

讓我用Fred的這句話做为本篇的總結:“一個架構師的價值在於,他不僅能看到系統的美,而且能夠在建造系統的時候能夠把這些美創造出來。”

是的,每個好架構師都是一位出色的程序員。

 

2、Fred George:架構師是使用代碼作畫的大師

 

为了深入的了解這些問題的答案,51CTO開發頻道展開了對國內外幾個著名架構師的一系列郵件訪談。本次訪談的對象是一位資深的程序員、咨詢師和架構師,Fred George先生。

架構師個人簡曆

Fred George
Fred George

Fred George先生在敏捷開發領域頗有聲望,在業界有將近40年的開發經驗。早年他在IBM工作。退出IBM之後,以獨立咨詢師的身份在美國工作了十多年。後來他加盟了ThoughtWorks,成为早期致力於推動敏捷開發的一批開發者。現在他離開了ThoughtWorks,在英國的TrafficBroker公司就任解决方案架構師一職。51CTO編輯曾在2009年敏捷中國大會上與Fred先生進行過一次面對面的交流,編者對Fred先生充滿生趣的演講和對編程如同小孩子一般的熱情印象頗深。

以下是此次訪談的具體內容。

編輯:不同的企業和項目經理對架構師往往定義不完全相同。在您的團隊中,對架構師是如何定義的?對於招聘的架構師會有怎样的技能要求?

Fred:首先澄清一下,我的這個頭銜:“解决方案架構師(Solutions Architect)”,其實只是为了簽證弄的一個頭銜。我其實是沒有頭銜的。不過呢,我確實自詡为一個架構師。

基本上,架構師是使用代碼作畫的大師。最近在那些頂級的軟件思想者中刮起了一股討論系統之“優美”以及“簡約”之風。一個架構師的價值在於,他不僅能看到系統的美,而且能夠在建造系統的時候能夠把這些美創造出來。

在我看來,系統是一個個有機的生命。跟企業一样,系統也需要施肥澆水,需要健康的成長。與企業一样,一個系統可能會在短期內被濫用(比如在需要短期內快速盈利的驅使下),不過如果濫用的時間過長,系統最終將會無法支持。與CEO一样,一個架構師對系統的這個特性了如指掌。他們能夠識別什麼是濫用,系統能夠承受的限度,並將系統引回到健康的道路上。

編輯:假設有三名優秀的程序員,A尤其擅長沟通與團隊管理;B的編程功底深厚,且對新技術能快速掌握;C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程序員成为架構師?

Fred:不是每個人都能夠具有一個架構師的能力。在你提供的選項中,C的成功幾率是最高的。駕馭概念的技能,在我看來是每一個人最高的潛力。對於其他的需求,如語言、經驗等,我可以通過培訓來建立。

B有可能會成为一個好架構師:她顯示出了概念理解能力的一些苗頭。如果她開始領悟一個好系統的模式(pattern)是怎麼一回事,那麼她便能夠完成轉型。

對於A我不作考慮。把他放在架構師的位子上,就相當於把“架構師”當做“設計師”的升級版。這就好像把你的祖父扔到F1賽車場上,僅僅因为他開車的時間最長。這個絕對不對頭。

領導能力是重要的,但並不是一個好架構師的組成因素。

編輯:對於一個剛剛從程序員轉型過來的架構師,通常有哪些問題是他最難把握的?

Fred:如果你從程序員的職位轉型,决定自己不再是程序員了,那麼你的架構師生涯將是短暫的。最好的架構師都在寫代碼。Kent Beck曾經寫道:“代碼就是設計與殘酷現實之黃昏的交匯(Code is when design meets the harsh reality of dawn.)”。他的意思是,我們畫出來的設計都是美好的,但最好的設計僅僅是被翻譯为優雅代碼的那些。一個無法將願景帶入代碼的架構師將永遠無法了解我們這個急速變化的行業所展示的深度。

 

所以說,不編程的架構師的職業生涯是短暫的。

做为一個架構師,我需要實現(這個過程是結對編程,我會有一個搭檔)一個系統最難實現的一部分。我將其稱之为“先鋒”,因为這是我檢驗我腦中的主意是否真的是一個好主意的過程。我在第一次實施中會細化這個主意。然後我才會放心的讓編程團隊的其他成員按照這個模式來走。這就是“架構”。

有點跑題了。對於一個菜鳥架構師而言,最大的障礙就在於承認你並不知道詳細的答案,但你信心滿滿的認为可以和程序員和設計師一起找到這個答案。

另一個新手架構師經常遇到的問題是“優美”以及“簡約”。每次當進行决策的過程中出現這些概念的時候,項目經理往往對這样的理由不置可否。項目經理通常有短期目標要實現,而對優美還是簡約這样的概念並不感冒。但事實上,他們這是對系統未來健康狀況的不重視。

最後,菜鳥架構師往往是出色的程序員。而他會發現團隊中的其他程序員貢獻的代碼看起來不太美。菜鳥架構師必須要學會界定哪些醜陋的代碼是可以接受的,哪些是不能接受的。

架構師是藝術家,他們的成就往往不會在他們活着的時候被贊賞。

 

二、抽象思維 駕馭概念的技能是最高潛力

在近日開發頻道對數位架構師進行采訪的時候,編輯觀察到一個很有意思的現象,那就是他們在提起一個假想架構師的時候會下意識的使用“she”或者“她”來指代。然而我們這次采訪到的的架構師們卻全都是男士,這似乎是一個比較難以理解的現象。

 

對高級架構師王翔先生的訪談似乎能在一定程度上解答這個現象的由來。在訪談中,王翔先生說到自己在特定情況下會優先培養女性做为架構師,因为“架構師在創造性、知識匯總方面根據個人經驗似乎女性更适合。”

無論王翔先生的個人經曆是否常態,既然說男人來自火星而女人來自金星,那麼這至少表明是否适合架構師一職與人的思維模式有很大關系。在這一系列的訪談中,所有接受采訪的架構師們都一致的表示邏輯思維和抽象思維能力是一個架構師最重要的素質。eBay的Randy Shoup先生稱擁有條理清晰的邏輯思維能力的人“就像稀有動物那样難找”。Fred George則表示“駕馭概念的技能,在我看來是每一個人最高的潛力”,並表示自己不太介意這样一個苗子在其他方面的技能和經驗的匱乏,因为在他看來除了思維之外的其他因素都是可以培養的。

邏輯思維,抽象思維,這些幹巴巴的名詞並不比高舉某某旗幟、將某某貫彻到底的口號說明了更多問題。架構師們習慣了思考“虛”飄飄的概念,但如果不能讓非IT人員明白這個或那個概念到底是在說什麼,那麼這個架構師也注定是失敗的(詳見架構師技能之沟通技術篇)。所以首先有必要解釋一下這些架構師們說的這兩個概念是什麼意思。

程序員對邏輯思維是再熟悉不過了,因为程序員寫的代碼都是邏輯。如果怎样怎样就做什麼什麼,如果什麼什麼就觸發這個或停止那個。編寫條件這样的邏輯構成了代碼中的絕大部分,因此缺乏邏輯思維能力基本等同於不可能成为程序員。架構師必須要有很好的邏輯思維的理由,事實上和架構師必須先是個出色程序員的理由是一样的(詳見架構師技能之優秀程序員篇)。

因此本文的關鍵在於抽象思維能力。這個能力常常被與物理成績或數學能力等同起來,但它事實上並不是計算能力。比如說小學常見的數學題,兩個城之間的鐵路長度500公裏,一輛火車平均時速100公裏,問這輛火車從這個城到那個城需要多少時間。學生們往往會陷在於500公裏、100公裏/小時和5小時這些數字中,但是這道題的抽象因素其實是在“長度”、“時速”和“時間”這三個概念當中。

這其中其實又有兩個概念,一個是將實在的事物概念化,一個是將模糊的感覺數量化。看到一個蘋果,能夠將其抽象为質量、大小、顏色、形狀、味道等概念的組合,就是概念化,而量化則是在概念化之上,將蘋果用多少克、多少立方厘米來定義;至於顏色、形狀、味道等概念,則是還沒有完善量化標准的概念。如果在沒有彻底理解概念的前提下過分拘泥於數字,那麼到頭來只是活躍了頭腦的計算功能而無助於抽象思維的鍛煉。

人們往往發現優秀的數學家、物理學家以及軟件架構師有着很多相似的素質,甚至往往能夠一人精通這好幾個領域(比如UML之父James Rumbaugh),其中很重要的原因就是這個抽象思維的能力。架構師在接到商業需求之後,最主要的工作就是將其轉化为技術需求。這個過程的完成與架構師抽象思維的能力密不可分。好比說這個項目是eBay那样的電子商務平台,那麼eBay的主架構師第一個閃過的念頭多半就是:這個系統,將會有“買、賣、搜索、付款等功能。”而負責每一個功能的架構師,又需要對這些部分進行進一步的抽象化。

 

很難想象一個缺乏抽象思維能力的人,要如何擔負起架構師的工作。

而抽象思維和之前所講的邏輯思維能力,並非是同一個東西,這也是为什麼並非所有優秀的程序員都能夠成为一個好的架構師。不過編輯在這裏並不是想說難以成为架構師的程序員都是缺乏天賦,事實上抽象思維並非是一個不能培養的能力,只是它需要你主動地去思考。正如支付寶的馮大輝所說,程序員要想成为架構師,必須“有意識的開拓技術視野,深入理解公司業務”,這其實就是一個擴展視野的同時,培養抽象思維能力的過程。架構師在項目中處於位置較高的地方,工作的問題很難說找到誰來學習、借鑒一下,更多的是摸索、琢磨。如果你有這样的决心和毅力,那麼相信抽象思維的能力也是不會難倒你的。

 

三、技術前瞻性 架構師:站在技術的山頂向前眺望

鐵打的程序員,流水的技術。程序員的開發生涯可能長達幾十年,但一門技術的平均壽命卻不長。因此作为程序員們的技術領袖,架構師必須有很好的技術前瞻性,要先於大家了解到最新的技術。

 

有人談到技術高手與架構師的區別就在於,架構師不光是着眼於現在,不僅僅局限於開發細節,比如如何調用,如何並發等等。而是跳出三界外,考慮一下面向未來問題和潛在風險的應對之道。

那程序員該如何培養自己的技術前瞻性呢?很大程度上來說還是要學好英語,國外的新東西,老東西的新特性肯定都是用英文寫的。即使國內有很多網站也在做外電翻譯,但面對海量的信息肯定是杯水車薪。而且有不少程序員所面對的領域本身關注度就不高,靠外部翻譯似乎很難實時跟進。這時就需要有良好的外語水平,能看懂國外的技術文章和文檔,能與國外相關人士進行交流。

外功是從外部獲得最新技術信息,那麼內功就是自己的邏輯思維能力和接受能力。再新的技術,其實也與以前的技術有結合。這也是为什麼我們說架構師首先是卓越的程序員,也就是這個道理。

但是架構師並不是將前沿技術的名詞天天掛在嘴上之人,整天只知道在程序員面前大談“雲計算,SaaS”這些東西的架構師注定成不了好的架構師。新的技術雖好,但是程序員接受和再培訓還需要時間,還要考慮到系統的兼容性問題。因此,誇誇其談的名詞專家,並不是我們努力的方向。好的架構師,應該提前想到如何为程序員盡可能減輕負擔,比如數據庫軟件新的特性可以提高性能,簡化查詢步驟,那架構師是不是第一時間要引導程序員去适應新的特性,提高開發效率。

架構師,你追的上潮流麼

被技術潮流拋棄的架構師是可悲的

技術前瞻性還體現在對新技術的選擇上,哪些東西适合自己團隊,哪些不适合肯定要自己心中有本帳。工具選好了再返工的人力成本和時間成本是很多公司沒法負擔的,利润就那麼多,經不起瞎折騰。程序員在自己的學習過程中,也可以适當培訓一下自己,比如新的IDE中有新的功能,但是要安裝這新版本的IDE需要更新系統,更新硬件,還要更新和數據庫的接口。這一套下來花費的時間成本是多少,換算成工資是多少?我想事事都這样過一遍,我們在做選擇的時候就不會盲目。

架構師在自己所處的領域肯定了解頗深,未來本領域技術該如何發展,應該有自己的理解。也會對未來技術的發展有所期盼,有自己的見解。當然這屬於比較發散的想法,個人有個人的目標。

總結:技術人生如逆水行舟,不進則退。

 

四、問題解决大師 架構師修煉課程:透過問題看本質

一個剛剛從學校畢業的、致力於投身編程事業的年輕人,在投遞了n封簡曆之後,終於如願以償得到了第一份編程的工作。如果他在求學期間沒有積累過項目經驗,那麼可以說這就是他職業的起點,他青澀的編程之路開始了。

 

可能他一開始會滿腔抱負、意氣風發的按照自己的方式完成小頭目交给自己的一些練手任務,然後懊惱的發現小頭目對這些看似能夠完成任務的代碼大搖其頭,指指點點;然後在真正進入項目之後,又會被各種不知道從哪裏冒出來的bug和漏洞搞得暈頭轉向……

這些問題一方面和這位菜鳥程序員缺乏經驗有關,但是在過來者看來,造成這些問題的一個主要原因正是在於,這位程序員沒能看到問題的本質。

而看到問題的本質,也是架構師所必須具備的素質。

所謂看到問題的本質,實際上是一個思考的層面問題。比如說,你現在看到的這篇文章,從表面上看,就是你的顯示屏顯示出來了一些文字,但這明顯不是它的本質。從內容而言,這篇文章是一篇有關架構師技能的文章,它是對一個職業的某一項能力的描述;從技術而言,這篇文章是在世界上某台服務器上的數據庫中提取出來的某些信息,經過漫長光纜和層層協議的傳遞,經過你的網線插口(或無線接收器)進入了你的機器,通過瀏覽器解讀並最終呈現出來。

聽起來,這個和另一篇文章介紹的同样是架構師所需要的“抽象思維”有點像,只是方向不同:抽象思維是往高層次的升華,透過問題看本質則是往深層次的挖掘

讓我們看看文章一開始的那位菜鳥程序員为什麼總是失敗。如果你是一位PHP程序員,那麼可以参考這篇文章,裏面總結了一些常見的問題。最簡單的一個(有時被用作面試題)可能出現在這样的情況下——小頭目說:“顯示用戶提交的ID名”,然後菜鳥程序員大筆一揮:


  1. echo $_GET['username'];

小頭目閱畢自然抓狂不已,因为這是一個再明顯不過的安全隱患。菜鳥程序員被小頭目訓了一頓,然後知道這样做是有問題的。

這個事情如何與通過問題看本質有關?這個就取决於這位菜鳥程序員是如何改正這個錯誤的。如果這位程序員只是把下面的那段“合格”代碼抄襲過來並死記硬背,那麼,以後等待這位程序員的大概是比較悲慘的結局——因为漫長的代碼生涯中有極多類似的問題,而等到他進入真正的項目之後,犯錯誤是有成本的。他的學習方式表示他沒有主動避免這样類似問題的能力,那麼他可能將會造成極大的損失,從而最終失去在這個行業的競爭力。

但是,如果他了解到代碼之下,更深層次的那些機制,比如echo是如何執行的?在什麼時候執行的?哪些字符可能導致安全問題?htmlspecialchars为什麼能解决這個問題?它真的解决這個問題了麼?那麼他將會一點一點的進步,逐漸成为一個合格的程序員。

什麼是本質?將世界萬物理解为原子,將整個互聯網理解成0和1,這倒的確是非常本質了,不過並不能解答任何問題。從問題看本質,實質上是一個從表層逐步深入的過程。在架構師面對一個用戶需求時,這個“用戶需求”是非常表層的——比如說,一個自動遠程備份數據庫的功能。而架構師的主要工作,就是把這样的“業務需求”翻譯成“技術需求”。這個過程一方面需要通過抽象思維將用戶需求提煉为启動、讀取、存儲、中斷處理等模塊,而另一方面則需要看到更深層次的網络、操作系統、硬件等方面,以及其可靠性、穩定性、适用性、安全性等問題。

上面述說的是個小型需求,按照某些行業標准,這頂多只能算是一個資深程序員的工作,而沒有達到“架構”的規模——即,非大型項目中不存在真正的架構師(按照王翔先生的描述,大型項目差不多是“100M(RMB)、B(RMB)、10B(RMB)”這些數量級)。那麼,讓我們看看大型系統的情況。以eBay为例,按照其架構師Randy Shoup的介紹,電子商務站這样大型的系統有兩個層面的功能:“垂直功能,如買、賣、搜索、付款等。水平功能,如數據庫、事件與消息系統、服務基礎設施、展示框架等。”按照編者的理解,如果說垂直功能是抽象思維的產物,那麼其中的水平功能的劃分則是一個架構師“透過問題看本質”能力的體現——這些劃分體現了架構師看到了表層的功能是建造在哪些因素之上的。同時,架構師要看到“電子商務站”這样一個服務的本質,就是要提供一個多人同時在線進行交易的平台,因此系統的本質也必須包括“功能,性能,可伸縮性,可管理性,安全性,以及可用性”這些因素。否則,即使搭了個架子,沒有上述特性的系統是完全無法滿足客戶需求的。

 

看到這裏我們應該明白了,“透過問題看本質”並不是什麼神秘的能力,而是有一定經驗能力的程序員都具備的能力。如果你在編寫Java代碼時考慮到了JVM的性能,在編寫PHP代碼時想到了潛在的安全問題,甚至於在編寫HTML+CSS頁面時考慮到了不同瀏覽器的兼容性,這些都體現了“透過問題看本質”的素質。只是,架構師之所以为架構師,是在於他們在面對龐大系統之時,仍然能夠敏銳的發現其底層之真實。這不僅需要此哲學層面的“內功”,還需要架構師具有多領域知識和經驗的積澱。

“透過問題看本質”,這也是程序員往往需要修煉十餘年才有資格晉升为架構師的主要原因之一。程序員們,好好努力吧!

架構師:透過問題看本質

 

五、內力 架構師要努力成为內功深厚的高手

一聽到架構師,首先便想到的是在一間寬敞的房間中間坐着一位衣着得體的中年男人,望着落地窗外的風景凝思,萬千思緒在腦海裏翻騰,頗有運籌帷幄千裏外的氣勢。程序員究竟是做架構師還是項目經理,最近看到微軟潘正磊女士的一篇博文,给出了一些启示。

 

“當時我們團隊來了一位剛被提拔的開發經理,每次當我陳述完一個問題,他都會迫不及待地提出他的解决方案。在這之後很長的一段時間,他還是一直習慣性地建議我如何如何處理問題。通過平日的觀察,我也發現他更喜歡花時間對技術和產品進行深度探討,而非團隊管理。於是幾個月後,我找了一個機會跟他說,“我覺得你做軟件架構師說不定會更有意思。”而他自己也覺得這個建議不錯。幾個星期後,他真的轉去做架構師的工作,我們團隊也迎來了一個新的開發經理。”

這個例子中體現出來的正是架構師深厚的技術底蘊,或許很多程序員更向往項目經理的職位。從上面我們可以看出,程序員在平時的培養過程中還是過於看重技術處理細節,而不喜歡管理。這样看來,成为架構師還是更多程序員的最終歸屬,盡管項目經理的頭銜看起來是更吸引人,但是架構師作为一個純技術性崗位,更适合廣大的程序員。

修煉內功不等於死鑽開發技術

講到內功深厚,大家心想“那我就往死裏鑽研技術,不就完了?”。確實,很多人理解的內力就是開發技術,包括語言的掌握、對框架的掌握、數據庫管理能力、安全管理能力等等。但是我們看到,架構更多的內力體現在對技術的綜合運用上,光會編程的程序員,最多就能做到高級程序員,也就是技術實現上的高手。

51CTO編輯在對高級架構師王翔先生的采訪中,曾提到這样一個問題“假設有三名優秀的程序員,A尤其擅長沟通與團隊管理;B的編程功底深厚,且對新技術能快速掌握;C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程序員成为架構師?”

王翔的回答是這样的“C,後面依次遞減是B、A。A更适合做項目經理、產品經理。而且根據個人的經驗,雖然女性程序員開發階段顯得不如男性那麼快深入和入手(Programmer),但能堅持到Developer、S. Developer、 Designer、S. Desinger階段她們的思維能力優勢就顯示出來。如果B是女性Desinger級別的人員,我寧願選擇培養她,因为架構師在創造性、知識匯總方面根據個人經驗似乎女性更适合。”這裏我們看到,內力更多的是一種思考能力,結合技術的思考能力。光有程序開發的能力,不會思考,那只能做個代碼狂人。只思考而沒有腳踏實地的技術開發能力,那就是忽悠人的表現,更不招人喜歡。

內功的修煉第一層,自然是開發技術的培養。從寫第一行代碼開始,就多想为什麼,有沒有什麼其他的路徑能實現同样的功能。當我們寫了很長時間代碼了,是不是就該考慮更多的問題,比如優化、預期未來。其次是對架構的熟悉,下面是大家比較熟悉的Struts 2架構圖。要做一名優秀的架構師,就得對各種架構做到了熟於心。

Strut2架構圖

更高層次的修煉,就在於不同技術的學習。要懂得數據庫知識,懂得安全監控方面的知識,還要懂得網络構建方面的知識。這是比較高層次的內功修煉,很有可能與程序員目前所處的開發環境關系不大,對程序員來說並不是什麼有用的東西。但一個優秀的架構師必須懂得這些,才能更好地抽象軟件的使用環境,選擇符合需要的架構以及開發模式。

 

六、知識領域要寬廣 架構師:要成为百科全書式的智者

通常來說我們將架構師分为系統架構師、軟件架構師等等。雖然有分工不同,各自所處的層次也有不同,但是究其核心能力,跨領域知識的學習能力,是架構師的強項所在。

 

首先,作为一名卓越的程序員,架構師肯定不欠缺開發方面的知識。從架構到方法論,從數據處理到安全監控。可以說IT開發層面上,架構師可以做到爐火純青的地步。但是這僅僅是一名卓越程序員的能力級別,離架構師那還有很大的一段距離。

架構師身为一名技術領袖,需要通過發散知識的光芒來統禦開發團隊的。如果只是對本行業知識做到爛熟於心,那還僅僅是一名熟練工的水平。要想晉升更高的層次,還需要跳出“只緣身在此山中”的困惑。例如在目前國內架構師,至少有網络領域为依托,物流金融證券等熟知越多越好,這個是應用級別。比如南天的金融平台研發部門,但是這個成不了底層平台架構師。再往上走,很多公司的研發人員不是精通計算機,可能是物理極为精通,比如中軟研發聲納軟件部門很多人對數據信號極有研究。

架構師都是大忽悠

很多程序員對架構師似乎存在偏見

這裏就會出現一個常見的問題“架構師是不是一個只會誇誇其談,只會忽悠下面人而對軟件開發了解不多的人?”更尖酸的問題還在於架構師連一段代碼都不會寫。相信這是一定的誤解,就好像銀行的高層管理人員,要更多的從宏觀的角度考慮問題,盡管他們點鈔的能力肯定不及下面的櫃台人員。事必躬親的諸葛亮,最後的結局還是國破家亡,過多的幹預細節忽視整體,絕對是要打敗仗的。架構師學習更多跨領域知識,也是为了在接受一個項目時,能更快更准確的找到解决問題的“命門”。

有的程序員也會說,如果多學習跨領域、跨學科的東西,會不會成为什麼都懂,但什麼都不精的人?其實在這裏的跨領域,並不是要求大家都成为每個領域的專家。最重要的是有一門敲門磚,學習的引子。如果開發一套金融系統,對於财務結算以及處理方法都不了解,那別說是勝任架構師的任務,連普通程序員的工作也不可能做好。假設大家工作一段時間後,對某領域很了解,但由於工作變動的緣故,到其他公司後,開發的領域完全不會。這裏就要用到跨領域知識學習的能力了,需要大家样样都要知曉。

談到跨領域學習,知識面廣似乎是最好實現的目標,只要博覽群書,加上高中之前各學科紮實的基礎,相信大多數程序員本身就具備一定的跨領域學習的能力。但想成为真正的百科全書式的智者,恐怕不光是簡單覺得眼熟就行。在條件允許的情況下,程序員其實可以去参加一些其他領域的專業考試。比如参加會計資格證的考試,抑或其他專業中較初級的考試。這样的經曆,主要還是在於“以學促考”,通過一定的壓力讓自己能鑽進去學習。

還有一種跨領域學習的目標,就是多語種的學習。學習除英文之外的語言,既能開拓國際視野,也能在平時的工作中有所建樹。

架構師害怕程序員知道的技能,其實就是他們自己“獨門絕技”。雖然他們自己不說,但是我們自己還是能總結出來,在一定深度之內成为一個“雜家”並沒有什麼不好。其關鍵在於所學的跨領域知識,能否成功的運用到工作中去。51CTO在獨家采訪王翔高級架構師時,他曾提到,一個致力於成为架構師的程序員。需要盡可能的参加大的項目開發,盡管積累1000個小項目的經驗也是很好的程序員,但好的架構師必須参與更大的項目,哪怕數量不多。從中我們能解讀到一個信息,大的項目意味着學科跨度的增大,所需要學習的跨領域知識必然也足夠大,也就更有利於程序員向架構師晉級。

 

七、沟通與交流 架構師:一群善於沟通的技術領袖

架構師的沟通方向與項目經理相比,還是有一定的區別。比如項目經理有很大一部分時間需要與客戶進行沟通,進一步弄清需求。而架構師的沟通主要在於開發團隊內部,一種純技術上的沟通。這也是作为技術領路人的架構師,最日常的工作。

 

當架構師對整個系統分析完畢,有一些架構師喜歡昏天黑地的奮鬥幾天,然後寫出一本厚厚的架構書扔给程序員。在此之後就不做過多的交流與沟通,“具體實現?那是程序員的事情,我怎麼能去幹涉他們呢?”其實在這裏,這位架構師就犯了錯誤,他並沒有將自己真正融入開發團隊中,而是以一種高高在上的救世主姿態出現。其實架構師未必就是神人,很多錯誤還是要大家一起來研究來解决的。

究竟怎样才能是一名合格的架構師,成为一名真正能說會道的程序員呢?首先自然是沟通要清晰明了,平和待人。架構師不能將自己锁在自己的象牙塔上,頤指氣使的對程序員發號施令。這样的態度必然遭到程序員的憤恨,大家都是一样的技術人員,只是分工的不同,为什麼要受氣呢?

做到人性化的沟通,需要我們在平時就進行培養。寫出大部頭的架構書,有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解,直觀簡單的UML圖可以極大的方便程序員理解架構師的意圖。其次,可以召開小範圍的技術人員會議,大家一起來討論,一起理解架構師真正的意圖。甚至就是一塊小白板,幾支筆就能把問題擺清楚,講明白,統一意見後的團隊必然幹勁十足,再不會出現互相推諉的情況。

架構師就相當於一支球隊的主教練,如何將自己布置的戰術交到執行的球員,也就是開發人員的腦袋裏,是關乎勝利的關鍵。那麼怎样才能成为一名能說會道的程序員呢?

在一般人的印象裏,程序員都是一群略顯呆滯,沟通能力不強的技術狂人。邏輯思維非同常人,但就是倒不出來。有些人通過找女朋友作为旁證,連經濟适用男中的定義原型都是IT人士,月薪4000以上,不善言談,最後娶一剩女为妻。看來我等程序員,真的只能被人如此定義了。雖說架構師技術層面上的東西與前例不可同日而語,但是也看到沟通能力上,程序員還有很大的發展空間。

架構師,你講的我聽不懂

其實很多程序員都是善於談吐的,木訥的形象只是人們的誤解。但是如何來改變呢?首先我們需要更多的感性思考,說話時也要注重別人的感受,尊重對方才能更好的交流。微軟MVP陳廣琛在與51CTO編輯談到程序員沟通能力時,曾說道:“很多程序員總能列出一堆的理由來,說明为什麼自己不适合學習或者不需要掌握某項與程序無關的技能,例如說演講、英語、設計等等。但其實問題並沒有那麼复雜,你需要考慮的只是多學一項技能是否對你的職業發展更有利,只要你願意,沒什麼是不能改變的。”

總結:架構師不是油腔滑調的程序員,但是一句話都憋不出來的程序員,是做不好架構師的。

 

八、權衡取舍 架構師:每天要在魚和熊掌之間做選擇

在訪問聚聚呀項目總監梁遠華先生時,梁先生說到“權衡取舍”是一個架構師在項目中最難把握的。“一個產品會有很多的東西要做,什麼是可做的,什麼是重要的,什麼是將來能做的,每天都做做選擇題。”

 

eBay的傑出架構師Randy Shoup先生也表示“對權衡取舍方面有着出色的把控能力”是自己團隊招聘架構師的一個重要要求。

你聽說過軟件架構師的職業培訓中有一個叫做ATAM的課程麼?ATAM,全稱Architecture Tradeoff Analysis Method,意为架構權衡分析方法。雖然這样的培訓並非必要,但是值得我們去學習了解一下。

ATAM概念流程圖  ATAM概念流程圖

沒有一個人可以建造一個沒有缺陷的架構。這個項目可能缺乏時間,缺乏金錢,缺乏人手,或者缺乏合适的技術。在項目從開始到進行中的每時每刻,架構師都需要對這些架構的“缺陷”有明確的了解。

在架構師的藝術氣質篇我們提到了“基於需求考慮問題”和“基於系統考慮問題”的不同,並提到這中間會存在一些矛盾,需要架構師來做權衡决策。站在系統的角度上,架構師可能覺得自己手頭的資源不夠,他需要更多的時間、人以及新技術,但是項目經理和其他團隊成員很可能會拒絕,而他們也有自己的理由。

所以Fred George先生提出了“短期濫用”的說法,即在系統能夠承受的範圍內做出一些妥協。在ATAM方法中,分析的思路是基於“情景”的:你需要提出各種可能的情景,然後來證明在每一個用戶使用場景中,系統的哪一些內容是必要的、不可丟棄的——從而確定哪些部分是暫時可以不予考慮的。

到了這一步,便已經是一個技術性問題;但是這個問題的解决過程卻是對架構師“軟”技能的一個考驗:即架構師有沒有看到各方面訴求的差異,以及有沒有意願为了這些差異而做出妥協。

案例分析1

讓我們看一個案例,這是現任微軟Visual Studio Business Applications總經理潘正磊女士在博客上分享的一段經曆:

“分享一件去年發生在上海Visual Studio團隊和印度SQL Server團隊之間的故事。兩個團隊郵件往來10個回合後仍無法在某個問題上達成一致,因此上海團隊把我拉進了郵件討論。於是我從頭開始讀郵件,讀到第四封我大致了解到,分歧的根源在於,兩個團隊所沟通的,根本不是同一件事。

印度團隊認为自己開發了一個特別棒的SQL Compact工具,能滿足客戶的重要需求,所以要求把這個功能加入Visual Studio 2010 Beta 1 (Visual Studio 2010 的第一個公開測試版);上海團隊認为當時已接近測試版的發布日期,考慮到功能加入產品前必須遵循的一系列發布流程,時間上恐怕來不及了。之後的郵件裏,印度團隊一直強調這個功能是多麼棒,應該讓它在測試版中發布(也就是一個解决方案),卻從沒有解釋他們要解决什麼問題;上海團隊則不斷重申功能加入必須按流程來,可見他們之間的交流完全錯位了。在這個典型的案例中,印度團隊努力推動一個解决方案,卻沒有想清楚所要解决的問題为什麼會對上海團隊也非常重要。之後,我們發現的確有一個用戶使用場景需要用到SQL Compact工具,於是我們詢問新工具對這個使用場景有何幫助,是否能與其他新功能兼容 … …一旦我們能明確這個問題的本質,我們就不難找出雙方都接受的解决方案,例如,立即加入第一個測試版,或稍後加入第二個測試版,甚至是加入Service Pack等等。”

如果說架構師的藝術氣質體現在其把系統當做生命、站在系統本身的角度思考問題,那麼架構師出於對客戶、項目經理、開發者和測試者不同視角的理解而做出權衡妥協則充分體現了其職業性。上面潘女士提到的案例,是一個大型項目中的兩個開發團隊之間的理解沖突所引起的。

A:一個特別棒的功能應該被加入到產品發布中。

B:一個功能加入到產品發布中應該要謹慎並經過充分的審核。

這是“把一個功能加入到產品發布”從兩個角度的解讀,兩個解讀都有自己的道理。而在潘女士参與之前,雙方的論點沒有交集,“交流錯位”了。而要實現權衡與妥協的前提,則是讓B了解“這個功能是很棒”,並且讓A了解“新功能必須在謹慎考量之後才能加入產品發布”。在潘女士的努力下,雙方最後都理解了對方,並找到了都能接受的解决方案。而這個過程正是通過設計和描述“場景(scenario)”來推動的。

案例分析2

上面是開發工具項目中的一個小案例,下面讓我們看看另一個案例。Amazon.com的CTO,Werner Vogels在08年的12月底發過一篇很有参考價值的博文:Eventually Consistent(最終一致),討論對象是Amazon的S3,SimpleDB,EC2等大型雲計算服務。Werner對這些服務的描述直達本質,一針見血:“這些服務需要在安全、伸縮性、可用性、性能以及性價比方面獲得高分,同時必須維持全球上百位客戶不間斷的使用需求。”

文中講述了不少深入的架構知識,對於廣大程序員而言或許有些難以理解;但是有一句話是一句很直白的經驗總結,充分的解釋了“權衡妥協”的意思:“在一個理想的世界中,只存在唯一一個一致模型:在實施一次升級之後,所有觀察者都能夠看到這個升級。”言外之意就是,對於系統而言,在某一個地方或某一個層面發生的改變,勢必將影響到系統的其他地方和層面,乃至整個系統。正因为系統的各個部分是互相關聯的,因此为每一個變動考慮權衡(trade-off)是必要的,有意義的。

Werner提到的一個正面案例就是在90年代中期的時候,人們只知道可用性(availability)很重要,但對於追求可用性需要犧牲什麼渾然不知。出於對可用性權衡的研究,加州大學的Eric Brewer教授提出了CAP理論,認为對於一個共享數據的系統而言,數據持續性、系統可用性、對網络劃分的耐受性這三個屬性(property)是不可調和的,任何時候只能同時達成兩個。

雖然理論只是理論,但理論並非憑空而來,Eric的理論是總結了90年代大型互聯網系統建設的經驗研究成果。對於Amazon雲計算服務的架構師而言,這些經驗總結自然是無法忽視的;在知道了魚和熊掌不可兼得的情況下,要深刻理解各個方面不同角度的訴求,並找出各方都可以接受妥協的制衡點,自然是必不可少的。

總結

具體要如何制衡是一個很大的話題,甚至於每個系統都會有不同的情況。很多人在各個方面都做過很多研究,指導架構師們一些方向。對於架構師而言,僅僅有權衡妥協的意識還遠遠不夠:這個意識只是前提之一,如果缺乏了對技術紮實的了解,那麼這個意識則毫無意義。同時在分析權衡的過程中會有很多抽象的概念(這些概念可能還需要被量化),並且深入到系統的各個層面,因此架構師的抽象思維能力和看到問題本質的素質也是必須的。

 

抽象能力,深入本質,權衡意識——這三點都是十分珍貴的思想素質。這三種能力配合豐富而紮實的“硬”技能(技術)、合格的“軟”技能(沟通)以及敏銳的眼光,無論在哪個行業都能成功。而由於架構師這個職業本身就是IT界的高級職業,這所有的能力和素質就都成了架構師的入門必備敲門磚。不過每個人的時間、精力以及天生素質都是不同的,本次介紹的架構師十大技能全部修煉是很困難的。想要成为架構師的程序員們,首先要自己權衡决策一下,看看自己應該如何修煉才能達到最好的效果——這也是權衡能力的一次練習吧。

 

九、藝術氣質

1、優美的系統與架構師的藝術氣質

“系統是一個個有機的生命。跟企業一样,系統也需要施肥澆水,需要健康的成長。與企業一样,一個系統可能會在短期內被濫用(比如在需要短期內快速盈利的驅使下),不過如果濫用的時間過長,系統最終將會無法支持。與CEO一样,一個架構師對系統的這個特性了如指掌。他們能夠識別什麼是濫用,系統能夠承受的限度,並將系統引回到健康的道路上。”

 

上面是一段架構師對於構建優美系統的描述。這段話的主人說,“架構師是使用代碼作畫的大師。”——在他看來,架構師最大的價值在於藝術。這並非是Fred George自家的看法,高級架構師王翔先生也表示“好的A(編者注:A即Architect,架構師的簡稱)需要有些藝術氣質”。

什麼是優美的系統?

商業軟件項目的首要目標是實現來自客戶或公司的商業需求。然而,在架構過程中僅僅考慮到實現商業需求而建立的系統往往缺乏伸縮性、安全性、可維護性、可靠性、可移植性等等,導致其在短短數年內便因無法與時俱進而被拋棄。這一點幾乎每一位維護過項目的程序員應該都能夠體會到:面對着缺乏文檔、不知所雲的代碼,想要修改或添加一個功能卻無從下手。

而一個優美的系統則是可以像有機的生命一样成長的,這是因为從系統開始架構的那一刻起,架構師就考慮到這個系統以後將會面臨的挑戰,为系統的成長預留好空間。項目經理經常會對這位架構師提出的看似理想化的要求不置可否——項目經理只想着能夠盡快以比較低的成本實現客戶的需求,然而這些充滿藝術美感的想法其實是打造健康——因而優美——的系統的根本因素。

架構師的藝術氣質使其站在了與項目經理不同的立場上:項目經理從商業需求的方向考慮,而架構師則從系統本身的方向考慮。在商業氣息很濃的項目中這會引發一些沖突,這也是为什麼最出色的系統往往出自學院,而商業項目中的架構師必須具備權衡取舍及妥協能力的原因。

藝術氣質的另一體現就是對簡約的追求,這在Google或Apple的大部分產品上有很好的體現。看起來是兩回事,不過系統的簡約與系統的健康往往是相輔相成的。

架構師的藝術氣質

在軟件開發產業發展的過程中逐漸建立起了一些行業准則和参考標准,這些將有助於架構師在面對复雜需求時仍然能夠保持清晰地頭腦來思考問題。學習前人總結的軟件與架構方面的知識,遵循既定的指導標准——比如,按照模版編寫軟件架構文檔——看似死板,卻是必要的修煉。這些架構師的基本功是全面的、抽象的、深層次的。沒有這些基礎,那麼架構師連實現商業需求都會感到吃力,更不要說去顧及需求之外的東西。另外我們提到過架構師需要有前瞻性:超前的眼光是架構師實現其藝術追求的彈藥。

閱讀公開的軟件架構文檔(Software Architecture Document)是一個很好的學習途徑(在Google上能夠找到很多)。軟件架構文檔是架構師在項目早期階段對於系統的一個描述性概覽,這份文檔提供了這個系統預計實現功能的概述,這個系統將會使用什麼技術以及可能存在的技術局限,以及最重要的部分:視圖模型。

軟件架構文檔

視圖模型是業內在20世紀90年代開始逐步建立起來的一套規範(IEEE 1471),不同的視圖從不同的角度對系統的不同方面進行關注。之前所提到的項目經理注重商業需求而架構師注重系統健康的矛盾,其實在這個視圖模型中都有相應的描述,为架構師開展思路提供了很好的指引。過去的十多年間出現了很多指引性的視圖以及框架,一些常見的包括:

用例視圖(Use-Case View):這是業務需求的角度。

邏輯視圖(Logical View):這是功能實現的角度,用例執行的流程圖。

上面兩個視圖是必需的,也往往是項目經理最關注的部分。如果只考慮這兩個角度,系統可以被建立,但正如之前所描述的那样,是不可能優美的。架構師還需要視情況考慮下面這些視圖:

進程視圖(Process View):如果系統是多線程的,高並發的,則需要考慮線程的角度。

部署視圖(Deployment View):如果系統分布在多節點,則需要考慮服務器端和客戶端節點等硬件映射的角度。

數據視圖(Data View):如果持久層在系統中很重要,則需要考慮數據的角度。

還有很多其他的視圖,在這裏就不一一列舉了。這些視圖都是從系統的角度來看問題。有些視圖框架有一定通用性,比如業內廣为流傳的4+1模型、RM-ODP模型等等;但是對於每一個系統需要考慮哪些視圖,則需要架構師去摸索、去感覺、去研究;況且現在新技術層出不窮,一個比較前沿的項目需要從前人沒有考慮過的角度看問題也不是沒有可能。如果架構師沒有一定的藝術氣質來指引方向,那麼一味的照搬現有的模式可能會水土不服而使系統變得臃腫复雜,而完全不考慮商業需求之外的因素則會讓系統先天不足而夭折。

 

不過正如之前所提到的,如果沒有紮實的技術基礎,如果架構師缺乏全局觀、抽象思維能力以及透過問題看本質的能力,那麼他僅僅为了實現客戶需求都會感到力不從心,更不用說發揮自己的藝術氣質雲雲了。

從另一個角度來講,做藝術的架構師們也都是行業裏大師級別的人物了,這也是架構師們的終極目標吧!

 

2、獨家專訪梁遠華:架構師需要廣泛的知識面

成为一個軟件架構師往往需要具備十年以上的軟件開發經驗,入門的門檻是相當高的。而架構師的工作與實際項目經驗密不可分,尤其是在互聯網產品愈發重要的當下,一個軟件架構師往往需要掌握多項技能。程序員如果想要修煉为一個架構師,究竟需要培養自己的哪些技能?近日,51CTO開發頻道對廣州鐵克司雷網络科技有限公司(techsailor.cn)梁遠華先生(Leung)進行了郵件專訪。梁先生現在是網络社區平台聚聚呀(jujuya.com)項目的項目總監。

 

架構師個人簡曆

聚聚呀項目總監梁遠華先生  聚聚呀項目總監梁遠華先生

梁遠華先生有十年的IT工作經驗,在鐵克司雷公司負責了整個聚聚呀項目的架構與實施。梁先生接觸過各種各样的工作,做過的工種也是多種多样,服務過的公司也是類型多样,並且曾經和朋友一起兩次創業。曾經從事計算機教學,網管,程序員,網站項目管理等工作,並曾在信息產業部第五電子科研所及地球村計算機科技公司積累了不少寶貴經驗。

以下是此次訪談的具體內容。

編輯:軟件架構師必須具備哪些技能或素質?哪項技能(素質)是您認为最重要的?

梁遠華:就我的經驗,下面三點是十分重要的。

1、整合分析能力

就拿聚聚呀來說吧,我們的宗旨是“讓大家結識共同興趣愛好人群的平台,可以方便讓每個人創建和管理自己社區的平台”,這個是我們現在的核心,對於一個架構師應該有很強的分析能力,能夠根據產品的宗旨,目標,分析產品的定位和產品業務,整合現有的技術領域用最佳的方式來實現產品的概念。

2、產品實現規劃能力

對於任何一個互聯網產品如何實現是架構師的重要責任之一,需要保證產品功能的現實,產品功能的可持續性,產品的穩定性及產品的可用性等。產品的這些需求都依懶於架構師對產品技術的規劃。我們團隊在產品的現實規劃上有自己明確的目標和具體的可行性實施方案,以滿足產品在升級,改版的需要。

3、橫向沟通能力

一個產品它會分成多個部門的合作,各部門沟通的有效性直接會影響到產品的質量和產品的進度。聚聚呀產品現在有7個部門的同事協同工作,對於架構師的溝通要求是需要去同各個部門間進行沟通,交流,獲得更多的產品信息,業務數據,運營指標,產品需求等各種信息的匯集才能作为產品架構决策的基礎數據。

編輯:要成为一個架構師,是否存在快速成長的捷徑?普通程序員如何一步步向架構師的目標靠近?

梁遠華:成为架構師嚴格上來說是沒有什麼捷徑的,架構師從產品的生命周期上來看,他所涉及的層面很廣,而且他所需要的知識面也會很廣,需要過程更需要時間的學習和磨練。

 

我們的團隊也會有一個培訓機制,會挑選出一些比較有發展潛力的開發人員通過引導培訓方式讓他們走上架構之路。

我們的經驗是從以下幾個方面着手:

1、 擴大知識面:提升對互聯網行業的認知度,對互聯網產品的分析,並且通過小團隊分享方式對互聯網“熱門現象”進行案例分析。

2、 專業度訓練:提升橫向和縱向的技能培訓,特別是對專業態度的培訓很重要,要求開發人員對自己的做的工作有強烈的責任心。

3、 分析思維訓練:提升開發人員對產品功能需求的分析以及對產品業務需求的分析整合能力。

51CTO編輯:假設有三名優秀的程序員,A尤其擅長沟通與團隊管理;B的編程功底深厚,且對新技術能快速掌握;C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程序員成为架構師?

梁遠華:我會選擇C在邏輯思維和抽象能力方面表現優秀,架構師需要很強的抽象能力。

編輯:在一個軟件項目中,通常有哪些問題是架構師最難把握的?

梁遠華:我感覺有下面兩點——

1、 對問題的定位,分析

2、 權衡取舍

以上二點在做聚聚呀產品過程中有深刻的體會,特別是第二點,一個產品會有很多的東西要做,什麼是可做的,什麼是重要的,什麼是將來能做的,每天都做做選擇題。

 

十、管控能力 架構師要善於管理整個開發團隊

管理被很多開發人視作“虛”的東西,平時程序員也不會去鑽研管理的學問。身为程序員中的領路人,架構師一般也被認为依靠人格力量進行管控,更多的是以理服人。可以說在現階段的中國,很大程度上還處於泰勒的科學管理階段,員工只需要機械,高效的完成工作即可。

下面是泰勒的相關理論:工作定額原理、挑選頭等工人、標准化原理、計件工資制、勞資雙方的密切合作、建立專門計劃層、職能工長制、例外原則。仔細思考過後,這些東西有很多與現在的工作相似。就拿工作定額和挑選頭等工人來說,每位程序員的工作量都是訂好的,工資標准也是按照技術最好的“大拿”來做對比。至於人性化管理,滿足更高層次的需要,很多項目經理現在還考慮不到程序員的要求,項目經理就是泰勒理論中的職能工長而已。

 

作为一名優秀的架構師,比較迫切的管理任務可能就是開發成本與收益平衡的問題。舉例說,采用MySQL做數據庫與采用Oracle做數據庫,價格肯定有很大差距。但是究竟該采用何種技術,架構師需要仔細權衡用戶的報價與本公司收益率的問題。又比如說采取甲技術開發出的軟件,界面大方性能一般,但是需要耗費程序員更多的勞動時間,那在有些場景下就不如采用乙技術快速開發後節約的大量人力成本,盡管界面有些難看。

因此,架構師在管理和控制的能力上,需要有自己獨到的見解,而不是簡單的認为這是項目經理或者财務部門的事情。身为技術專家的架構師,隨不需要處理那些煩雜的日常管理。奇虎架構師李釗在一次接受采訪時道出過架構師們的心聲,技術人才轉向管理就是莫大的浪費。對,如果架構師只是一味的去進行項目管理,那就和其他市場人員沒有任何區別了。在這裏架構師所需要的管理與控制,其實是從技術的角度,對一些問題的控制,特別是開發過程中的監控,而不是普通意義上的純粹管理。

在51CTO架構師系列選題文章中,有一篇是講沟通能力的文章,其實這就是一種“管理”。通過這样的管理,能增強技術團隊內部的團結。安全監控也是架構師的重要職責,負責監督整個開發過程中可能出現的問題,在出現問題後還要牽頭及時解决問題。這裏我們講到的管控能力,就是這種內部團結的實現,是一種對於程序員人格尊重的實現。馬斯洛的五種需求理論中,就有“被尊重的需求”,程序員在一個感覺輕松,被尊重的環境中,其潛在的創造力是難以預料的。

馬斯洛的五種需求

馬斯洛五種需求是良好管理的根基

良好的駕馭管理開發團隊的能力,能夠讓架構師在開發項目中遊刃有餘,不會出現意料之外的幹擾。而對於程序員來說,愉悅的開發環境,不光是一個好心情,更能寫出優美的代碼。當然要做到這一點,架構師自己要有良好的人格修養,能從內散發出人格魅力。另外良好的技術內功也是必備條件,要能讓程序員們心悅誠服的接受架構師的領導,而不是發出“架構師一行代碼都不會寫!”的質疑。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *

Post Navigation