九妹帶你走向 架構師

邁向系統架構師

編者按：系統架構師是許多程序員的夢想職業。今天的你也許已經掌握了各類開發工具，而且可以使用各類平臺進行開發，但做爲一個架構師的要求，也許還有很長的道路。邢波濤先生在LAMP架構上的造詣，讓我邀請他撰寫本文，也許這位架構師的建議能讓你在將來的架構師之路上節省一點時間。

一個產品的經典開發步驟一般須要通過系統需求調研、系統分析、系統設計、開發、測試、部署實施等一系列的步驟，以下圖所示：

而系統架構師，則在這個過程當中，起到了承上（面對業務專家/系統分析員）和啓下（面對軟件工程師）的做用。因此說，系統架構師，在整個產品開發週期內是一個核心角色。若是說市場和銷售決定一個產品是否好賣的話，系統架構師則直接決定着這個產品的開發是否成功。從某種意義上說，這也是衆多程序員將來的夢想職業。

要想成爲一個優秀的系統架構師，並不是一朝一夕之功所能達到的，「冰凍三尺，非一日之寒」，除了要有很深的專業技能外，還需技術全面、成熟練達、洞察力強、經驗豐富，具有戰略性和前瞻性思惟能力，善於把握全局，可以在更高抽象級別上進行思考。若是說系統分析員、業務專家只須要對一個產品的業務負責，能夠不關心一個產品軟件開發語言的話，而一個優秀的職業系統架構師，不只要對產品背景和產品背後的業務邏輯熟悉，並且要對所用的軟件開發語言（例如Java/C#/C/C++/J2EE），也要很是熟悉才能夠，二者缺一不可。不然就起不到承上啓下的做用，固然也設計不出良好的軟件架構。在美國，一個合格的系統架構師的薪水甚至比部門經理或產品經理要高不少，這也是美國爲何三四十歲甚至五十歲的程序員也很常見的緣由。

事實上，軟件開發中碰到的不少問題，歸結起來均可能和當初的架構設計有關，因此架構師要想不成爲衆矢之的，決不是件容易的事情。基於此，我認爲，要想成爲合格的系統架構師，首先要從程序員作起，只有有了多年的一線軟件開發經驗，深入體會到了程序員的艱辛與不容易，才能設計出易於擴展、易於修改、易於維護、「不難爲」程序員的架構出來。一個系統架構師，首先要能作出可以「自圓其說」的原型，才能跟程序員進行有效的溝通，而不是隻是設計出來一個架構，就徹底交給程序員來作了，這樣，後期開發出來的產品風險很大。以我如今參與開發的產品爲例，這個產品只是公司核心戰略產品的很小的一部分，固然，雖然小，倒是核心中的核心。這個產品配了3個系統架構師（年齡都在40歲以上，有數十年的軟件開發經驗），6個程序員、5個測試，還有一個負責產品打包的工程師。這3個系統架構師也都參與核心代碼編寫。

其次，合格的系統架構師，對所要開發的產品的業務背景，也要至關的熟悉纔好，不然，設計出來的產品就不是客戶想要的產品，固然也就不是成功的產品。仍是以我如今參與的產品爲例，這個產品是SCA規範的一個實現，3個系統架構師的其中一個，就是SCA標準規範的參與者與制定者，對SOA/SCA標準，有着至關的功底，不然，作出來的產品，就只能圍着大公司，在他們屁股後面每天追了，別人作什麼，本身也作什麼，別人標準修改了，本身也趕快跟着修改。

第三，做爲系統架構師，要常常閱讀一些關於產品背景資料和系統架構設計方面的最新書籍。雖然如今技術方面的書籍，出得太濫，精品極少，大部分是從網上抄襲一些資料攢出來的，可是常常閱讀一些國外大師的一些精品圖書，仍是能給本身帶來一些新的思路和設計理念的。

第四，做爲系統架構師，必定要有自信，既不要保守，也不要人云亦云，千萬不要迷信於大師和大俠。別人說J2EE好，本身的產品就基於J2EE開發；別人說.NET容易開發，開發成本低，就轉作.NET；別人說Ruby很敏捷，本身就說本身的產品是基於ROR開發的。必定要結合公司、市場和項目的實際狀況，採用合適於本身的開發語言，設計出合適於本身的架構。好比，《J2EEWithoutEJB》那本書，提出了著名的「不要造新輪子」原則。若是你們都不要造輪子，都利用別人現有的框架和產品，怎麼可能有技術的進步和百花齊放、欣欣向榮的景象呢？Spring的做者還不是看到經典J2EEEJB框架的詬病，才設計出來本身的Spring輪子了嗎，爲何本身有了Spring輪子，就勸別人不要另造輪子了呢？GavinKing造出來了Hibenate這個輪子，爲何又參與EJB3.0的制定呢？並又參與設計出Seam這個輪子？我我的以爲，一個系統架構師，必定要造出本身的輪子，纔算是真正的系統架構師，而不是拿着一大堆開源框架進行拼湊。

