架构设计_阿里弃用dubbo后新框架_架构设计原则(2)

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

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26396-2.html