上周，极客大学推出的李智慧老师《架构师训练营》正式开营了，繁忙的工作之余我还是抽时间准时参加了课程。
说起李智慧老师，算是久闻其名了，前几年刚刚开始知道“架构”这个词的时候就知道李老师有一本畅销书《大型网站技术架构》，讲的就是像淘宝这种规模的网站是如何搭建和运作的。我并没有买这本书来看过，不过从那时起我就知道李智慧老师一定是一个很厉害的架构师。
后来由于工作和兴趣的原因，我开始自学架构知识。说起架构师这个角色，我觉得自己一直属于在边缘徘徊的角色。作为影视CG行业的流程技术指导，我平时只是用Python写一些面向企业内部的桌面应用和脚本，没做过互联网应用，没搞过大规模高并发的系统，更没用过Spring全家桶，但是我始终按照专业程序员的标准在要求自己，始终在关注互联网行业都在做些什么。而且，虽然我们写的东西技术复杂度比较低，但却包含了整个公司业务的方方面面，由于项目需求和周期不同，所以业务复杂度一点也不低，而现有的技术栈和架构方式已经很难满足需求变更的频率。从这个角度讲，我认为在我所在的职位上也是可以学架构、做架构的，因此我平时会更注重编程规范、设计模式、架构模式方面的知识，慢慢地我发现很多解决问题的原理和思路是相通的，就好比设计模式可以用在生活的方方面面一样。例如，如何根据不同的需求使用不同的处理过程，这就是接口、多态、依赖注入方面的内容，如何避免复杂任务运行到一半挂掉之后产生脏数据，这就是事务的ACID原则……
随着年龄的增长，我也越发希望自己能够在架构的道路上更进一步，从业余、自学步入专业、实战的状态，因此当看到李智慧老师推出训练营的时候，我毫不犹豫就参加了。我知道市面上有不少架构师方面的课程，但价格都很高昂，而且都是以技术方案的讲解的为主，像我这种没有Java基础的，其实是不太敢去学的。而李老师的课从简介上看并不是讲技术，而是讲方法论，并且更侧重于能力的培养，以及应对面试的方法，所以我决定给自己一个自我检查、自我提升的机会。
李老师在开课之出就讲到，如何成为一名架构师。对于这个问题，常见的回答有两个方向，一是通过应聘架构师职位来成为架构师，二是通过公司内部晋升被任命为架构师，但无论哪种都是有门槛的，而且没有做过架构的话，怎么应聘架构师呢？但当不成架构师，又怎么做架构呢？这似乎就成了个悖论。但正确的思路应该是，架构师只是一个头衔，但并非只有架构师才能做架构，无论当前的头衔是什么，只要在做架构的事情，在为系统的设计而负责，其实就已经在履行架构师的职责，在积累着架构师的经验。所以在平时就要注意多积累、多培养架构师相关的知识和技能，多去做相关的工作，提升硬实力和软实力，这样当面对应聘或晋升机会的时候才能得心应手，顺利拿到架构师的头衔。
结合当前大厂JD普遍对架构师的要求，李智慧老师的总结出了以下架构师的主要职责：
编写架构设计文档
开发编程框架
重构软件代码
设计系统架构
进行技术选型，解决技术应用中的问题
优化系统性能
模块分解与微服务架构重构
保障系统安全与高可用
大数据应用
技术创新
沟通管理
与之相对应，架构师的主要能力包括：
编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化与分析故障的能力
常用架构模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
《架构师训练营》的课程内容正是根据这一职责和能力列表细化得来，最终的目标就是“做到架构师所应当做到的”。结合这两个列表自查，我认为自己编程能力、架构模式和框架理解能力、建模和设计能力、业务分解能力不算差，其他能力就有明显的不足了，而职责对应着经验，其实我的工作经历中算不上有真正的架构经验，李老师在课上也说，希望大家学完之后能够用学到的技能重新审视之前做过的系统并尝试以架构师的思维和方法对其进行重构，从而优化工作经验。
架构应当如何学习呢？其实很多架构师会告诉你，架构是没法学的，架构师也无法通过培训产生。能学的是架构的知识，例如技术选型、各种产品和框架的使用，设计方法论和架构模式，但架构的思维、解决问题的思路和经验，乃至架构师本身的工作方式，这些是没法通过学习得到的，只能是在不断的实践中去培养，而由于每个人的悟性不同，所能达到的水平自然也不同。曾经听过这样一句话：一切脱离业务谈架构都是在耍流氓，架构是必须要关注业务的，因此架构的内容也必须视业务而定。不同的公司、不同的环境有不同的业务，自然架构也就没有所谓的唯一正确答案，我们要学的并不是如何再造一个淘宝，事实上99%的架构师都没有这样的机会，我们要学的是如何把架构师的知识体系和技能运用到当前的业务需求中，以合理的方式完成架构设计和实现。
那么，到底什么是架构？对于这个问题，不同人也有不同的答案，李老师给出了这样一张图：
这张图说明了一件事情，那就是架构过程中真正核心的是“相关方”，其实这就是所谓的“面向切面编程”、“横切关注点”在说的事情。架构本身是对系统整体结构的抽象，他是一个复杂的、拥有不同层次的、可以表达不同内容的知识集，如果我们把整个系统架构的所有方面、所有内容都写在一起，那么牵涉到的东西会过于繁杂。对于架构过程中不同的参与者来说，其所关注的内容和目标是不同的，我们说一切业务活动都是为了实现特定的价值，而对不同的相关方来说价值也是不一样的，例如针对运维人员，架构的价值体现在高性能、高可用，针对业务部门，架构的价值在于灵活易用、快速接入，针对决策部门，架构的价值在于更好地帮助业务运转，提供持续发展的推动力和竞争力。
所以，做架构的过程就是面向不同的参与者、以不同的视角和关注点，通过架构文档来描述系统的各个组成部分及其之间的关系。
那么架构文档又应当包含哪些内容呢？针对不同的参与者，应当输出什么样的架构文档呢？针对这个问题，李老师介绍了4+1视图和UML。
UML基本上每个开发者多多少少都了解和接触过，我也不例外，但是自己画的图总是不那么规范、标准，对于UML到底包含些什么内容也不能一次性缕清。通过这周的学习，我了解到了UML的具体组成，以及每种图分别是用来干什么的。李老师还强调了一点，UML其实有很多方言变种，所以平时画得不太标准也不用太担心，而且实际工作中也往往不是每种图都要画，但了解标准的画法和含义有助于我们在工作中更好地进行沟通，既能准确展示自己的想法，又能快速理解别人的设计。
在此推荐两本UML方面的书，这两本书都比较厚重，看起来需要一定的耐心，但是对UML的讲解非常完整。
其实UML远非花几张图那么简单，训练营课程中所讲的案例还都比较简单，但是实际工作中遇到的需求和业务逻辑会复杂得多。正确运用UML中的用例图能够帮助我们从需求中整理出系统最终要实现的功能，以及不同的参与者，同时为测试环节提供测试用例和验收标准；而类图、组件图则能帮助我们将一堆待实现的功能进行拆分，降低各个模块的开发难度；各种动态视图则能帮助我们明确系统运行和调用的过程，各种状态的变化，这样有助于我们正确设计接口，避免调用关系过于复杂。
网友评论