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

Posted 2022-01-20 李迟

前言

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

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

复盘

上午综合题

分数是55分，基本符合预期。在考试时，不确定答案的题目，都会圈出来，记录的大概有13题左右——跟去年差不多。计算题和英文题都不难，难的是中间部分的概念题，有很多题都没见过（准确说是没复习到）。

下午案例分析

分数62分，超出我的预料。回想起来也没有答得很好，试题一的架构风格，质量效用树的填空题不难，但风格区别答得不好，架构风格选择那题，我选的是解释器。试题二的UML用例和顺序图填空不难，因为题目给了关键信息，但最后那3个术语的概念题没见过（在网上搜索发现有比较多的资料），答题时按字面意见胡扯一通。试题五的填空题、TCP和UDP区别不难，第一小问（传统智能家居管理和云平台家居管理的差别）有点难，但因为前2年搞过互联网的案子，当时搜索过一些资料，凭记忆回答，现在已经想不起来写了什么了。

下午论文

分数52分，超出我的预料。我选的是微服务，虽然没真正搞过，但起码docker这些有深入研究，微服务、云计算这些概念是知道的。考试较紧张，整体发挥不好，背景和过程写得不好，但起码把微服务特性写了（题目给有一些），然后按项目模块划分设计，把restfull、网关、nginx转发、redis写上，最后加上自动化部署（包括gitlab和jenkins），基本把自己这两年接触的知识都写了。洋洋洒洒写了2500字，一直写到考试结束。

备考篇

去年考过了项目管理师，今年继续软考路，考的是系统架构设计师，因为作为技术人员，我比较看中这个。

相比去年，今年的考证是内心驱动的，因为要用证来证明自己。花了204大洋报名，如果通过，可以退税几百（听同事说可退500块，到时看看），虽然截止12月月底我才交800多块的税，但如果能退的钱超过200块，那也有赚的。

去年高项考试结束后，就开始着手架构师的考试。粗看大纲和网上的电子书，发现很多技术点和概念是我没接触过的，心里没底，所以前后买了三本书（不过实际上书本没看多少，但考试时确实也考到了书本的知识点）。如果买书标志着开始复习的话，我的备考时间长达一年。

总体看，我先大概过一遍大纲，知道要考哪些方面的知识，再粗略过一次教程，实际上没吸收到什么内容，主要还是听视频、作笔记。一开始，按类别刷题，到近考试的前2个月，就按年份刷真题，前后刷了2遍。

由于属于自己的时间实在太少，并没有正经地复习，书本只看过几次，终成摆设，后来调整战略，看了网络公开资料（如某库、GitHub），加了一些群，从群中也拿了一些资料，然后上B站看免费视频，再下载软某通APP刷真题。B站上高项的视频很多，架构师的却有一定年头了，所幸偶尔刷到较新的视频（2018年的），于是下载到手机中。

由于上下班通勤时间比较长，合计将近2小时，所以就利用时间来听视频，磨耳机，日积月累，在工作之余学到的知识也慢慢巩固起来，也慢慢理解“架构”一词的含义。架构考试也涉及到项目管理，恰好部门今年要过CMMI5，所以学以致用，同时加深理解。

刷题一般利用睡前、排队、吃饭的时间，刚开始做错的题比较多，后来慢慢有进步，以至于后来设计模式、架构风格、质量属性的选择题都能全部答对——在没有看完题目情况下。

另外秉承“好记性不如烂笔头”的原则，我在记事本上手写笔记，顺便练字（应对写论文），但是有些资料有图片或网络上有现成的，因此也用 Markdown 记录下来。做笔记须先看大类，再细化，这样容易构建全局观和知识树。比如设计模式有3大类，每类有若干种。传统架构风格有五类，每类又有若干子类。架构评估有3种，再分若干种。等等。

考试复盘发现，架构师的知识点太广泛了，我并没有全部都看到（哪怕已经在书本上），因为记录了的已经有很多了，还是将那些知识点记熟。但有部分还是只看了大概，比如RUP只看了四个阶段的名称，及各个阶段的主要任务，具体细节就没去记。我还认真看了并研究海明码和CRC计算，只是没考。

但我又不想只学书本的东西，所以也花了一些时间看点其它相关的视频，B站有英文原版的视频，我找了一些介绍架构，UML，重构方面的，顺便练习听力，也解决上午的英文题。对于设计模式，我主要看李老师的教程，除了学习设计模式外，对面向对象编程原则有深层次的理解。

所有这些时间，都是长期硬挤出来的，并没有因为考证耽误工作和照顾小孩，只是今年没有再接过私活。

考试篇

考试前几天及当天，我虽然也有看题，但都没有命中，还得靠平时的积累。考试前的准备工作必须要仔细检查。比如准考证、身份证、黑色笔、铅笔、橡皮擦、小刀、（非电子）手表。像今年我考试时，还需要核酸阴性报告、通行卡（我都打印出来备查）。

字需要练，不要求漂亮，但要求整洁，平时做笔记时最好手写，否则论文那关不好过。

工具十分重要，像我，由于钢笔坏了，水性笔写字不好看，论文整体版面不够好。又因为戴电子表，被检查出来，还好考试有挂钟。总之，考场上不如去年那样顺畅，多少影响应试心态。

应试篇

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

策略

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

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

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

下午案例分析和论文，是在听完视频后再着手的，主要是在网上收集、记录案例真题，同时搜索案例和论文涉及的点。有些知识点做了扩展，比如V模型、MVC，像redis，较全面地了解了（只限于了解），因为网上很多相关的面试题目。Java方面是强记，但不怎么理解，只记得servlet、EJB、各种Bean等名词。近年真题出现过的知识点，需要熟记，以防再出现。个人认为还是靠积累经验，案例题属于主观题，原则是尽量写完所有题目，万一放水就能得分了。

对于论文，我直接沿用去年的项目，项目背景和技术点都没变化，因为项目亲自做过，而且印象深刻（包括但不限于跑了大部分充电桩，在路边午休，欠工资，等）。如果没有实践经验，只能靠背了。数字一定要足够，因此平时练字做笔记就有必要了，而且版面要整洁，笔者写完回顾发现有部分语句不通顺，但并没有再涂改。

案例和论文需要涂填题目号，一定要核对清楚，这两科时间是最紧张的，心态很重要。

一般情况下会提前几分钟发试卷，此时应该可以看题目。笔者坐到教室最后一个位置（但序号不是最后一个），我拿到试题时，别人估计已经过了几个题目了。

速记

本节对一些知识点进行联想记忆，有些是自己总结的，自认为还可以。

23种设计模式

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

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

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

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

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

注：速记可应付选择题的分类题目，但不同模式的应用场景，需要理解，也可应付案例

模型与图对应关系

功能模型 －－ 数据图   功据（工具） 
数据模型  －－ 实体联系图   数实 （属实）
行为模式 －－ 状态转换图   行状 （形状）

UML两种图

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

质量属性

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

其它

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

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

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

外一篇

从应试中学到的

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

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

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

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

杂项

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

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

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

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

经济学十大原理之一：人们面临权衡取舍。对应到架构中的术语，是敏感点和权衡点考点。

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

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

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