浅谈软件架构师的素质与职责

原文:http://www.nowamagic.net/internet/internet_DutyOfSoftwareArchitect.php

最近开始学习如何成为一名合格的架构师。首先参照别人的观点,在结合自己的实际经验,写出自己对如何成为一名架构师的理解,希望大家热心于与援手,能够指点一二。

  沟通能力和自我表达

  我认为沟通能力是基本中的基本,最为重要,最为普遍的素质。技术人员好像容易忽略,想成为架构师就不能忽略。因为架构师要做的第一件事就是与团队成员、项目经理、客户认同沟通,获得认同。我知道,这对于现在做技术,以后想转做架构的人也许很难。对本人也是如此。也许你会注意到虽然你兢兢业业,老黄牛的做了很多事,但每次升迁的总是那些平时最活跃的人。抛除其他方面的因素,领导之所以选这种人,是因为领导认为他能与人打交道——也就是沟通,而我只能做事,只是个好员工。虽然我自认为也擅长沟通,但没有表现出来,别人如何得知。沟通是双向的,一方面要能够理解对方的意思,另一方面也要让对方理解你的意思。所以如果要成为架构师,首先要勇于表达自我,然后仔细聆听对方的话语。不可抱有"酒香不怕巷子深"的观点,不然结果就是"怀才不遇,图子伤悲"了。

  有一定的魄力和感染力

  架构师要与很多人打交道,其中不乏领导,刁钻的客户,技术狂人。而架构师是有职无官,但又要推动整个团队的技术进展,能在压力下作出关键性的决策,并将其贯彻到底。这就需要架构师具有一定的魄力和感染力,依此来排除工作过程中一些个人情绪带来的影响,从而保证工作顺利进行。其实这点就算不做架构师,在日常生活中,相信大家也有所体会。面对有感染力的人,他哭你悲,他伤你哀;面对有魄力的人的铿锵话语,相信他的话你不会不听;反之,面对一个亦步亦趋,唯唯诺诺的人,你如何敢相信他的话,又如敢与他共事!

  有广阔的知识领域

  架构师的职责有些特殊,多少有点需要创新的要求。虽然有很多现成的架构,但放到具体行业又有不同,不能生搬硬套。那么这时候你就需要专业的架构知识,丰富的业务领域知识,开阔的眼界。依此才能跳出架构和业务,从旁看清楚事实,从而将理论架构与实际业务完美结合。我认为,要做的这点,架构师不仅要努力学习架构和业务知识,也要把眼光放得更远。"世事洞明皆学问",也许灵感正来自与软件毫不相干的东西。

  有过硬的技术能力和丰富的编程经验

  广阔的知识领域是广度的要求,因为没有广度就成了井底之蛙。然而有了广度还要有深度。人的精力有限,但至少要精通1~2门技术。有深度才能把握细节,才能保证自己的设计不是天马行空,不切实际。有丰富的编程经验,主要是希望保持一种代码感觉,能够和开发人员进行有效的沟通,了解团队的情况。当然这并不是要求自己成为一门技术专家,只要能够保持对代码的感觉就行。因为优秀的技术选型可能有很多,适应于团队的缺未必。

  多方位思考分析能力

  收集到客户需求和技术团队的反馈后,就要求架构师能够对这些资料进行系统分析,制订可行的解决方法。制订可行的架构,不仅要求你要从客户的角度考虑,也要从开发,机器等多方面考虑。这就要求你具备一定的抽象思维,多方位分析能力。只有具备这样的能力,架构师才能看清系统整体,掌控全局。如何具备这些能力?首要的是经验,自己的,别人的均可,这点最重要。创新固然让人兴奋,然前人之鉴才更为稳妥,另外,相信大家都听过"听君一席话,胜读十年书"这句话,由此可知经验有多么重要;其次要学习。

  当我们具备了这些条件的时候就可以选择成为架构师了。这时候我们就应该知道软件架构师应该做些什么,不应该做些什么,也就是软件架构师的职责范围。

  由于国内外软件土壤差别巨大,适合国外的一些理论在国内不一定行的通,而国内的一些资料往往都是根据国外的资料直接搬过来用的,这也直接导致国外的软件架构师在国内变得水土不服。今天本篇随笔的内容则是在一些培训资料的基础上,加上自己的思考,总结出来的适合国情的软件架构师职责范围。

  需求整理分析

  有人认为架构师是在需求规格说明书完成后介入的,但我认为架构师要从项目最开始的阶段就参与进来。理由有很多:首先,第一手的信息损失最少,架构师能够更好的把握需求;其次,分析人员在与客户交流时,往往不会深入挖掘需求,因为有很多隐藏的需求客户自己都不见得意识的到,而架构师则可以依靠敏感的软件嗅觉发现这些需求,减少以后的变数;第三,分析人员往往脱离开发团队,盲目接受客户需求,而架构师能够清楚把握现有的研发团队能做什么,不能做什么,提前预知风险,降低项目失败的机率。

  系统分解

  在收集完信息后,架构师需要将用户需求转化为软件需求,同时要补充非业务需求,如健壮性,扩展性等等。如何区分和化解用户需求与软件需求,如何有效把握用户需求与软件需求的区别,是系统分解的核心。这是最考验架构师的地方,也是只有架构师参与的工作。

  技术选型

  这一步要根据对软件需求决定项目该使用何种架构,开发模型,及依赖选项。如使用多层架构还是分布式架构,是瀑布模型还是RUP,是使用MySQL还是SQLServer,是否需要使用企业库,是否需要使用ORM。但是,架构师对项目的技术选型要提供多种不同的方案,并为每种不同方案提供详细说明文档,用来阐述每种方案的优势,劣势,可行性等内容。这些文档供项目经理或领导决策最终的技术选型。

  系统设计

  依据软件需求和技术选型,架构师需要和软件工程师一起将软件需求落实到软件详细设计说明书中。架构师负责将软件需求分解,重组织为子项目,子系统,组件和模块,以及它们之间的逻辑关系,从而形成不同的逻辑组成部分,最后还需要确定各个子系统及组件间的接口。这些都是作为进一步的团队分工的依据。同系统分解一样,系统设计是考验架构师能力的重要职责。

  培训与指导

  在软件详细设计说明书完成后,为保证项目的顺利进行,架构师需要对整个团队进行技术培训,让团队中的每个人明白自己的职责范围,该做什么,不该做什么。在项目实施过程中,架构师需要参与到具体开发过程中,给与每个开发人员有效指导,以避免团队成员对系统设计的误解而造成项目的延误。在我看来,这点对于新手比较多的团队尤为重要。因为国内新手的一个通病是眼高手低,刚学会了一点点就认为自己什么都会;当他们拿到真正的设计时又往往不知所措,畏首畏尾。

  保持沟通

  沟通是保证项目顺利开展的有效保障。架构师要从多方面跟踪项目进度,及时与项目经理或直属领导汇报项目进展,与技术开发人员沟通遇到的问题,如果是迭代开发,还需要与用户沟通需求变更。

  以上是一个项目开发过程中架构师需要承担的主要职责,相比一些培训指导,我认为,架构师需要更深入地参与到项目中。