第五，對於開源的架構設計，要批判性地繼承。要多閱讀這些框架的源代碼。以J2EE和Eclipse插件開發爲例（由於我專一於這兩個方面的開發），從前些年流行EJB,再到Struts→J2EEwithoutEJB→Spring/Hibernate→AJAX，每個框架的流行，都有其深入的歷史背景，有一些現有框架解決不了的難題在裏面，這些框架都是爲了解決一些問題而出現的。咱們常常閱讀這些大師的源代碼，精神上是一種享受，對錘鍊本身的功底，也是大有好處的。例如，在作Eclipse插件開發的時候，經常會遇到一個問題，怎麼才能監聽到用戶保存的事件，雖然Eclipse提供了資源變化監聽機制，可是直接利用其機制，是很原始的，任何資源的變化，好比，添加/刪除/移動一個圖形，都會引發這個事件的調用，而我只想監聽用戶存盤的一剎那那個事件，之前在作項目的時候，想盡各類辦法也沒解決好。後來，在另一個產品的源代碼中，就看到了別人很好的解決方案，本身看到那段源代碼，真的是領悟到不少。有時候，Eclipse的源代碼和J2EE的源代碼，在架構上是能夠互相借鑑和補充的。好比，Eclipse的Adapter擴展機制和事件、資源監聽機制，咱們同樣能夠拿到J2EE框架中來，做爲設計本身產品的設計模式藍圖。

第六，優秀的系統架構師還要擁有優秀的溝通能力，用以進行說服、鼓勵和指導等活動，並贏得項目組成員的信任。一個系統架構師設計出一個良好的框架後，若是不能跟程序員進行有效的溝通，不能對程序員進行良好的指導，則這個良好的框架就不能很好的貫徹到產品開發的每一個環節中去。有的程序員可能仍是按照老經驗對程序中的一些關鍵環節進行處理，等到這個架構師發現問題時，可能已經很晚了，說服、教育、培訓和處罰到那時已經沒有意義了。另外，若是一個系統架構師不能贏得項目組成員信任的話，那麼他設計出來的架構就不具有說服力，程序員遇到困難，就會抱怨系統架構師設計的框架有問題，不能充分調動起來程序員的責任感和主觀能動性。因此說，一個優秀的系統架構師，不管在精神上，仍是技能上，都是一個程序員良好的導師。

第七，系統架構師要分清本身和系統分析員、項目經理或產品經理之間的角色和關係，不能負責一切，也不能只負責技術架構。因爲系統架構師在整個產品開發週期內處於承上啓下的中間地位，和程序員打交道的時間比系統分析員面向程序員的時間要長，有時候甚至比項目經理和程序員之間還熟悉，使得程序員很容易認爲系統架構師對全部的需求和架構都負責，容易形成系統架構師職責太重。

成爲優秀系統架構師的路，是一條漫長而任重道遠的路。在這條道路上，要不斷說服本身，不斷抵制各類誘惑，要能在深夜無人的時候，挑燈閱讀別人的源代碼，還要有承受住各類壓力的能力，能跟項目經理一塊兒抵制住老闆的無理工期要求，還要在困難的時候，鼓勵項目組成員一塊兒渡過難關。總之一句話，要想成爲系統架構師，不是很容易。「路漫漫其修遠兮，吾將上下而求索」。

做者簡介：

邢波濤，11 年軟件開發和管理經驗，7 年的J2EE 開發經驗， 資深J2EE 專家。對JSP/ Servlet /JavaBean/EJB 技術有深入瞭解。熟悉Oracle、MS SQL Server、DB2，對Eclipse 平臺開發，基於SWT/GEF/EMF 的Eclipse 插件開發有深刻的實踐基礎。此外，熟悉UML、Rational Rose/ Rational Software Architecture 等面向對象分析技術和工具，熟悉WBI Modeler 等業務建模工具，從事過MDA/MDD 開發。