邁向系統架構師

編者按：系統架構師是許多程序員的夢想職業。今天的你也許已經掌握了各種開發工具，并且能夠使用各種平臺進行開發，但作為一個架構師的要求，也許還有很長的道路。邢波濤先生在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 開發。

?