架构师训练营第一次课程感想小记 1

——写在第一周课程之后



参加了极客时间（time.geekbang.org）的第0期架构师训练营，写写自己的感想。

先声明，这是一篇有自己的思想、行文诙谐甚至黑色幽默的文章，平时不怎么接触幽默的可能会感到不适应，可绕道。

首先，看看老板/公司对“架构师”的要求。深圳的字节跳动（南山区）的架构师招聘要求，对广大架构师绝对是全身武装、精通十八般武艺的写法，为了不透露课程内容，我去51job找了个类似岗位的要求如下：

———————————————————————————————————————————



这个绝对是除了架构设计和重构（职位描述1和3）之外、开发（有明确的“编码”字样）、测试（不测试你怎么定位系统瓶颈）、产品、项目经理一肩挑的要求，难怪给的工资高。5-7年经验+学历本科，3-6万/月。不禁想起了网上的一句话：干到35岁，给家人留一笔钱（遗产）不好吗？（内涵金句）

相对来说，北京的岗位工资低一些，不过要求实在、接地气一些

———————————————————————————————————————————



这就是说：兄弟，你会开发和架构就好，来了主要做开发和设计，肯定得写写需求什么的，不过从这个描述和要求上看，大概率可能还得维护（要不懂shell、Python等后端编程语言是不是浪费了），保障换个说法就是运维。

架构师身兼数职，类似八脚章鱼、千手观音一样的出击效率，如高性能计算机一样的头脑、像大规模分布式存储一样海量的存储和容错能力被这两个招聘要求写得跃然纸上，不由得让我对现在任职的架构师这个岗位有了进一步的深刻的认识。到了2020年，架构已经代替全栈、高级软件工程师，成为整个团队当中的门面，出道必选，大概率C位。所谓商业计划书、投资都有了差的就是你啊。（那为啥薪酬上不来呢？-_-||）

以前我们缺全栈，全栈来了人消瘦。

现在全栈都不够，我们唯独缺架构。

既然一个架构处于这么重要（碎催）的地位，我们来学习架构师的技能就是非常重要的事情了。

于是我可以得出一个结论：今年过节不放假，过节都去学架构。

-------这是分割线-------

老实说，我也是软件工程专业科班毕业，受学校教育多年了对不对。从业十几年，交费来听这门课，不是为了讲笑话开玩笑的。《软件架构》这门课我在校也学过，也得了90分以上的高分。我报名的目的是为了看看最近业界有什么新的知识需要我进一步学习，以及门外面的世界有什么需要我知道的，和时代、业界、伙伴保持一致的步调。



一、软件架构的定义

第一周，老师主要讲述架构师的职责、定位、课程安排、软件工程中设计方面的知识。

聊了半天，回到软件架构这门课，我们先讲讲定义。

软件架构的定义，可以说是软件工程（Software Engineering）这一学科比较难下的定义了。软件架构的定义从是什么和做什么两个角度分别说明：

是什么：软件系统的架构将系统描述为计算组件及组件之间的交互。

（组成派的定义，简洁，我喜欢，软件工程课程考试的学生也喜欢）

做什么：用于指导大型软件系统各个方面的设计。

对于做什么，软件架构的决策派作出了更加详细的描述：

定义（软件架构包含了关于以下问题的重要决策）：

1.    软件系统的组织。

2.    选择成为系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为。

3.    如何组合这些元素，使他们逐渐合并成更大的子系统。

4.    用于指导这个系统的架构风格：这些元素以及它们的接口、协作和组合。

5.    软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。

决策派的定义就复杂多了。组成派更偏重软件“自己长什么样子”，重视对物的描述；决策派更偏重“怎样选择软件的样子”，重视人的思想发挥作用的过程。

老师用了维基百科的定义：

软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

说实在的，维基百科这个定义简化了架构的内涵，不太利于学习者理解其范围。因为，各个方面，具体指那些方面？

老师说架构师是一个帽子不是一个职位（估计老板看了都会点头），你可能有架构职责，但是公司不一定有架构师这个岗位或职位。所以，一个软件开发工程师、测试工程师，都可以学习一下架构课程，对深入的知识有所掌握，拓宽自己的职业道路。从英文的角度讲，帽子cap加上能力ability就是capability（更偏重潜在的能力）。

二、架构师职责

——奉献

把自己奉献给伟大的软件架构事业，你需要做：

从具体领域问题到问题描述的抽象、控制问题描述向软件需求的转化、干预软件需求向最终编码的模块、抽象化层次的控制。

而不仅仅是上面两个招聘CV要求的需求、开发、测试、运维、产品经理、项目经理。包含但不仅限于这个词了解一下。

职责实现：

1、 画视图。

2、 建造模型。

老师介绍了一种模型来描述这两件事：4+1软件架构模型。

这个模型是RUP理论中的，RUP就是Rational United Process，RUP同时也是业界为数不多的直到现在还在用、并且是由公司名称命名的一套工作流程理论，不过Rational公司被IBM收购了，成为后者这个IT巨头当时的六大软件板块之一。



上图将4+1视图中“4”的内涵用一种非常平实的语言表述出来。

过程视图是这门网络课程当中的说法，那么RUP中，原来的意思是Process view，翻译为处理视图我认为更加合适。

1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。如下图所示。



Philippe Kruchten提出的4+1视图方法

针对以上的4+1，UML（统一建模语言）做了一系列工作，UML的7大常见图，就成了架构师最常用的沟通工作用图。《UML用户指南》也是被推荐的官方出品读物之一，另一本是《UML参考手册》。个人认为《UML参考手册》难读一些，拿着《UML用户指南》就能按部就班地画出各类图了，用词精简易懂，非常适合初学者和工程师。





画图，一般还是用Visio。不过今天发现一个Java的use case图好工具：Jude。小巧，虽然界面简单一点，不过绘制use case图够了。

三、工作技能

讲了UML和OOA（面向对象分析）、OOD（面向对象设计）的一些知识。

1、抽象模型、模型间关系和图形表示。

Use case用例图。

类图。

顺序图（时序图、序列图）翻译不同，对应的都是Sequence Diagram。

活动图。活动图和算法中的有向图（状态机）很类似，可以在工作中注意它们的联系。

协作图。协作图和顺序图存在互相转化的关系。

组件图。

部署图。

异步消息有了定义（单边箭头），要注意。

想必广大在架构师岗位的朋友都很熟悉，这也是软件工程基本知识，不赘述。

2、文档

介绍了几款架构师常用架构设计文档。

四、工作方法

根据康威定律描述做架构的方案，并通过实例讲解了现实社会中组织变动、工程的实现。

讲到了GPS四星定位系统，这里就多讲两句。为什么地球上的点不能通过三星定位。需要修正GPS接收器和卫星间的时间误差。三个卫星可定位一个点，再用一颗卫星的时间参考来消除误差。这样的话，对于每个地面点的位置，需要求解就有4个待定参数，因此至少需要4颗卫星至地面点的距离数据。