• 架构漫谈阅读笔记


    软件架构师的职责: 

      所谓软件架构师,是软件行业中一种新兴行业,工作职责是在一个软件项目开发过程中,将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划,是主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员。

           软件架构师其实相当于是软件项目管理的主管,他负责设计与构筑公司的系统架构,对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。软件架构师还要跟踪架构的使用情况,以保证软件开发符合制定好的系统架构。他还负责进一步改进系统架构,以符合公司发展的业务要求。软件架构师还得给设计人员和开发人员提供系统架构的培训。这些就是一名软件架构师的职责目标。

           软件架构师的主要任务不是从事具体的软件程序的编写,而是从事更高层次的开发构架工作。他必须对开发技术非常了解,并且具有良好的组织管理能力。可以这样说,一个架构师工作的好坏,决定了整个软件开发项目的成败。其实,软件架构师的工作职责可以分为三点。首先最重要的是负责软件项目的测试,也就是根据详细设计书,编写测试单元的用例,然后根据软件测试用例,搭建软件测试环境,进行软件测试,最后整理软件交付件,参与软件的交付工作。我们都知道软件架构师,是对一个项目整体进行架构设计的,所以如何对自己所设计的架构的系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握,就需要软件架构师对软件项目进行测试以发现体系结构中的优缺点。然后软件架构师还要负责软件项目的实施。也就是负责编制使用说明书,还有负责针对发现的问题或用户的要求,进行沟通并确定问题解决办法。我们在上个学期的软件需求分析的课程中,就已经学习了,什么是用户需求,所以在软件项目实施的过程中,用户的体验很重要,所以作为一名软件架构师,需要发现客户在使用的过程的一些问题,并对自己的架构或者说是整个项目进行改进。最后软件架构师还应该负责软件系统技术支持。也就是说软件架构师还应该负责软件系统的运行监控,负责软件系统日常运行过程中的技术支持,并负责解答用户疑问,还要参与软件系统日常运行过程中的问题排除并收集用户反馈的软件问题及改进需求。其实这一点也就是对上述两点的一个总结。

    软件架构师的基本素养:

      沟通能力和自我表达

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

      有一定的魄力和感染力

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

      有广阔的知识领域

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

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

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

      多方位思考分析能力

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

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

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

      需求整理分析

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

      系统分解

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

      技术选型

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

      系统设计

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

      保持沟通

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

  • 相关阅读:
    定时删除日志文件---linux定时清理日志
    Packagist 镜像使用方法--composer
    laravel 5.5 跨域问题解决方案
    linux服务器上面部署ShowDoc 安装Composer
    shell之批量新增用户脚本(http-basic-auth)
    js转义问题
    js之select三级联动
    《远见》之读书笔记
    Node.js之判断字符串中是否包含某个字符串
    微信小程序之页面传参
  • 原文地址:https://www.cnblogs.com/ziyixuedie/p/8527847.html
Copyright © 2020-2023  润新知