微軟的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.是否專注技術的同時開始專業業務流程的分析，關注業務模組化？
如果我們在設計和開發過程中經常關注這些知識和技能的話，成為一個合格的架構師是早晚的事情。平時能夠勝任工作開發用到的知識和技能是微不足道的，如果自己不是有意識的去學習這些知識的話，那技能是很難得到進一步提高的。我參加過兩次微軟的架構師教育訓練，在北京的微軟架構峰會上也有機會專門參加了P&P Workshop的學習，教育訓練老師是微軟總部SmartClient Architecture and Design Guide一書的作者Edward A.Jezieski，讓我感受最深是老外深刻的技術底蘊，對程式開發的執著。
對于DotNet架構經常用到的知識和技能儲備有
1.RUP方法論，4+1視圖。用例驅動業務模組化- >分析模型- >設計模型
2.用例模式- >分析模式- >設計模式
3.常用的分布式技術
4.對安全，異常，日志，性能等非功能性需求的關注
5.對應用系統整體業務的關注
![快學Python：如何測試函數與類1.測試函數2.測試類[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)