| 系统架构师是怎样炼成的 | |
“在我工作的六年多时间里,除了第一年是纯粹编码以外,其余时间都在做和架构设计有关的工作,当然也还一直在写各种各样的代码。”张友邦认为架构设计可能看起来很神秘,新入门或没有架构设计经验的程序员刚开始的时候会有种不知所措的感觉,但其实架构设计是件很容易的事,它只是软件系统开发中的一个环节而已,整个软件系统的开发和维护以及变更还涉及到很多事情,包括技术、团队、沟通、市场、环境等等。
在技术能力上,软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识,包括进程内通信(对象访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如RMI、DCOM、Web Service)。在WEB应用大行其道的今天,开发者往往对服务器间的通信关注的比较多,而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石,它是架构设计中的鸟瞰视图;而进程内的通信是模块实现的骨架,它是基石的基石。如果具体到一个基于.Net企业级架构设计,首先需要的是语言级别的认识,包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识,包括ASP.NET Web Service、.NET Remoting、企业服务组件等。总之,丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去,给代码编写人员带来实实在在的可行性。 其次,具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力,可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事,一厢情愿的保留接口在需求变化中的命中率非常低。也就是说,在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用,因为需求的变化并没有按照预想的方向进行,到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。 再次,张友邦提到,架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围,包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程,沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊,我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱,让系统构建过程可以有条理的高效进行。另外,对人的关注还表现在对团队成员的素质判断上,比如哪些开发人员对哪些技术更熟悉,或者哪些开发人员容易拖进度等。只有合理的使用人力资源,让合适的人做合适的事情才能让整个软件过程更加高效。 另外,张友邦认为架构师应时刻注意新软件设计和开发方面的发展情况,并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级,软件架构师需要吸收这些新技术新知识,并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行,不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术,而且它们在推广自己的解决方案的时候往往是以自己的产品为中心,容易给人错觉。比如数据库,往往让人觉得它什么都能做,只要有了它其它什么都不重要了。但事实上并不是如此,对于小型应用可以将许多业务逻辑用script的方式放入数据库中,但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断,包括横向的比较和纵向的比较,最后得出一些性能、可移植性以及可升级等指标。另外,新入行的开发人员往往关心新技术动向而忽略了技术的历史,而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。 构架师不是通过理论学习可以搞出来的,不学习并且亲自实践相关知识肯定是不行的。就像前面说到的,架构设计是一个工程性质的事情,只有在不断实践的基础上才能逐渐熟悉起来。实践的内容并不是去深挖各种语言的特性,因为系统架构师是设计应用系统架构而不是设计语言(除非你是要实现DSL)。更多的时候需要带着一种比较的眼光去实践,把不同的实现方式下的优缺点做个总结,做到自己心里有数,等具体的上下文环境下才好判断采用什么样的方式方法。把基础打牢的同时掌握一定的方法,架构设计不是想象中的那么难。【记者/付江】 |
|
| 楼主 创建:08-04-03 18:37:30 更新:08-04-03 18:45:31 | |
| 发表回复 | |
| 1/1(共1页) | |
| hello123 | hao~~ |
| 1楼 创建:08-05-06 15:32:48 更新:08-05-06 15:32:48 | |
| 大大猫 | 我也想当系统架构师 |
| 2楼 创建:08-10-19 22:11:21 更新:08-10-19 22:11:21 | |
| 发表回复 | |