架構師修鍊之路

標籤：java   使用   問題   javascript   工作   代碼   

國內我們對架構師，專案經理，開發經理或者是技術總監這類職業定位普遍不都不清晰，很多的情況是“能者多勞”，一人身兼數職。達爾文的理論在我們的行業是絕對適用的，我從進入這個行業開始我就不甘於成為淘汰者，而我也由心地熱愛著這個行業很年前我就立志要成為架構師（當年流行叫：系統分析員 ）這目標進發。回首這10幾年的磨練，我總結了一下一名合格的架構師應該具備哪一些方面的能力以及怎麼才能得到這些能力

編碼能力

    架構師是一個職業，是一種經曆了各種磨練與長年開發經驗積累出來的。另外我一直認為：不會編碼的架構師不是一個好的架構師。我見過很多所謂的架構師完全不懂編碼，但總喜歡拿著架構說事。但從嚴格來說他們並不屬於“軟體架構師”的範疇，充其量只能算是個“系統架構設計師”，遇到這樣的”架構師“我總喜歡說一句話：”Don’t tell me the concepts show me the code!“。

    不參與編碼並不代表不會編碼，如果沒有過硬的開發基礎，巨量的編碼時間積累為基礎，在設計軟體時一定會忽略非常多的細節，而這將會直接影響到整個項目的成敗，試想想當專案經理按照架構師設計的軟體藍圖訂製開發計劃與安排項目資源時由於“藍圖”記憶體有大量未確定的風險因素，以及由風險觸發後所帶來的不可預知的結果，最後項目是否能成功 ？

 

• 多看 - 多看別人的代碼，從別人的代碼中讀出軟體的架構與設計的設計思路
• 多學 - 掌握各種語言，不要偏執於某一技術陣形，不管java, .net , phyon 還是javascript每種語言都有其優缺點，成為一名語言控，從語言本身學習與理解語言設計者的思想。
• 多做 -  瘋狂編碼，從時間與實踐中去體驗與領悟，工多藝熟。
• 勇敢 - 嚴格要求自己不要寫出”發臭“的東西，勇敢地重構！讓代碼變得優雅，易讀充滿你的設計思想。

 

表達力

世界上最難的兩件事是：將別人口袋的錢放到自己的口袋裡面；將自己腦子的想法完整放到別人的腦子裡面。

我認為一份成功的設計是 ”能讓不同層面的人都能看得懂“。為什麼這樣說？那麼得瞭解誰需要看設計，又是出於何目的來看設計。

• 銷       售 - 從設計中尋找賣點與特色，豐富銷售方案和定製預售計劃。
• 專案經理 - 根據設計進行時間估算、項目資源準備與工作分解。
• 開       發 - 根據設計要求進行技術準備、開發環境、編寫DEMO以及最終編碼 。 
• 測       試 - 根據設計劃分測試粒度、準備測試環境、定製測試計劃 

 

不同的開發方法與開發流程都會有不同的設計文檔要求，而受眾無非也是上述幾種。作為項目/軟體的設計者，能清晰地向受眾準確地傳達自己的設計思路就顯得極其重要。這裡指表達不是指嘴上的功底，更多的是在工具的掌握能力與文字的表達能力。使用不同的工具表達向不同的受從表達相同的理念，這基實是對架構設計的一種驗證，這種溝通與表達能有效地融合不同角度的觀點，也能讓架構師能更深入地理解自己的設計方向。

 

要面對如此多的複雜性應該如何來鍛煉自己的表達性呢？

1. 多與人溝通，多參與頭腦風暴
2. 練慣用人類語言表達“非人類”的專業知識。一張用鉛筆畫的框圖往往比一個使用專業UML設計工具做出來的設計更容易讓人理解。 UML為作架構師基本上是必修課，也是輔助架構師思維的工具，但對於不懂UML的那就是“非人類”的文檔，設計是給人看的，別人看不懂再專業再標準化的設計也只能淪為廢紙。
3. 培養測試先行的習慣 - 在設計時多寫範例與測試，在很大程度上可以減少設計誤區和驗證被實現的可行性。這樣可以在將設計交付給開發、測試後節約大量的溝通時間。

 

擁抱變化

正如XP（極端編程）中所說：“世界上唯一不變的就是變化”。擁抱變化、預測變化、控制變化不單純是優秀開發人員的和專案經理的要求同樣也是架構師一種重要的能力。

“變” 

     我的理解 設計中的“變” 就是 “可定製化” 的要求，可定製化程度越高系統/項目的可擴充性就越強。架構師就是需要鍛煉的是控制這種變化的範圍與程度，“變”是雙刃劍，允許過多的變化就會造成“過度設計”，出現一大堆“未來可能使用的功能”；過於封閉則會變得僵化難以適應新的要求。 

“不變”

這裡所說的“不變”也只是相對而然，在系統/項目中相對不變的就應該是“核心”或者是“基礎架構”，舉最簡單的例子就是 .net framework 就是其中一者，雖然它會不斷髮展，增強功能。但其基礎核心設計理念與架構也從來沒有發生過質的改變。更具體的一點來說“不變”的是規則、用法和基礎設計理念。

 

我認為學習控制變化的最佳方法是多看出色的類庫或系統，多問為什麼這樣做，理解原設計師的想法。經過一定時間的積累，隨著對“變化”觀察的增多，自然而然會在自已的設計中按設計要求將”變“與”不變“應用得當。

 

方法論 

針對架構設計的方法論眾多，應該如何選擇？我也讀過很多的相關書籍，我只選最實用的，這裡我推薦幾本書。

• 《設計模式》- 要讀懂、活用，我讀了10幾年每次都可以從中學到不一樣的想法,將其應用於架構內可以極大地簡化很多複雜的問題。
• 《Java 編程思想》 - 談物件導向方面最好的其中一本書，提高物件導向的設計能力會有很大協助
• 《Refactoring》- 重構不單單是一種做法和程式員才關心的事。重構重於意識與思維完全可以用於架構設計 。
• 《eXtreme Programming》- 雖然討論的是開發方法，但它最能詮釋什麼是”變化“。

方法論的實踐與應用也需要時間磨合并融會貫通，它們給予我們更多的是理念與意識，一定要避免走進為實踐方法論而設計的誤區。

 

成為架構師的路子我相信還有許許多多，我相信相同的是每位架構師都需要通過長時間的學習、實踐、思考而也且也擁有一顆熱愛軟體心。