3 架構師的職責
近來看到CSDN上有個CTO俱樂部，裏面聊得是不亦樂乎。我懷着無比崇敬的態度，拜讀了一下牛人們的發言。裏面有個哥們發起一個話題：“CTO, 你多久沒有寫程序了？”。有人回答：“不寫代碼的CTO,屬於......這公司問題大了!”。看到這裏，我就趕緊撤了，怕忍不住反駁幾句，反而遭到牛人們的羣毆。試想，一個上點規模的IT公司，還得靠CTO來寫程序的話，那是不是才叫問題大了呢。當然，我沒有做過CTO，所以我有我的不同看法，而且還願意表達出來，無知者無畏。我情願相信：我所理解的CTO跟這位CTO所理解的是兩回事。所以我想，如果有人能把CTO的職責給標準化了，也許就不會有這麼多的爭論了。
同樣的道理，關於架構師的定義，大家也有着不同的理解。什麼是架構師？架構師有哪些職責？我覺得有必要提前明確一下，要不然大家溝通起來也會產生類似問題，子說子理，卯說卯理，但是壓根說得不是一碼子事。
3.1 什麼是架構師
曾經有這麼個段子：
甲：我已經應聘到一家中型軟件公司了，今天上班的時候，全公司的人都來歡迎我。
乙：羨慕ing，都什麼人來了？
甲：CEO、COO、CTO、All of 程序員，還有會計、司機都來了。
乙：哇，他們太重視你了，人才啊，這麼多人迎接你！
甲：沒有啊，就一個人！
乙：靠，#%￥$%...
很多的創業公司，一人身兼數職的情形還是很常見的。至少，我是經歷過的，一個人包辦了所有的開發過程，連測試我都做了，絕對的一條龍，但是經常踩鋼絲、騎獨輪車總會有失足的時候，結果有一次，從我手裏發出去的光盤母盤，含有病毒殭屍，以至於被迫收回已經推上市場的2萬張光盤，從那之後，我的心臟就開始變得無比堅強，現在就是整個後臺服務都癱瘓了，我也只是微微一笑。其實，一個人身兼架構師和程序員，甚至多種角色，沒什麼不妥，後面還會講這個話題，這種現象不是中國特色，跟國外是完全接軌的。我曾經跟米國的一個工程師在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條：
架構師主要職責有4條：
1、確認需求
在項目開發過程中，架構師是在需求規格說明書完成後介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反覆交流，以保證自己完整並準確地理解用戶需求。
在項目開發過程中，架構師是在需求規格說明書完成後介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反覆交流，以保證自己完整並準確地理解用戶需求。
2、系統分解
依據用戶需求，架構師將系統整體分解爲更小的子系統和組件，從而形成不同的邏輯層或服務。隨後，架構師會確定各層的接口，層與層相互之間的關係。架構師不僅要對整個系統分層，進行“縱向”分解，還要對同一邏輯層分塊，進行“橫向”分解。
軟件架構師的功力基本體現於此，這是一項相對複雜的工作。
依據用戶需求，架構師將系統整體分解爲更小的子系統和組件，從而形成不同的邏輯層或服務。隨後，架構師會確定各層的接口，層與層相互之間的關係。架構師不僅要對整個系統分層，進行“縱向”分解，還要對同一邏輯層分塊，進行“橫向”分解。
軟件架構師的功力基本體現於此，這是一項相對複雜的工作。
3、技術選型
架構師通過對系統的一系列的分解，最終形成了軟件的整體架構。技術選擇主要取決於軟件架構。
Web Server運行在Windows上還是Linux上？數據庫採用MSSql、Oracle還是Mysql？需要不需要採用MVC或者Spring等輕量級的框架？前端採用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，並進行評估。
架構師對產品和技術的選型僅僅限於評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案爲項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。
架構師通過對系統的一系列的分解，最終形成了軟件的整體架構。技術選擇主要取決於軟件架構。
Web Server運行在Windows上還是Linux上？數據庫採用MSSql、Oracle還是Mysql？需要不需要採用MVC或者Spring等輕量級的框架？前端採用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，並進行評估。
架構師對產品和技術的選型僅僅限於評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案爲項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。
4、制定技術規格說明
架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。
架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、理解各自承擔的子系統或者模塊。
架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對於架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。
架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。
架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、理解各自承擔的子系統或者模塊。
架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對於架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。
3.3 架構師的誤區
1、架構師就是項目經理
架構師不是項目經理。項目經理側重於預算控制、時間進度控制、人員管理、與外部聯繫和協調等等工作，具備管理職能。一般小型項目中，常見項目經理兼架構師。
架構師不是項目經理。項目經理側重於預算控制、時間進度控制、人員管理、與外部聯繫和協調等等工作，具備管理職能。一般小型項目中，常見項目經理兼架構師。
2、架構師負責需求分析
架構師不是需求分析員。需求分析人員的工作是收集需求和分析需求，並與最終用戶、產品經理保持聯繫。架構師只對最終的需求審覈和確認，提出需求不清和不完整的部分，他會跟需求分析員時刻保持聯繫。架構師是技術專家，不是業務專家。
架構師不是需求分析員。需求分析人員的工作是收集需求和分析需求，並與最終用戶、產品經理保持聯繫。架構師只對最終的需求審覈和確認，提出需求不清和不完整的部分，他會跟需求分析員時刻保持聯繫。架構師是技術專家，不是業務專家。
3、架構師從來不寫代碼
這是一個尚存爭論的問題。目前有兩種觀點：
觀點1：架構師不寫代碼，寫代碼純體力活，架構師寫代碼大材小用。架構師把UML的各種視圖交給開發人員，如果有不明確的地方，可以與架構師隨時溝通。
觀點2：架構師本來自於程序員，只是比程序員站的層面更高，比程序員唯一多的是經驗和知識，所以架構師也免不了寫代碼。
我個人覺得這兩種說法是與架構師的出身和所處的環境有關。
架構師首先是一個技術角色，所以一定是來自於技術人員這個羣體，比如系統架構師，多是來自於運維人員，可能本身代碼寫得並不多，或者說寫不出來很漂亮的代碼。軟件架構師多是來自於程序員，有着程序員的血統和情懷，所以在項目開發過程中，可能會寫一些核心代碼。我們的理想是架構師不用寫代碼，但事實上有時候過於理想。架構師寫不寫代碼，可能取決於公司的規模、文化、開發人員的素質等現實情況。另外，架構師也不是跟程序員界限分得那麼清楚，按照能力也有高中低之分，寫不寫代碼不是區分兩者的根本標準。
3.4 架構師的基本素質
周星馳有個片子《喜劇之王》，劇中的尹天仇整天揣着本《演員的自我修養》，一個好演員不僅需要天賦，也需要一定的理論指導，無師自通的人畢竟是少數。架構師的成長過程也是這樣。從普通程序員到高級程序員，再到架構師，是一個經驗積累和思想昇華的過程。經驗積累是一個方面，素質培養是另一個方面，兩者相輔相成，所以我覺得有必要把架構師的所要具備的素質羅列一下，作爲程序員努力的方向。
1、溝通能力
爲了提高效率，架構師必須贏得團隊成員、項目經理、客戶或用戶認同，這就需要架構師具有較強的溝通能力。溝通能力是人類最普遍性的素質要求，技術人員好像容易忽略，想成爲架構師就不能忽略。千萬不要抱着這樣的觀念：懷纔跟懷孕似的，時間久了總會被人發現的。還是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式。看看你周圍的頭頭腦腦們，哪一個不是此中高手，我們千萬不要鄙視，認爲這是阿諛奉承、投機鑽營，凡事都要看到積極的一面，“溝通”的確是一種能力。我認爲自己是一個略內向的人，因爲我是農村出來的孩子，普通話都說不好，以前或多或少帶有點自卑感，幻想着是金子總會發光，所以在職業生涯中吃了不少虧。現在，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感覺工作起來順暢多了。
爲了提高效率，架構師必須贏得團隊成員、項目經理、客戶或用戶認同，這就需要架構師具有較強的溝通能力。溝通能力是人類最普遍性的素質要求，技術人員好像容易忽略，想成爲架構師就不能忽略。千萬不要抱着這樣的觀念：懷纔跟懷孕似的，時間久了總會被人發現的。還是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式。看看你周圍的頭頭腦腦們，哪一個不是此中高手，我們千萬不要鄙視，認爲這是阿諛奉承、投機鑽營，凡事都要看到積極的一面，“溝通”的確是一種能力。我認爲自己是一個略內向的人，因爲我是農村出來的孩子，普通話都說不好，以前或多或少帶有點自卑感，幻想着是金子總會發光，所以在職業生涯中吃了不少虧。現在，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感覺工作起來順暢多了。
這一條我認爲最爲重要，所以排在首位。我甚至認爲下面幾條都可以忽略，唯一這一條得牢記，而且要常常提醒自己。
2、領導能力
架構師能夠推動整個團隊的技術進展，能在壓力下作出關鍵性的決策，並將其貫徹到底。架構師如何來保證這種執行力？這就需要架構師具有領導能力。
架構師能夠推動整個團隊的技術進展，能在壓力下作出關鍵性的決策，並將其貫徹到底。架構師如何來保證這種執行力？這就需要架構師具有領導能力。
架構師的領導能力的取得跟項目經理不太一樣。項目經理主要負責解決行政管理，這種能力與技術關係不大，他有人權和財權，再扯上一張“領導”的虎皮，採用“胡蘿蔔加大棒”的方式，基本上可以保證執行力。架構師在項目裏面可能更多地使用非正式的領導力，也就是我們常說的影響力，裏面包括個人魅力、技術能力、知識傳遞等等。
3、抽象思維和分析能力
架構師必須具備抽象思維和分析的能力，這是你進行系統分析和系統分解的基本素質。只有具備這樣的能力，架構師才能看清系統的整體，掌控全局，這也是架構師大局觀的形成基礎。你如何具備這種能力呢？一是來自於經驗，二是來自於學習。架構師不僅要具備在問題領域上的經驗，也需要具備在軟件工程領域內的經驗。也就是說，架構師必須能夠準確得理解需求，然後用軟件工程的思想，把需求轉化和分解成可用計算機語言實現的程度。經驗的積累是需要一個時間過程的，這個過程誰也幫不了你，是需要你去經歷的。但是，如果你有意識地去培養，不斷吸取前人的經驗的話，還是可以縮短這個週期的。這也是我寫作此係列的始動力之一。
架構師必須具備抽象思維和分析的能力，這是你進行系統分析和系統分解的基本素質。只有具備這樣的能力，架構師才能看清系統的整體，掌控全局，這也是架構師大局觀的形成基礎。你如何具備這種能力呢？一是來自於經驗，二是來自於學習。架構師不僅要具備在問題領域上的經驗，也需要具備在軟件工程領域內的經驗。也就是說，架構師必須能夠準確得理解需求，然後用軟件工程的思想，把需求轉化和分解成可用計算機語言實現的程度。經驗的積累是需要一個時間過程的，這個過程誰也幫不了你，是需要你去經歷的。但是，如果你有意識地去培養，不斷吸取前人的經驗的話，還是可以縮短這個週期的。這也是我寫作此係列的始動力之一。
4、技術深度和廣度
架構師最好精通1-2個技術，具備這種技術能力可以更加深入的理解有關架構的工作原理，也可以拉近和開發人員的距離，並形成團隊中的影響力。
架構師的技術知識廣度也很重要，需要了解儘可能多的技術，所謂見多識廣，只有這樣，纔可能綜合各種技術，選擇更加適合項目的解決方案。有的人說，架構師技術廣度的要求高於技術深度的要求，這是很有道理的。
總而言之，一句話：架構師是項目團隊中的技術權威。
總而言之，一句話：架構師是項目團隊中的技術權威。
面向過程和麪向對象這兩個基本概念，不僅架構師需要非常清楚，程序員、設計師也要非常清楚，這也是系統分析、設計和編碼最基本的常識。我接觸的程序員，很多人只停留在一種“似是而非”的程度，這是不行的，想要繼續前進，就得把基礎夯實，所以我覺得很有必要先回回爐，補補課。
---------------------------------------------------------------------------------------------------
後記：在講面向對象之前寫了這麼一篇，主要就是要把前面漏下的功課補上。
---------------------------------------------------------------------------------------------------
後記：在講面向對象之前寫了這麼一篇，主要就是要把前面漏下的功課補上。