我是怎樣成長爲系統架構師的

 

 

來這家公司從事信息化工做已經也有三個年頭了，有必要對這三年的工做和成長以及不足之處作一個總結。在此以前，從2001年開始學習JAVA，那時候用Struts的開發的企業也很少，而我在的作項目的企業當時已經本身開發了Struts的高速開發平臺，專門作對日軟件外包的項目，在這家公司工做，培養了我JAVA基礎知識，軟件project的認識以及項目管理的知識。隨後博士畢業後去了一家外企作了4年的IT系統集成研究，主要用Eclipse Plugin搭建研究項目的驗證的Prototype，期間研究了SOA，SSH，LDAP，Web服務發現等技術。

 

剛來這家公司的時候，領導決策要將系統作重建開發。項目的詳細狀況是：咱們擁有了成熟的業務功能，僅僅要將老的系統的功能照搬到新的系統中，所以，對於老的系統進行了一次整理和分析，分析了合理的地方，也分析了不合理的地方，不合理的地方，但願在新系統中進行改進，但原則上，數據庫表結構不作大的修改，以避免將給未來系統遷移帶來重大困難。固然，由於隨着企業的業務的發展，會有新的需求，但大部分的需求都是沒有改變的。

在項目的成員實力方面，沒有的是：

1.熟悉JAVA的開發者。

2.J2EE項目的經驗。

有的是：

1.IT項目的開發、測試和維護經驗。

2.數據庫系統開發經驗。（事實上很是重要的，數據庫系統對於企業應用來講，數據也是很是關鍵的，擁有這樣面的經驗，爲項目的興許開發提供了很多的經驗支持）

在項目的初期階段還碰到了技術選型的問題，依據應用的特色，終於選擇了C/S三層結構，並選用標準的EJB 3.0做爲中間層，採用成熟的商用中間件server，這樣就攻克了ORM，數據持久化等問題，這樣便肯定了技術方向，這對於沒有經驗的團隊來講，也是艱難的。

上述即是我團隊的狀況的簡要概況。項目老是要作的，因爲領導決策了啊。先看上述兩個問題咱們是怎樣解決的。

1.針對開發團隊沒有JAVA的開發經驗，進行培訓，由我親自操刀。培訓爲期15天，從開發環境熟悉，到JAVA基礎知識，上午半天講知識，下午上機練習。

2.針對沒有J2EE的項目經驗。

整個項目就我一我的有過J2EE的項目經驗，但是我曾經沒有作過J2EE項目的架構師至少沒有作過如此大型項目的，我僅僅是作過J2EE項目的開發（B/S的，而本次項目是client）並瞭解軟件project、面向對象的設計、設計模式等。怎麼辦？咱們是這樣解決的，請老師。專門請了老師來說架構設計知識。這還不夠，咱們花錢請人作架構設計。但僅僅是作架構設計，生成一個架構說明書後，離架構的工做還很是遠，還有很是長的路要走，而在合做公司作好架構設計後，他們的工做也就基本結束了。後面的架構方面的工做，基本上是由我來作的。我說說我都作了什麼事情。

（1）依照架構說明書，將整個架構環境搭建起來。

（2）開發一套便於開發者開發的開發框架。

（3）設計了Swing的MVC模式，並開發實現。

（4）開發了整個系統的基礎組件，爲了實現架構中的複用的原則，這個很是重要。

（5）負責整個系統的權限的管理，這個很是重要，跟各個模塊都有關係。

（6）負責開發的編碼規範的制定，包含JAVA的編碼的規範，同一時候還有質量屬性方面的編碼的規範。

（7）整個系統的異常處理、日誌、錯誤驗證等機制的設計和開發；

（8）第三方系統和工具的集成，如報表系統，瀏覽工具的集成等；

上述，僅僅有（1）是現成的。其餘的都是詳細的架構方面的工做。很是多人，都覺得，架構師嘛，不就是高高在上的，待在象牙塔裏給開發者發號施令的人嗎？事實上否則，架構師需要天天跟開發者在一塊兒，一塊兒寫代碼，一塊兒工做，一塊兒交流。

回想起，在搭建高速開發框架的過程當中，開發者在開發的過程當中，提出了很是多有意義的改進的意見，直到今時今日，咱們還在改進，僅僅有開明的架構師，才能夠設計出好的系統，好的基礎組件。固然沒有意義的，也被篩選掉的，架構師必須要有這種決斷力。

Swing的MVC模式就不說了，可能每個團隊對於該項設計都會有所不一樣。

說說怎樣實現組件的複用，要實現組件的複用，必須要鼓舞開發者複用已有的組件以統一界面風格以及下降工做量。那麼，就要告訴開發者，眼下咱們的系統有哪些基礎組件，他們都是怎麼樣使用或調用的。有了這些，開發者天然就肯用了。

關於編碼規範，可能很是多人認爲這是項目開發中的小事情，事實上否則，某位架構大師說過，架構無小事，編碼規範的運行不力，直接影響到整個項目的代碼質量，甚至影響質量。好比，要求不要出現在循環，要釋放對象，儘可能用StringBuffer等。在編碼規範的運行的難度是，不是說你有沒有規範，而是你的規範有沒有被運行。那麼怎樣使得你的規範被運行呢？

這就需要架構師的耐心和溝通能力了。在整個項目的開發過程當中，架構師始終要保持與開發者的溝通，苦口婆心地說，編碼規範的重要性。時間長了，開發者養成了好的習慣，架構師也就省心了。

依據上述經驗，我作個總結。

1.經驗是可以複製的，當您沒有這方面的人員時，最好請求專業或外援，並培養本身的人員，同一時候有吸取的學習。

2.架構師是整個團隊的技術領導，需要具有領導能力。

3.架構師需要較強的溝通能力，需要與項目的各個方面的人員進行溝通，與項目經理溝通，幫助項目經理制定合理的開發計劃；與需求分析員溝通，瞭解系統的關鍵需求和非功能性需求；與開發者溝通，使得架構設計能夠被真正運行；另外還有與項目經理、物理架構負責人溝通等等。

4.架構師需要編寫代碼，這樣使本身積累不少其它的代碼經驗，加深理解設計模式，能夠幫助本身對於整個項目更加熟悉，同一時候能夠回答開發者在開發過程當中出現的所有的問題，樹立我的威信。

5.架構師須要有較強的IT知識和廣博的知識面。IT的知識更新很快，現在雲計算等的出現，一定要淘汰一部分架構師，所以，架構師要保持生命力，必須要不斷地學習。

6.架構師要懂業務知識。架構設計要知足系統的需求。我儘管剛到公司不久，但由於以前積累了很是多業務相關的知識，通過短時間的學習，也掌握了業務知識。

7.不要怕作事情，我在整個系統的開發過程當中，個人開發量是別人的三倍還多，但我收穫的，則也是三倍還多的經驗。

 

 本身的不足之處：

1.有時候會着急，當規範強調了10遍，仍是沒有獲得很是好的運行時，就開始沒有耐心了。

2.需要增強溝通能力，將本身的想法能夠推銷出去。

3.需要在不少其它的業務領域知識方面獲得高速的增加。

 

下一步的目標

 

1.系統理論地學習架構知識，使得知識更加固化，以進一步使得架構設計更加科學和有調理；

2.經過普遍地閱讀學習企業信息化的各個方面的知識，包含ERP，SCM，營銷管理，企業戰略，企業管理等，每一年看書或閱讀文章至少100本或篇；

3.熟悉企業的業務流程，與企業不一樣層次的人員多多地進行交流，多學習，多溝通；

4.多交朋友，多向朋友學習與交流。

張