如何煉成NET架構師

  微软的DotNet 开发绝对是属于那种入门容易提高难的技术。而要能够成为DotNet 架构师没有三年或更长时间的编码积累基本上是不可能的。特别是在大型软件项目中,架构师是项目核心成员,承上启下,因此 RUP 方法论也认同以架构为核心,体现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.对应用系统整体业务的关注相关的一些参考书籍(微软网站和电驴都可以下载到)

微软网站提供的参考书籍
Enterprise Solution Patterns Using Microsoft .NET
.NET Data AccessArchitecture Guide
Application Architecture for .NET:Designing Applications and Services
Caching Architecture Guide for .NET Framework Applications
Designing Application-Managed Authorization
Smart Client Architecture and Design Guide

其它架构方面的参考书籍
Software Architecture In Practice
Pattern-Oriented Software Architecture
The Art Of Software Architecture
Beyond Software Architecture

模式方面的书籍
Analysis Patterns
Design Patterns - Elements of Reusable Object-Oriented Software
Applying UML and Patterns
Design Patterns Explained

时间: 2024-10-13 15:51:19

如何煉成NET架構師的相关文章

新一代組合創新架構師_學習地圖

新一代<組合創新>架構師  從初學到認證 學習地圖 第1步:自行(免費)學習線上課程,包括: 課程-1. (3.5小時)               需求碎片化时代,从编程到设计的心灵鸡汤(上集)                 需求碎片化时代,从编程到设计的心灵鸡汤(下集) 課程-2.  (4小時)                           需求碎片化时代_让碎片没钱就改版_改版就有钱 參考書籍: <思考软件,创新设计:A段架构师的思考技术> 作者:高煥堂 &

混合 Data Warehouse 和 Big Data 倉庫的新架構

(讀書筆記)許多公司,儘管想導入 Big Data,仍必須繼續用 Data Warehouse 來管理結構化的營運數據.系統記錄.而 Big Data 的出現,為 Data Warehouse 提供了一個互補的機會,而不是取代後者. 高度結構化的營運資料 (data,數據),仍然可保留在 Data Warehouse 中:而分散式 (distributed) 的資料,以及會即時改變的資料,則可交由基於 Hadoop 的架構來控制. 圖 1 傳統的 Data Warehouse 和 Data Ma

學習 React.js:瞭解 Flux,React.js 的架構

Getting To Know Flux, the React.js Architecture Ken Wheeler (@ken_wheeler) 簡介 歡迎來到學習 React 的第三章.今天我們將會學習臉書的 Flux 架構的工作方式,以及我們怎麼把它應該用到我們的工程中. 如果你沒有準備好,我強烈建議你回去看看這個系列的第一.第二章,Getting Started & Concepts 和 Building a Real Time Twitter Stream with Node and

計算機架構圖

一臺計算機能夠正常運行:有以下結構組成 從下到上: 第一:硬件 第二:Kernel 內核,即所謂操作系統 第三:庫,公共系統調用的資源,API,應用程序接口 第四:Shell,與人交互的shell,不需直接與內核或硬件打交道!如下圖

在 docker 環境下建立以 MongoDB &amp; NodeJS 為架構的 web server (for Win7)

參考文獻 教材程式碼 教材解答 說明: http://proserge.kh.ua/coding/index.php/post/33/MongoDB+for+NodeJs+devs+week4%3A+Perfomance node.js + mongo db 是大家習慣使用建立 [Web + database] project 的工具;以上教材是在 docker 的環境下的建立簡易部落格.教材程式碼部分露空,主要讓讀者自己完成;答案也有網址,為了方便展示執行結果,我將 2 者合併為一個 proj

學習日記:函數和對象

2016-2-21 1. Living without an aim is like sailing without a compass. 生活沒有目標,猶如航海沒有羅盤. 2. 無論是現實世界還是計算機世界,可讀性都是相當重要的,因為這涉及到人們的意識或者是認識效率,一般文字比數字的可理解性和可讀性要好,圖片的可讀性最強. a) 一般數學是比較抽象的,因為其中充滿著各種阿拉伯數字和已經不能再簡化的希臘字符. b) 數學家的得意之作就是覺得自己是在世界科學界的最巔峰. c) 我們能用數學工具處理

1天讲座,成为优秀架构师

1小时,学会架构设计:1天讲座,成为优秀架构师 歡迎參加:高老師的<1天講座,成為優秀架構師>講座課程. 地點:台北.上海.新加坡. 索取報名表:[email protected](請註明上課地點) 交流學習:學員可參與<兩岸三地交流>相互學習.無盡成長 主講人:高煥堂 (台灣T型架構師論壇.主席) ~ End ~

(转载)閱讀他人的程式碼(6)閱讀的樂趣:透過程式碼認識作者

即便每個人的寫作模式多半受到他人的影響,程式人通常還是會融合多種風格,而成為自己獨有的特色,如果你知道作者程式設計的偏好,閱讀他的程式碼就更得心應手. 閱讀程式碼時,多半會採取由上而下.抽絲剝繭的方式.透過記錄層層展開的樹狀結構,程式人可以逐步地建立起對系統的架構觀,而且可以依照需要的粒度(Granularity),決定展開的層次及精緻程度. 建立架構觀點的認識是最重要的事情.雖然這一系列的文章前提為「閱讀他人的程式碼」,但我們真正想做的工作,並不在於徹底地詳讀每一行程式碼的細節,而是想要透過重

好站、好書、好詞推薦 不定時更新

http://oomusou.io/refactor/refactor-in-action/ 漸進式網路應用 https://medium.com/@murtazazaidi_/native-mobile-apps-vs-react-native-apps-vs-progressive-web-apps-be81b314cdec 開發者RoadMap https://github.com/kamranahmedse/developer-roadmap 其他技術性名詞紀錄 (慢慢整理 太多技術名詞