從2001年開始學習JAVA，那時候用Struts的開發的企業也不多，而我在的做項目的企業當時已經自己開發了Struts的快速開發平臺，專門做對日軟件外包的項目，在這家公司工作，培養了我JAVA基礎知識，軟件工程的認識以及項目管理的知識。隨後博士畢業後去了一家外企做了4年的IT系統集成研究，主要用Eclipse Plugin搭建研究項目的驗證的Prototype，期間研究了SOA，SSH，LDAP，Web服務發現等技術。
剛來這家公司的時候，領導決策要將系統做重建開發。項目的具體情況是：我們擁有了成熟的業務功能，只要將老的系統的功能照搬到新的系統中，因此，對於老的系統進行了一次整理和分析，分析了合理的地方，也分析了不合理的地方，不合理的地方，希望在新系統中進行改進，但原則上，數據庫表結構不做大的改動，以免將給將來系統遷移帶來重大困難。當然，由於隨著企業的業務的發展，會有新的需求，但大部分的需求都是沒有改變的。
在項目的成員實力方面，沒有的是：
- 熟悉JAVA的開發人員。
- J2EE項目的經驗。
有的是：
- IT項目的開發、測試和維護經驗。
- 數據庫系統開發經驗。（其實很重要的，數據庫系統對於企業應用來說，數據也是很關鍵的，擁有這樣面的經驗，為項目的後續開發提供了不少的經驗支持）
在項目的初期階段還碰到了技術選型的問題，根據應用的特點，最終選擇了C/S三層結構，並選用標準的EJB 3.0作為中間層，採用成熟的商用中間件服務器，這樣就解決了ORM，數據持久化等問題，這樣便確定了技術方向，這對於沒有經驗的團隊來說，也是艱難的。
上述便是我團隊的情況的簡要概況。項目總是要做的，因為領導決策了啊。先看上述兩個問題我們是如何解決的。
- 針對開發團隊沒有JAVA的開發經驗，進行培訓，由我親自操刀。培訓為期15天，從開發環境熟悉，到JAVA基礎知識，上午半天講知識，下午上機練習。
- 針對沒有J2EE的項目經驗。
整個項目就我一個人有過J2EE的項目經驗，但是我以前沒有做過J2EE項目的架構師至少沒有做過如此大型項目的，我只是做過J2EE項目的開發（B/S的，而本次項目是客戶端）並瞭解軟件工程、面向對象的設計、設計模式等。怎麼辦？我們是這樣解決的，請老師。專門請了老師來講架構設計知識。這還不夠，我們花錢請人做架構設計。但只是做架構設計，生成一個架構說明書後，離架構的工作還很遠，還有很長的路要走，而在合作公司做好架構設計後，他們的工作也就基本結束了。後面的架構方面的工作，基本上是由我來做的。我說說我都做了什麼事情。
- 按照架構說明書，將整個架構環境搭建起來
- 開發一套便於開發人員開發的開發框架
- 設計了Swing的MVC模式，並開發實現
- 開發了整個系統的基礎組件，為了實現架構中的複用的原則，這個很重要
- 負責整個系統的權限的管理，這個很重要，跟各個模塊都有關係
- 負責開發的編碼規範的制定，包括JAVA的編碼的規範，同時還有質量屬性方面的編碼的規範
- 整個系統的異常處理、日誌、錯誤驗證等機制的設計和開發
- 第三方系統和工具的集成，如報表系統，瀏覽工具的集成等
上述，只有（1）是現成的。其它的都是具體的架構方面的工作。很多人，都以為，架構師嘛，不就是高高在上的，待在象牙塔裡給開發人員發號施令的人嗎？其實不然，架構師需要每天跟開發人員在一起，一起寫代碼，一起工作，一起交流。
回顧起，在搭建快速開發框架的過程中，開發人員在開發的過程中，提出了很多有意義的改進的意見，直到今時今日，我們還在改進，只有開明的架構師，才能夠設計出好的系統，好的基礎組件。當然沒有意義的，也被篩選掉的，架構師必須要有這樣的決斷力。
Swing的MVC模式就不說了，可能每個團隊對於該項設計都會有所不同。
說說如何實現組件的複用，要實現組件的複用，必須要鼓勵開發人員複用已有的組件以統一界面風格以及減少工作量。那麼，就要告訴開發人員，目前我們的系統有哪些基礎組件，他們都是怎麼樣使用或調用的。有了這些，開發人員自然就肯用了。
關於編碼規範，可能很多人覺得這是項目開發中的小事情，其實不然，某位架構大師說過，架構無小事，編碼規範的執行不力，直接影響到整個項目的代碼質量，甚至影響質量。例如，要求不要出現在循環，要釋放對象，儘量用StringBuffer等。在編碼規範的執行的難度是，不是說你有沒有規範，而是你的規範有沒有被執行。那麼如何使得你的規範被執行呢？
這就需要架構師的耐心和溝通能力了。在整個項目的開發過程中，架構師始終要保持與開發人員的溝通，苦口婆心地說，編碼規範的重要性。時間長了，開發人員養成了好的習慣，架構師也就省心了。
總結
- 經驗是可以複製的，當您沒有這方面的人員時，最好請求專業或外援，並培養自己的人員，同時有吸收的學習。
- 架構師是整個團隊的技術領導，需要具備領導能力。
- 架構師需要較強的溝通能力，需要與項目的各個方面的人員進行溝通，與項目經理溝通，幫助項目經理制定合理的開發計劃；與需求分析員溝通，瞭解系統的關鍵需求和非功能性需求；與開發人員溝通，使得架構設計能夠被真正執行；另外還有與項目經理、物理架構負責人溝通等等。
- 架構師需要編寫代碼，這樣使自己積累更多的代碼經驗，加深理解設計模式，可以幫助自己對於整個項目更加熟悉，同時能夠回答開發人員在開發過程中出現的所有的問題，樹立個人威信。
- 架構師需要有較強的IT知識和廣博的知識面。IT的知識更新非常快，現在雲計算等的出現，必然要淘汰一部分架構師，因此，架構師要保持生命力，必須要不斷地學習。
- 架構師要懂業務知識。架構設計要滿足系統的需求。我雖然剛到公司不久，但由於之前積累了很多業務相關的知識，經過短期的學習，也掌握了業務知識。
- 不要怕做事情，我在整個系統的開發過程中，我的開發量是別人的三倍還多，但我收穫的，則也是三倍還多的經驗。
這張圖從架構師的綜合能力、崗位認識、崗位職責等方面，清楚的畫出了作為一個架構的基本準則。
人人都想成為架構師，可作為架構你達到了上面的要求了嗎？
無論怎麼分，作為一個架構師，你必須具備以下幾個特性。
- 技術能力
技術能力，不用置疑肯定是最重要的。技術能力弱的架構不是一個好架構。所以，你需要知道所有主流技術的基本原理、應用場景，及快速解決問題的能力。
所以，架構師必須要有見識，所需知識面肯定是要不斷拓展的。你需要清楚在什麼樣的場景用什麼樣的技術比較合適，並知道可能存在什麼樣的風險。來了需求，你腦袋是空的，不知道用什麼技術這是最可怕的。
- 架構能力
這個可以表現為抽象能力、整體規劃能力、及設計能力。你需要照在業務的角度進行系統分解、技術選型、架構搭建，以及規範制定。架構出來了至少可以滿足近幾年的發展，或者可以很方便對現有架構進行擴容。
有人說架構不需要懂業務，我面試過的就有明確表示不做業務架構。當然有方面的架構師，如中間件架構師，運維基礎設施架構師等。但一般的後端架構師都是需要了解業務，不理解業務你如果進行系統分解，服務劃分，及根據不同業務作出不同的架構？
技術都是為業務服務的，不站在業務的角度設計架構，那架構就是空談。
- 溝通能力
這個看起來不是最重要的，其實也非常重要。作為一個優秀的架構師，你需要清楚的知道客戶的需求，需要不斷和需求人員進行溝通，以達到客戶真正的目的。
不論是不是架構師，任何一個職場人，提高自己的溝通表達能力無疑是不可或缺的。有一句話怎麼說的，領導就喜歡拍馬屁的。做領導的大多不是技術特別牛的，但溝通能力肯定是一流的。
這3點肯定是架構師的核心，但不一定是每個架構師的標準。
國內做程序員，30歲左右就得轉型，不然就會被嫌棄。不管是不是如此，大環境就是這樣，程序員你能幹到35已見天花板。
所以，程序員必須轉型，管理職位數量有限，對性格、溝通表達能力有要求。所以轉型架構師是首選，大家一起加油吧。
那如何學習才能快速入門並精通呢？
當真正開始學習的時候難免不知道從哪入手，導致效率低下影響繼續學習的信心。
但最重要的是不知道哪些技術需要重點掌握，學習時頻繁踩坑，最終浪費大量時間，所以有一套實用的視頻課程用來跟著學習是非常有必要的。
為了讓學習變得輕鬆、高效，今天給大家免費分享一套阿里架構師傳授的一套教學資源。幫助大家在成為架構師的道路上披荊斬棘。
這套視頻課程詳細講解了（Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構）等這些成為架構師必備的內容！
而且還把框架需要用到的各種程序進行了打包，根據基礎視頻可以讓你輕鬆搭建分佈式框架環境，像在企業生產環境一樣進行學習和實踐。
後臺私信回覆“架構” 就可以馬上免費獲得這套價值一萬八的內部教材！
最後，做一個愛思考，懂思考，會思考的程序員。
閱讀更多 Java高級架構資訊 的文章