时间: 2024-11-08 13:35:38

浅谈软件架构师的素质与职责的相关文章

浅谈软件开发者应具备的基本素质

我们常常能在一些电子产品的发布会上听到新产品修复了某些BUG.开发出了某些先进的功能: 我们常常会听到某些黑客攻击某些网站的消息,也可能受过某些电脑病毒的侵害: 我们也常常能在一些科幻大片里见到程序员在紧急关头敲打代码拯救世界. 每天,我们都在使用着电子产品,使用着软件程序开发者的成果.但是,对于普通人,软件开发又高深.难以涉猎.而作为软件开发者,又应该怎么样对待软件开发,应当具备哪些素质?我正在学习软件开发,下面从个人的角度,浅谈自己的看法. 开发软件的基本前提是站在他人的角度考虑问题:软件开

说说组织除冗——互联网+时代组织变革浅谈

说说组织除冗--互联网+时代组织变革浅谈 作者:张国祥 2015年7月16日 互联网+时代,去中间层.管理扁平化的呼声可谓此起彼伏.不绝于耳!更有甚者,要砍掉中间层,去管理层的尝试也时时见诸网络.这到底是怎么回事?面对这场前所未有.遍布全球的"加"(互联网+)与"减"(去管理层)的浪潮,广大中国企业应该何去何从?作何决策?正确应对会对中国企业的生存与发展产生深远的影响,反之亦然. 任何管理理论的诞生都是缘于时代的要求.任何管理方式都是实践经验的产物.在管理理论上,笔

浅谈软件工程

