第一周学习总结
逆水行舟,不进则退。
架构师
架构师是做架构设计的,是对系统负责的那个人,
架构师是一顶帽子,而不是一把椅子,架构师是一个角色而不是一个职位。
理想情况下,架构师需要创建一个技术愿景,通过该愿景我们可以获得可维护又可靠的产品。架构师需要协调不同的团队,共同构建一个相互依存的软件生态系统。此外,他们还需要分享高层的集成决策,传达应用程序和组件之间协同工作的方式。除此之外,他们还需要根据常见的软件问题审查并规定工具和框架,并通过向利益相关者和领导层传达最终产品的目标和愿景,将所有这些联系在一起。
所以架构师的工作听起来很伟大。你可能想知道为什么我把如此之多的工作都推给了忙忙碌碌的架构师。为了理解这一点,让我们来看看我刚描述的情况与现实生活的对比。
生活或者工作中都会做出各种各样的选择,每一种选择都会产生不一样的结果,而这个选择就是自己tradeoff 之后对于一件事或者一个机会做出的响应,而你就是自己人生的设计师(架构师),你走的每一步道路都是自己设计出来的,因此说架构师是无处不在的。但是对于架构师的理解可谓是众说不一,有点像一千个读者就有一千个哈姆雷特。之前个人的观点就是沟通、协调、分配任务、设计方案、扯皮等。。。通过学习和思考发现远远不止这些,这些只是冰山的一角而已,架构师在一些大公司会分为业务架构师、系统架构师(技术架构师)等,小公司一般都是一个人会兼任这两个职责,不同的划分都有自己的诉求,业务架构更关注业务,技术架构更专注技术的设计。不管如何划分但是架构师的核心能力其实不会有多大的差别,主要从架构师的主要职责和核心能力进行阐述,当你明白了架构师做的事情及核心能力才能更进一步的了解他,日常工作中需要我们改掉一个low的习惯,就是架构师不在于你是不是,而在于你有没有做架构工作,架构最关键的是相关方,架构师是一种角色,人人都可以承担架构师的角色。只有你在当前职位做出了超越当前职位甚至下干了下一个职位的事情,你才能座到那个位置,否则凭什么让你上位呢?架构师需要的是一个“悟”,人生也是一样的,需要参悟。
架构师主要职责
编写架构设计文档
开发编程框架
重构软件代码
设计系统架构
技术选型,解决技术使用中存在问题
性能优化
模块分解
系统安全与高可用
技术创新
沟通管理
...
架构师核心能力
要成为一个NB的架构师,首选需要是一个出色的程序员,一个出色的程序员意味着在技术的深度上有所建树;其次技术的广度也即多领域知识、技术的前瞻性(对新技术等有敏感);最后就是抽象思维、透过问题看本质的能力;贯穿前后的还需沟通交流、平衡取舍,我们不是一个人在战斗,是在一个群体中战斗,去推动群体完成公司的战略目标,不沟通和取舍不现实。
架构
软件结构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各方面的设计(维基百科)。
架构是由架构元素和元素间关系组成的,元素间的关系有静态关系、动态关系;系统会有一种或者多种架构,而架构需要由架构文档来体现,架构文档由架构视图来组成,架构视图反映的是相关方关注点的具体展现。架构核心就是解决业务相关方的问题,不同的相关方(产品、业务方、技术经理等干系人)关注点不同,需要有考量提供不同的架构文档,别一股脑的搞一些不相关的文档给他们看,这样很容易让别人觉得你抓不住重点,能力不行有待提升。架构师面对不同的受众,要用不同的方式,展示不同的侧面。其实不同的人关注点不一样,需要我们提供人家感兴趣的东西。架构本身就是一个多面体,通过多维度来展示个问题。
架构师如何做架构
架构师需要将自己对于现实问题理解抽象出模型,模型映射到计算以达到对现实问题的求解。所以说架构师是介于领域问题与系统之间的桥梁,既要熟悉业务(对业务敏感),也要熟悉系统。
架构师做架构其中之一就是需要产出设计文档给相关方看,架构师的第一个成果就是架构设计文档,架构设计文档由架构视图组成,架构视图当然就是业界鼎鼎大名的4+1视图,这个视图传递了一个很好的设计理念就是都是围绕这场景来说事情,每一个视图展示了一个面,四个面和一个中心就构成了一个完整的问题解。
架构师常用的建模语言就是UML统一建模语言,UML图分为两大类分别为静态图(用例图、类图、组件图、部署图)和动态图(序列图、活动图、状态图),而我们只需要掌握其中这七种就足以应付工作中的case。在软件开发的三个阶段中需要的UML图如下所示:
需求分析:用例图、状态图、时序图、活动图
概要设计:部署图、系统级时序图、系统级活动图、组件图、组件时序图、组件活动图
详细设计:类图、类时序图、状态图、方法活动图
所谓的图只是为了落地架构师的设计理念,以便于验证该设计是否可行,作为一个NB的架构师一定记住你面对的受众是谁,每一种图都有自己的受众,就好比你拿着刀背切西瓜,虽然能搞,但是别人看着别扭,明显的就是你用错了,可想而知效果肯定不好。架构师可以通过组件相关的图很好的把控项目的进度,只因组件图的粒度可以拆的很细,这样前后依赖、时间都是可以掌控的,组件相关图也是开发任务分配单位。既然有了各种图,还需将公司的业务背景及战略目标融入设计文档,这样才能让人理解清楚前因后果,当然设计文档中还需体现非功能的需求,这些需求不可忽略,也是重之中。以上只是架构师的输出产物之一,后续还有其他的干货分享。
评论