NET架構師的思索

      我們看微軟的DotNet開發絕對是屬於那種入門容易提高難的技術。而要能夠成爲DotNet架構師沒有三年或更長時間的編碼積累基本上是不可能的。特別是在大型軟件項目中，架構師是項目核心成員，承上啓下，因此 RUP{Rational Unified Process,強調軟件開發是一個疊代模型Interative Model），RUP定義了四個階段（Phase）：開端（Inception），闡述（Elaboration），建造（Construction），過渡（Transition）}方法論也認同以架構爲核心，體現4+1視圖在整個軟件開發過程中的重要作用。架構人員既要精通技術，又要熟悉業務，而且基本對軟件生命週期各階段的相關技術都需要有相關的積累和知識儲備，而這些不經過多年的磨練是很難達到這個高度的。 
      
      要成爲一個合格的架構師首先必須是一個合格或優秀的編碼人員，對於開發來講編碼始終都是最重要的一項技能，在編碼過程中只要自己善於去思考和分析問題，就可以多學到很多相關的知識和技術。所以我們在開發過程中一定要注意新知識和新技術的學習，前人經驗和成果的學習。編碼過程中應該去思考的一些問題有： 
      
      1.在編碼過程中自己是否做單元測試，是否使用相關工具做單元測試，如果沒有的話是什麼原因無法把單元測試做起來？ 
      2.自己編碼的泄露率情況，編碼泄露的BUG的原因分析 
      3.是否有意識的對代碼進行重構，重構過程中是否引入了相關設計模式的思想？ 
      4.是否對C#語言的一些高級特性進行學習，如反射調用，異步處理等。 
      5.是否對Remoting和WebService兩種分佈式技術做過研究和對比分析？ 
      6.是否經常研究開源項目和開源代碼，如Duwamish，PetShop，NUnit,Enterprise Library，Nant等 
      7.是否對對象持久化機制和O/R Mapping等相關技術做過相關的研究 
      8.平時在編碼過程中是否注重公用組件和公用類的複用和抽取 
      9.自己在平時工作和學習中是否經常開發些小工具提高工作效率，鞏固學習知識 
      
      設計和編碼其實是密切而不可分的，對於嚴格將設計和編碼分開的瀑布模型一般也僅僅在大型項目中應用。而及時編碼和設計分離，也不是將編碼人員不需要思考，編碼活動始終是一項創造性的勞動，如果否定這個觀點那就代表編碼過程完全不需要人員介入而可以完全自動化。因此在這裏談設計主要還是指設計人員的系統化思維能力，設計人員應該比開發人員站高一個層次來分析和思考問題。設計人員最重要的一個技能就是現實- >抽象的轉換，而這個就需要談到方法論的問題了，技術人員需要積累面對對象分析和設計或結構化分析知識的積累，需要有較強的數據庫分析和設計能力。一個設計能否成爲很好的架構師關鍵就在這種積累的深度和廣度上面了。 
      
      因此在設計過程中應該考慮的問題有： 
      1.你現在分析和設計能力能否勝任大中型的應用系統還是隻是獨立功能分析和設計？ 
      2.設計過程中是否有意識的考慮到組件的複用和相關接口設計準則。是否能夠很自然的將分析模式，設計模式的相關內容應用到自己的設計過程中。 
      3.是否對XP，RUP，面向對象，結構化等方法論都有過較系統化的學習和思考。 
      4.是否真正理解系統功能需求和非功能需求對系統設計的不同的指導作用。 
      5.對自己設計的功能是否會根據後期的變更來反思自己的設計爲何不能很好的適應變更？ 
      6.是否在設計過程中經常自己開發些原型來對自己的設計思路進行驗證？ 
      7.是否專注技術的同時開始專業業務流程的分析，關注業務建模？ 
　     對於DotNet架構經常用到的知識和技能儲備有 
      1.RUP方法論，4+1視圖。用例驅動業務建模- >分析模型- >設計模型 
      2.用例模式- >分析模式- >設計模式 
      3.常用的分佈式技術 
      4.對安全，異常，日誌，性能等非功能性需求的關注 
      5.對應用系統整體業務的關注