本文主要是介绍人月神话blog:如何循序渐进向DotNet架构师发展,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
http://sd.csdn.net/n/20060714/92603.html
微软的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.是否专注技术的同时开始专业业务流程的分析,关注业务建模?
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
这篇关于人月神话blog:如何循序渐进向DotNet架构师发展的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!