软考路：2021年系统架构设计师之心得

Posted 2022-01-13 李迟

前言

都说等待是难熬的，但我例外，因为事实在太多了，上班一天很快就过去了，下班还得干体力活，不知不觉一个多月过去了。前几天的下午，有消息称可以查成绩了，刷新了很多次，终于登录到系统，点击鼠标时，手还是会抖——恰如去年那般。看到成绩后，认为对得起这一年的备考，也算是实现了年初定的目标之一。

本文写一下备考过程及一些心得，权作记录。

复盘

上午题考试时记录的不确定的题目大概有13题左右——跟去年差不多。最终分数是55分，基本符合预期。

下午案例分数62分，超出我的预料。

下午论文分数52分，超出我的预料。

备考篇

去年考了项目管理师，今年继续软考路，考的是系统架构设计师。作为技术人员，我比较看中这个。但是架构师偏的技术很多是我没接触过的，心里没底，前后买了三本书，不过实际上书本没看多少，但考试时确实也考到了书本的知识点。

应试篇

本节结合考试做一些描述。

策略

考试分三科：上午选择题，下午案例分析和论文。不同科目有不同的应付策略。

根据经验，架构考试会结合系分、网络、高项的知识。因此，在精力允许情况下，可以参考系统分析师（与web、数据库、架构风格有关的）、网络、高项等的试题（当然精力一般都有限）。

上午选择题考的范围大，知识点分散，像计算机组成原理、操作系统、网络、数据库，在大学里都是单独的课程，但考试中每一类只有几分，且每年考的点都不懂，因此需要全面学习，当然也有侧重点，有的考点在选择题、案例、论文中都有可能考，是重中之重。但也需要有战略地放弃，像网络的综合布线，数据库的范式等，经过几次的学习复习，还是没记住，于是就放弃了。

我是先大概过一遍大纲，知道要考哪些方面的知识，再过一次教程，实际还没吸收到什么，听视频，作笔记。按分类刷真题，近考试前2个月，按年份刷真题，前面刷了2遍。收集、记录案例和论文，搜索案例和论文涉及的点。有些知识点做了扩展，比如V模型、MVC，像redis，较全面地了解了（只限于了解），因为网上很多相关的面试题目。 Java方面是强记，但不怎么理解，只记得servlet、EJB、各种Bean等名词。

先有大类，再细化。如设计模式有3大类，每类有若干种。传统架构风格有五类，每类又有若干子类。架构评估有3种，再分若干种。

利用空闲时间构思论文，因为项目亲自做过，而且印象深刻（包括但不限于跑了大部分充电桩，在路边午休，欠工资，等）

部分细节没有看，如RUP只看了四个阶段，及各个阶段的主要任务。

认真看了并研究熟记但没考的：23种设计模式（重点学习），海明码，CRC码。

速记

对一些知识点进行联想记忆。如：

23种设计模式

设计模式的一点思考：不同模式均有对应的使用场景，模式是应对变化点的，解决稳定中有变化的点。如果所有地方都变化，或所有地方都没变化，那么，不适用设计模式。设计模式不是万能的。

设计模式包含三种类型，速记如下。

创建型：    
速记：单工抽原建 （单工抽元件） 

结构型：  
外观（门面） 组合 享元 装饰 桥接 适配 代理  
速记：外组享装桥适代 （外祖想装桥四代）

行为型：  
迭代 命令 解释器 访问者 观察者 职责链 中介者 备忘录 策略 状态    
速记：迭命模解访观职，中备策状（爹命摩诘访观止，终被车撞）  

注：可应用分类问题，但不同模式的应用场景，需要理解

模型与图对应关系

功能模型 －－ 数据图   功据 
数据模型  －－ 实体联系图   数实
行为模式 －－ 状态转换图   行状

UML两种图

UML静态图：    
组合结构图 对象图 包图 部署图 构件图 类图     
速记：组队包布构类（组队包布够累）  
UML动态图：  
用例图，活动图，状态图，制品图，定时图，交互概观图，通信图(协作图)，顺序图（序列图，时序图）  
速记：用活状，制定交通顺（用活动的桩，来制定交通，一定顺利）  
交互图3种：定通顺

质量属性

功能性 （Functionality）、性能（Performance）、 可靠性 （Reliability）、可用性（Availability）、安全性（Security）、 互操作性（Inter-operation）  
易用性（Usability）、可测试性（Testability）、可变性（Changeability）、可修改性（Modification）、健壮性（Robustness）     
共11个属性， 记忆：   
效用树 由4个重要的属性组成：  
安全性、可用性、可修改性、性能    －－》记忆：安用改性   
其它的次要：功测靠操易变壮

其它

软件维护类型：正是预完（正是鱼丸）。

网络安全五要素：用完抵保控（用完低保空，用完了低保，口袋空了）。

需求开发：获分定验。需求管理：两控制两跟踪。

外一篇

从应试中学到的

不同的专家/书籍，对相同的事物描述可能不相同，一般地都没有实质性的错误，只是从不同维度描述而已，作为高级考试，一般不扣字眼。不能抬杠，不用钻牛角，因为考试自有其规则，必须那边回答，考试是一回事，实践是另一回事。不管日常工作还是学习，从多维度看问题，思考问题，也是不错的。

整体复习了软件研发过程涉及的方方面面，如系统规划（虽然涉及少），需求分析，架构设计，编码，测试。

泛化和继承，按一般理解，先有父类，再有子类，此为继承。但实际中往往是从各个类中抽取出共有部分，重新组成父类，此为泛化。

天下大势，合久必分，分久必合。很多种都是来来回回迭代发展。从系统粒度上看，从模块、类、构件、服务，再发展到微服务。从设计原则看，类的职责要单一，但设计模式中外观模式又讲究统一接口，其实它们都自有一套内在逻辑，以适应不同的场景。没有最好，只有最适合。

杂项

重新复习了计算机组成原理、操作系统、网络及数据库，前面三门课加上编译原理，当年学得还可以，数据库一直提不起兴趣，工作后也很少有机会接触到。

架构在需求之后，编码之前进行，关注的是怎么设计架构达到项目目的（而不是做不做项目），到了架构这一阶段，不再做可行性研究，因为之前已经做过了，也不确认需求是否合理，而是如何做能完成需求。。

软件架构主要由需求决定，需求有功能性的和非功能性的，其中非功能性的需求主要就是指质量属性。关注质量属性，功能性需求倒是次要。拓宽视野，在考虑程序时，会自然考虑维护性，扩展性，安全性等方面。

从教程或视频看，架构似乎不关心系统功能需求，其实这是默认的，因为系统首先体现的就是功能需求，如像web服务器，首先要提供web服务，其次才考虑安全和并发等。功能是最直观的，但架构更关注背后支撑的东西。

经济学十大原理之一：人们面临权衡取舍。架构涉及到敏感点和权衡点考点。

设计模式有一定的应用场景，并不是万能的。

架构的设计过程还是比较抽象，并没有像写代码那样能在脑海里过一次。

初步了解分布式，负载均衡，redis集群。分布式还没有理解很深，负载均衡写了代码实践了。

看了一些相关的英语视频，包括设计模式，微服务，分布式以及重构方面，有的视频甚至没字幕，对于涉及的术语能快速反应。顺便提升了一些英语听力。当然是暂时的，若干年后不知道能不能记起。