借鉴<构造之法>--浅谈软件工程 源程序就是代码,建立在数据结构之上,对数据进行操作.数据分为静态数据和动态数据. 软件构建不仅仅是cc和link命令,一个复杂的软件具有合理的软件架构.软件设计,实现等等.软件团队要从需求分析开始,把合适需求梳理出来,然后展开后续工作,如软件架构设计,写数据结构和算法,测试到最后发布软件. 由“软件=程序+软件工程”扩展出“软件企业=软件+商业模式” 程序是基本功,软件工程决定了软件的质量,商业模式决定了一个软件企业的成败,软件从业人员的道德操守会极大的影响软

浅谈 MVP in Android(转)

我自己写的demo:https://pan.baidu.com/s/1dFImVYD 一.概述 对于MVP(Model View Presenter),大多数人都能说出一二:“MVC的演化版本”,“让Model和View完全解耦”等等.本篇博文仅是为了做下记录,提出一些自己的看法,和帮助大家如何针对一个Activity页面去编写针对MVP风格的代码. 对于MVP,我的内心有一个问题: 为何这个模式出来后,就能被广大的Android的程序员接受呢? 问了些程序员,他们对于MVP的普遍的认识是:“代

浅谈信息安全

对于很多IT公司来说,信息安全是老生常谈的问题了.那么如何做到信息安全呢?我们先来看下面两个故事. 施乐公司的帕洛奥图研究中心(常被叫做"施乐PARC") 成立于1970年,是图形用户界面(GUI)技术的先驱.它可能是世界上最善于创新而最不善于将创新商业化的机构了.施乐PARC的工程师们研发出了友好的图形用户界面,以取代当时电脑屏幕上那些拒人于千里之外的命令行和DOS提示符.但很遗憾的是,他们并没有将之商业化,其成果仅停留在实验室中.一个偶然的机会,乔布斯到施乐PARC去参观,看到了图

浅谈 产品经理、研发、测试,三个冤家如何高效沟通

浅谈 产品经理.研发.测试,三个冤家的那点事(1) 算上实习时间,参加工作已经五年了,一直在从事软件开发和测试的工作,期间也兼职干过一部分产品经理的事情,对这三者之间的微妙关系,颇有感悟. 1. 先来解读一下这三个岗位的"痛点" 聚会的时候,经常碰到以下几种情况,事后想起来,经常会有逗乐的感脚. 做开发的GG们是这样的: 一聊到自己的项目,两眼开始冒光,同时开启了狂喷模式,blabla一堆高大上的专业术语,一方面骂测试人员不懂技术,提的bug根本就不是关键问题,高级的bug他们根本就发

浅谈java异常[Exception]

本文转自:focusJ 一. 异常的定义 在<java编程思想>中这样定义 异常:阻止当前方法或作用域继续执行的问题.虽然java中有异常处理机制,但是要明确一点,决不应该用"正常"的态度来看待异常.绝对一点说异常就是某种意义上的错误,就是问题,它可能会导致程序失败.之所以java要提出异常处理机制,就是要告诉开发人员,你的程序出现了不正常的情况,请注意. 记得当初学习java的时候,异常总是搞不太清楚,不知道这个异常是什么意思,为什么会有这个机制?但是随着知识的积累逐渐也

浅谈程序员的行业选择---程序人生

引言 本篇博文接着许久之前的一篇博文<浅谈程序猿的职业规划,看你如何决定自己的未来吧.>,继续探讨一下程序员行业相关的内容. 行业的选择不仅对于程序员来说非常重要,对任何一个人来说都是一样的.只不过对于程序员来说,行业更容易被忽略.从程序员每天热议的话题就能看出来,大部分的热议话题都是C#和Java哪个更牛B,或者IOS和Android哪个挣得钱多,很少看到程序员去讨论两个行业谁更有发展前景. 鉴于此,今天我们就来着重讨论一下程序员行业的选择,行业和语言一样,没有谁优谁劣,只是一种选择罢了.

浅谈产业界与学术界的合作研究(转)

[编者注:原文可参阅: http://blog.sciencenet.cn/blog-414166-795432.html ] 最近网络上有一个流传甚广的微故事:"某企业引进了一条香皂包装线,结果发现经常会有空盒流过.厂长聘请一个博士后花了200 万设计出一个全自动分检系统.一个乡镇企业遇到了同样的问题,民工花90 元买了一台大电扇放在生产线旁,一有空盒经过便会吹走."这个微故事不断出现在笔者的视线中,想必在网络上得到了公众的认可.引起了共鸣,所以大家争相转发.平心而论,大多数人的内心