第一周学习总结
0. 起点
老师一开始从 JD 讲起,讲了一些常见的架构师招聘简历描述及要求,看似没有东西,其实里面蕴含的内容还不是一般能及的,以为代码写的牛逼了,随随便便糊弄糊弄就能做架构师了。那可能是技术专家,但是不是架构师。
0.1 拆解架构师的能力要求
架构设计能力、核心组件、核心服务实现能力
定位系统的问题、提高系统性能、稳定性以及业务扩展性
主导跨部门协作和负责的能力 平衡各方利益
海量数据和大规模分布式系统的设计和开发经验
对数据结构的深刻理解和优秀的编程能力、算法设计能力
良好的沟通、表达及团队协作能力
后面老师提了一些常见的面试问题
看了下,答不上了,就算是瞎答一点,深度还是不够,蜻蜓点水,不得要领。
后面老师讲了什么是架构师
0.2 什么是架构师
架构师是做架构设计的、对系统架构负责的那个人。
架构师是一顶帽子,而不是一把椅子;架构师是一个角色而不是一个职位。
如果你是做架构的,那么你就是架构师,不管你的职位是开发工程师、程序员还是项目经理。如果你的公司,项目经理只是分配活,没有这些设计,程序员就自己随性开发,那么你的机会来了,你可以尝试画画架构图,分享给同事,不要让别人来给你带上这个帽子,你把架构师的事情做了,你就是架构师了,无关乎别人怎么看你。
好像我们公司就是这样的,机会来了。
1. 什么是软件架构
软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计 ——维基百科
架构图
软件架构包括上图的系统、架构、文档和相关方等元素。任何系统,无论大小皆拥有软件架构,并且需要做专门的软件设计。软件设计真正的目的其实是降低成本,进行可行性研究,能不能做,可不可行,因为设计成本一般会远低于实现。当然,软件设计的核心并不在于系统或是架构本身,而在利益相关方(stakeholder)。
在软件设计的不同时段,设计文档应该根据评审的参与方(相关方)的不同,进行不同的、有侧重点的、能满足他们需求的设计图纸。
2. 架构视图
软件架构包括:元素、形式、关系/约束。由于单一的视图很难完整的表述架构,所以需要多种形式的图像来表述各个方面的设计意图,因此需要一份完备的视图集,业界常采用的方法就是 4+1 视图
4+1 视图分别是:
逻辑视图:设计的对象模型
过程视图:捕捉设计的并发和同步特征
物理视图:描述软件到硬件的映射,反映了部署特征
开发视图:描述开发环境中软件的静态组织结构
场景视图:描述用例的场景
3. UML 模型
建模是对一个系统的完整抽象。在计算机开发中,实现从领域问题到计算机系统的映射,以便抽象出更易得到的解决方案。UML 就是在面向对象开发中最常用的建模手段。UML 应该是一种软件开发里面的工业标准。UML 图大约有 10 种,其中常用的有 7 种,这些图例可以映射上文提到的 4+1 视图。
UML 中通常元素有:类、对象、节点、包、组件等:
元素之间的关系有:关联、依赖、泛化、聚合等:
UML 中的消息:简单消息、同步消息、异步消息等
3.1. 用例图
Use Case 是系统分析阶段最常用的模式。在宏观上给出系统的总体轮廓,一般是产品经理编写。每个用例图的元素不宜过多,总数控制在十个左右,可以自顶而下逐步细化。
3.2 时序图
时序图可以描述对象之间的动态交互行为,是穿插于各个开发阶段重要的视图。时序图有两个轴:横轴表示对象,纵轴表示时间。
时序图有两种形式:一般格式和实例格式:
一般格式:描述所有情节在,包括分支、条件和循环,比较复杂
实例格式:描述一次可能的交互,没有分支判断,仅仅显示特定情节的交互
3.3 泳道图
泳道图是活动图里面最常使用的视图。它用以描述完成活动的对象以及活动;泳道图的最大特色就是显示分组机制,可以描述跨系统的交互互动:
3.4 状态图
状态图用来描述特定对象的所有可能态,是产品经理在需求阶段重要的工具,开发阶段会进一步把状态图的内容转换为特定的方法和条件判断。
在复杂的状态变迁中,一张状态图,能说清楚对象变化的不同阶段,以及各种变化条件,后续开发人员可以根据这张图,具体实现逻辑校验,并且测试人员能够根据此图来进行针对性的检查、测试。
下面是电梯运行的状态图:
3.5 组件图、部署图
组件图和部署图提供了物理层面的建模,描述了各个子系统间的关系,是架构师最早改画的一份视图:
它描述了各个组件之间的关系。
还有就是部署图,系统怎么部署的,架构师心里也应该很清楚,后面运维人员根据这张图能针对性的找到运维关注的重点和难点以及是否需要对部署架构进行优化:
3.6 视图与整体设计
开发的不同阶段,可以根据不同的场景和情况,编写不同的视图,下面是不同阶段用到的视图:
需求分析阶段:用例图、活动图、状态图、时序图
概要设计阶段:(各个子系统级别)部署图(架构师的第一张图)、时序图、活动图、组件图
详细设计阶段(方法和类级别):类图、时序图、状态图、活动图
当然,视图的意义不在于多,在于正确的抽象业务,建立对解决方案的抽象模型;以最少的视图抽象出最完整的现实场景解决方案,才是一个架构师的能力体现。
4. 小结
第一周课程主要集中在画图上面,老师反复强调不要怕画图,要多画图,画正确的图,画 UML 图,其中 UML 建模时课程的重点吧,老师时靠它开始逆袭的。
架构设计文档时团队交流、协同工作的重要依据、方式和方法;熟练掌握这些技能,可以极大的改善开发体验,当然这也是架构师一项必备的技能。
很多架构师很牛逼,项目是他一手搭建,代码是他一手写出来的,但是就是没有架构设计文档,没有相关的一些图输出。这是一个切入点,也是为我们自己负责,为自己的未来负责,为下份高薪、下份更专业的工作打下坚实的基础,虽然我自己也不重视。
4.1 资料来源
https://www.jianshu.com/p/86f3eb140e31
https://blog.csdn.net/zgpeace/article/details/106556982
感谢上面的资料 很久没有学习了 更别说认真的学习了
那个画图 苦思了很久 不得其解 参考了网上的例子
虽然参考 全程手打 自己不苟同的地方略微修改 图 全程自己画 虽然模仿
后面这个总结 也是平时学习的时候没有积累 所以参考别人的输出
第二周 每天学习的时候就要
记录日总结
作业每天都要有进展 合理安排时间 不要最后周末来赶 就像暑假要完了 最后 2 天赶作业 太难了///
评论 (1 条评论)