3 架構師的職責
近來看到CSDN上有個CTO俱樂部,裡面聊得是不亦樂乎。我懷着無比崇敬的态度,拜讀了一下牛人們的發言。裡面有個哥們發起一個話題:“CTO, 你多久沒有寫程式了?”。有人回答:“不寫代碼的CTO,屬于……這公司問題大了!”。看到這裡,我就趕緊撤了,怕忍不住反駁幾句,反而遭到牛人 們的群毆。試想,一個上點規模的IT公司,還得靠CTO來寫程式的話,那是不是才叫問題大了呢。當然,我沒有做過CTO,是以我有我的不同看法,而且還願 意表達出來,無知者無畏。我情願相信:我所了解的CTO跟這位CTO所了解的是兩回事。是以我想,如果有人能把CTO的職責給标準化了,也許就不會有這麼 多的争論了。
同樣的道理,關于架構師的定義,大家也有着不同的了解。什麼是架構師?架構師有哪些職責?我覺得有必要提前明确一下,要不然大家溝通起來也會産生類似問題,子說子理,卯說卯理,但是壓根說得不是一碼子事。
3.1 什麼是架構師
曾經有這麼個段子:
甲:我已經應聘到一家中型軟體公司了,今天上班的時候,全公司的人都來歡迎我。
乙:羨慕ing,都什麼人來了?
甲:CEO、COO、CTO、All of 程式員,還有會計、司機都來了。
乙:哇,他們太重視你了,人才啊,這麼多人迎接你!
甲:沒有啊,就一個人!
乙:靠,#%¥$%…
很多的創業公司,一人身兼數職的情形還是很常見的。至少,我是經曆過的,一個人包辦了所有的開發過程,連測試我都做了,絕對的一條龍,但是經常踩鋼絲、騎 獨輪車總會有失足的時候,結果有一次,從我手裡發出去的CD光牒母盤,含有病毒僵屍,以至于被迫收回已經推上市場的2萬張CD光牒,從那之後,我的心髒就開始變得 無比堅強,現在就是整個背景服務都癱瘓了,我也隻是微微一笑。其實,一個人身兼架構師和程式員,甚至多種角色,沒什麼不妥,後面還會講這個話題,這種現象 不是中國特色,跟國外是完全接軌的。我曾經跟米國的一個工程師在msn中聊過類似的話題,發現他們的路子跟咱們沒什麼不同,在IT這個行業,我們跟世界的 差距隻有1天,他們剛弄出來的新東西,我們這裡第2天保準見得到。
架構師這個稱呼不是拍腦袋想出來的,是有國際标準(ISO/IEC 42010)可查的。架構師是軟體開發活動中的衆多角色之一,它可能是一個人、一個小組,也可能是一個團隊。微軟對架構師有一個分類參考,我們參考一下, 他們把架構師分為4種:企業架構師EA(Enterprise Architect)、基礎結構架構師IA(Infrastructure Architect)、特定技術架構TSA(Technology-Specific Architect)和解決方案架構師SA (Solution Architect)。微軟的這個分類是按照架構師專注的領域不同而劃分的。
EA的職責是決定整個公司的技術路線和技術發展方向。蓋茨給自己的Title就是首席軟體架構師,網易丁磊也喜歡這麼稱呼自己,實際上就是EA角色;IA 的工作就是提煉和優化技術方面積累和沉澱形成的基礎性的、公共的、可複用的架構群組件,這些都是一個技術型公司傳承下來的最寶貴的财富之一;特定技術架構 師TSA,他們主要從事類似安全架構、存儲架構等專項技術的規劃和設計工作;SA的工作則專于解決方案的規劃和設計,“解決方案”這個詞在中國已經到了嚴 重泛濫的程度,大忽悠們最喜歡把它挂在嘴邊。所謂解決方案,就是把産品、技術或理論,不斷地進行組合,來創造出滿足使用者需求的選擇。售前工程師一般都是帶 着它到客戶那裡去發揮的。
大公司會把各種類型的架構師分得很清楚,小公司一般就不那麼講究了,架構師多數是是IA+TSA+SA,一人包打天下,是以說大公司出專才,小公司出全才。
實際工作中,我們也經常會見到另一種比較簡單的分類方式,把架構師分為軟體架構師和系統架構師。軟體架構師基本上是TSA+IA,這也是程式員最容易突 破,最可能走上的一條道路,比如Java架構師、DotNet架構師、LAPM架構師等等,我後面所講的内容都是與軟體架構師的相關的話題。系統架構師實 際上是SA+TSA,更着力于綜合運用已有的産品和技術,來實作客戶期望的需求。系統架構師要求通曉軟、硬體兩方面的知識,是以它的知識體系相對龐雜。關 于系統架構師的話題,我們可以稍後再作讨論。
3.2 架構師的職責
架構師需要參與項目開發的全部過程,包括需求分析、架構設計、系統實作、內建、測試和部署各個階段,負責在整個項目中對技術活動和技術說明進行指導和協調。
架構師主要職責有4條:
1、确認需求
在項目開發過程中,架構師是在需求規格說明書完成後介入的,需求規格說明書必須得到架構師的認可。架構師需要和分析人員反複交流,以保證自己完整并準确地了解使用者需求。
2、系統分解
依據使用者需求,架構師将系統整體分解為更小的子系統群組件,進而形成不同的邏輯層或服務。随後,架構師會确定各層的接口,層與層互相之間的關系。架構師不僅要對整個系統分層,進行“縱向”分解,還要對同一邏輯層分塊,進行“橫向”分解。
軟體架構師的功力基本展現于此,這是一項相對複雜的工作。
3、技術選型
架構師通過對系統的一系列的分解,最終形成了軟體的整體架構。技術選擇主要取決于軟體架構。
Web Server運作在Windows上還是Linux上?資料庫采用MSSql、Oracle還是MySQL?需要不需要采用MVC或者spring等輕量級的架構?前端采用富用戶端還是瘦用戶端方式?類似的工作,都需要在這個階段提出,并進行評估。
架構師對産品和技術的選型僅僅限于評估,沒有決定權,最終的決定權歸項目經理。架構師提出的技術方案為項目經理提供了重要的參考資訊,項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡,最終進行确認。
4、制定技術規格說明
架構師在項目開發過程中,是技術權威。他需要協調所有的開發人員,與開發人員一直保持溝通,始終保證開發者依照它的架構意圖去實作各項功能。
架構師與開發者溝通的最重要的形式是技術規格說明書,它可以是UML視圖、Word文檔,Visio檔案等各種表現形式。通過架構師提供的技術規格說明書,保證開發者可以從不同角度去觀察、了解各自承擔的子系統或者子產品。
架構師不僅要保持與開發者的溝通,也需要與項目經理、需求分析員,甚至與最終使用者保持溝通。是以,對于架構師來講,不僅有技術方面的要求,還有人際交流方面的要求。
3.3 架構師的誤區
1、架構師就是項目經理
架構師不是項目經理。項目經理側重于預算控制、時間進度控制、人員管理、與外部聯系和協調等等工作,具備管理職能。一般小型項目中,常見項目經理兼架構師。
2、架構師負責需求分析
架構師不是需求分析員。需求分析人員的工作是收集需求和分析需求,并與最終使用者、産品經理保持聯系。架構師隻對最終的需求稽核和确認,提出需求不清和不完整的部分,他會跟需求分析員時刻保持聯系。架構師是技術專家,不是業務專家。
3、架構師從來不寫代碼
這是一個尚存争論的問題。目前有兩種觀點:
觀點1:架構師不寫代碼,寫代碼純體力活,架構師寫代碼大材小用。架構師把UML的各種視圖交給開發人員,如果有不明确的地方,可以與架構師随時溝通。
觀點2:架構師本來自于程式員,隻是比程式員站的層面更高,比程式員唯一多的是經驗和知識,是以架構師也免不了寫代碼。
我個人覺得這兩種說法是與架構師的出身和所處的環境有關。
架構師首先是一個技術角色,是以一定是來自于技術人員這個群體,比如系統架構師,多是來自于運維人員,可能本身代碼寫得并不多,或者說寫不出來很漂亮的代 碼。軟體架構師多是來自于程式員,有着程式員的血統和情懷,是以在項目開發過程中,可能會寫一些核心代碼。我們的理想是架構師不用寫代碼,但事實上有時候 過于理想。架構師寫不寫代碼,可能取決于公司的規模、文化、開發人員的素質等現實情況。另外,架構師也不是跟程式員界限分得那麼清楚,按照能力也有高中低 之分,寫不寫代碼不是區分兩者的根本标準。
3.4 架構師的基本素質
周星馳有個片子《喜劇之王》,劇中的尹天仇整天揣着本《演員的自我修養》,一個好演員不僅需要天賦,也需要一定的理論指導,無師自通的人畢竟是少 數。架構師的成長過程也是這樣。從普通程式員到進階程式員,再到架構師,是一個經驗積累和思想升華的過程。經驗積累是一個方面,素質培養是另一個方面,兩 者相輔相成,是以我覺得有必要把架構師的所要具備的素質羅列一下,作為程式員努力的方向。
1、溝通能力
為了提高效率,架構師必須赢得團隊成員、項目經理、客戶或使用者認同,這就需要架構師具有較強的溝通能力。溝通能力是人類最普遍性的素質要求,技術人員好像 容易忽略,想成為架構師就不能忽略。千萬不要抱着這樣的觀念:懷才跟懷孕似的,時間久了總會被人發現的。還是天橋上賣大力丸的哥們說得對:光說不練假把 式,光練不說傻把式。看看你周圍的頭頭腦腦們,哪一個不是此中高手,我們千萬不要鄙視,認為這是阿谀奉承、投機鑽營,凡事都要看到積極的一面,“溝通”的 确是一種能力。我認為自己是一個略内向的人,因為我是農村出來的孩子,國語都說不好,以前或多或少帶有點自卑感,幻想着是金子總會發光,是以在職業生涯 中吃了不少虧。現在,我深深懂得了溝通的重要性,我會很主動地跟同僚們,跟老大們不定時地溝通,感覺工作起來順暢多了。
這一條我認為最為重要,是以排在首位。我甚至認為下面幾條都可以忽略,唯一這一條得牢記,而且要常常提醒自己。
2、上司能力
架構師能夠推動整個團隊的技術進展,能在壓力下作出關鍵性的決策,并将其貫徹到底。架構師如何來保證這種執行力?這就需要架構師具有上司能力。
架構師的上司能力的取得跟項目經理不太一樣。項目經理主要負責解決行政管理,這種能力與技術關系不大,他有人權和财權,再扯上一張“上司”的虎皮,采用“ 胡蘿蔔加大棒”的方式,基本上可以保證執行力。架構師在項目裡面可能更多地使用非正式的上司力,也就是我們常說的影響力,裡面包括個人魅力、技術能力、知 識傳遞等等。
3、抽象思維和分析能力
架構師必須具備抽象思維和分析的能力,這是你進行系統分析和系統分解的基本素質。隻有具備這樣的能力,架構師才能看清系統的整體,掌控全局,這也是架構師 大局觀的形成基礎。你如何具備這種能力呢?一是來自于經驗,二是來自于學習。架構師不僅要具備在問題領域上的經驗,也需要具備在軟體工程領域内的經驗。也 就是說,架構師必須能夠準确得了解需求,然後用軟體工程的思想,把需求轉化和分解成可用計算機語言實作的程度。經驗的積累是需要一個時間過程的,這個過程 誰也幫不了你,是需要你去經曆的。但是,如果你有意識地去培養,不斷吸取前人的經驗的話,還是可以縮短這個周期的。這也是我寫作此系列的始動力之一。
4、技術深度和廣度
架構師最好精通1-2個技術,具備這種技術能力可以更加深入的了解有關架構的工作原理,也可以拉近和開發人員的距離,并形成團隊中的影響力。
架構師的技術知識廣度也很重要,需要了解盡可能多的技術,所謂見多識廣,隻有這樣,才可能綜合各種技術,選擇更加适合項目的解決方案。有的人說,架構師技術廣度的要求高于技術深度的要求,這是很有道理的。
總而言之,一句話:架構師是項目團隊中的技術權威。
面向過程和面向對象這兩個基本概念,不僅架構師需要非常清楚,程式員、設計師也要非常清楚,這也是系統分析、設計和編碼最基本的常識。我接觸的程式 員,很多人隻停留在一種“似是而非”的程度,這是不行的,想要繼續前進,就得把基礎夯實,是以我覺得很有必要先回回爐,補補課。
後記:在講面向對象之前寫了這麼一篇,主要就是要把前面漏下的功課補上。