软件设计师下午案例题：五类题型判分逻辑与通用解法

上午题交卷时心里还有底下午案例题一出考场很多人就开始怀疑自己——知识点明明都背过图也画了字也写满了可就是不知道能拿几分。2024上半年的软件设计师案例题整体沿用了下午卷的经典版式五道大题覆盖结构化分析的数据流图、数据库设计与E-R转换、面向对象建模的UML图、算法设计与C语言代码填空、面向对象程序设计填空。它的难点从来不在知不知道这个概念而在于能不能在有限时间里从一段两三千字的业务描述里抠出正确的实体、正确的数据流、正确的多重度再用手写的方式规范地画出来。这篇内容面向正在准备这类考试的读者也面向那些已经考过一次、想知道自己到底错在哪的人。我会把每一类题型的判分逻辑、通用解法、以及我自己和身边人反复踩过的坑摊开讲清楚让你看到案例题其实是一门信息提取规则套用的手艺活而不是玄学。1. 下午卷五道题的版式逻辑与失分真相1.1 五道题的固定分工决定了复习的投入比例先把这张表放在最前面因为它直接决定了你时间该怎么分配。下午卷的题量、分值、题型在近些年高度稳定这不是秘密但很多人复习时的投入比例和分值比例完全不匹配——花两周啃设计模式却只花两天练数据流图这属于典型的用错力气。题号题型常见分值核心考察能力可预期程度第1题数据流图DFD15分结构化分析与信息提取极高几乎必考第2题数据库设计E-R、关系模式、规范化15分建模与范式判断极高第3题UML图用例、类、状态、顺序15分面向对象建模极高第4题算法设计与C代码填空15分算法理解与逻辑推理高算法种类浮动第5题面向对象程序设计填空Java/C15分代码阅读与框架理解高看懂这张表你就会明白前四题中前三题几乎全是规则型题目答案对不对取决于你有没有掌握画图和标注的规则而不是取决于你聪不聪明。这类题是整张卷子里性价比最高的部分理论上45分的题练熟了应该稳定拿到38分以上。第4、5题才是真正吃基本功的地方但因为填空位通常有4到6个每个空独立给分所以即使代码读得磕磕绊绊也能拿到一半以上的分数。我在复习时做过的统计是把前3题的规则清单完整梳理一遍大约需要三天把第4题常考的七八种算法骨架吃透需要两周第5题的代码阅读能力靠的是长期积累短期突击收益有限。所以如果你的复习时间只剩一个月正确的顺序是先锁死前3题的规则分再去啃算法最后才是代码填空。反过来做的人往往会陷入算法题研究了很久还是不稳定回头一看数据流图基本没练的尴尬。1.2 看得懂知识点却拿不到分问题出在格式分这是案例题最反直觉的一点。绝大多数失分不是因为不懂而是因为不规范。案例题是人工阅卷阅卷人手里拿着一份标准答案答案是结构化的这个空必须填外部实体维修人员你写维修部门的人来操作意思再对也很难给分。数据流图必须从数据存储指向加工、从加工指向外部实体你箭头画反了逻辑再自洽也是零分。我见过太多人复盘时的心态是我明明想到了啊。想到了不算分写对才算分。所以案例题的训练方式应该和上午题彻底分开上午题是识别正确答案案例题是生产标准答案。前者靠刷选择题后者必须动笔必须写在纸上必须对着标准答案逐字比对。只做前者的人考场上会出现一个非常典型的症状——读完题觉得都会动笔时发现名字叫什么、箭头朝哪、多重度标在哪全都不确定。提示案例题一定要手写练习至少完整手写三套。用电脑打字练习的效果会打折扣因为你不会意识到自己写字速度有多慢、图示布局有多乱。1.3 我的答题顺序与时间切分下午卷总时长两个半小时五道题平均每题三十分钟。但这个平均是陷阱。前三题虽然规则性强但阅读量大——一道数据流图题的背景描述往往有一千五百字以上逐字读一遍就要五六分钟。如果你按三十分钟平均分配很容易在第4题算法上卡住二十分钟然后前面题目的检查时间被彻底挤掉。我习惯的顺序是第1题、第2题、第3题先做第5题次之第4题放最后但保证留足二十五分钟。理由是前三题的答案是渐进产出的——即使某一个小问不确定其他小问也能拿到分写一点得一点先拿到手最安心。第5题代码填空虽然难度不低但填出来的空是有把握的不会出现写了一堆全错的情况。第4题算法反而最容易出现思路卡壳、时间黑洞放最后能有效止损。时间切分的具体做法是每做完一题立刻在草稿纸角落记下当前时间。如果第1题做完已经过去四十五分钟说明你的阅读速度或者画图速度有问题后面必须加快。这种实时的自我监控比事后懊悔有用得多。我自己的节奏是前三题各三十分钟第5题二十五分钟第4题二十五分钟剩下二十分钟用于返工——尤其是数据流图的箭头方向和多重度标注这两处是最容易在紧张中写错的必须留时间回头看一眼。1.4 题面里的隐藏条件是怎么布置的案例题的背景描述不是平铺直叙的说明文它埋了大量的判定条件而且往往以很不显眼的方式出现。比如描述里说每个设备可以有多个维修记录但每条维修记录只对应一个设备这句话就是多重度判定的直接依据说系统允许同一个人在不同部门担任不同职务这就是在提示你不能简单地把人和部门合并成一个实体。这些句子有个共同特点它们通常出现在段落中间用但同时若只有这类词引出来而且往往不是后面问题的直接提问对象。多数人读题时会不自觉地跳过这类限定语只记住主干。我的建议是读第一遍时用笔把所有的量词、限定词、条件句划出来——多个唯一每个只能必须至少一个。这些词在后面的问题里几乎每个都会对应一个得分点。这不是玄学而是结构化分析的题面本身就是按数据模型来写的出题人写多个的时候脑子里想的就是一对多关系的标注。2. 数据流图分层平衡与缺失数据流的定位方法2.1 父子图平衡是最硬的扣分点数据流图这一题通常分三到四个小问补充外部实体、补充数据存储、找出缺失的数据流、有时还要求写出数据字典条目。第一小问往往是最简单的送分题第四小问最难。但无论哪一问有一条规则会贯穿始终那就是父子图平衡——顶层图0层图里某个加工的输入输出流在它展开的下一层图1层图里必须原封不动地出现。这条规则之所以关键是因为它提供了一个纯粹的机械检查手段。当你被问到图X中缺少了哪条数据流时如果题目给了两张图你几乎可以靠对比完成找出子图的边界看它的输入流和输出流然后回到父图看那个对应的加工框进出的流是不是一一对应。少的那条就是答案。我拿一个自己按真题结构编的场景来说明。假设题目描述的是一个设备报修管理系统报修人员提交报修单系统校验后生成工单派给维修人员维修人员完成后录入维修记录管理员可以查询统计。0层图有三个加工受理报修、派单调度、维修归档。受理报修的输入是报修单输出是已校验报修单派单调度的输入是已校验报修单输出是工单维修归档的输入是工单和维修记录输出是归档记录。现在看1层图里派单调度被展开成三个子加工如果子图里出现了一条叫维修人员空闲状态的输入流而0层图里没有对应这就是父子不平衡——你要么在0层图补上要么指出这条流是多出来的。反过来如果0层图显示派单调度需要输出派工通知给外部实体维修人员而子图里这条流消失了那就是典型的缺失数据流。画图时还要注意一点数据流不能凭空产生。一条流必须有明确的起点和终点起点和终点只能是外部实体、加工、数据存储三者之一。很多人答题时习惯在两条流之间画个箭头连接这在规范上是不允许的。另外外部实体之间不能直接有数据流数据存储之间也不能直接有数据流——一切数据交换必须经过加工。这两条约束看起来是常识但在紧张的考场上我确实见过有人把报修人员和维修人员直接用箭头连起来理由是他们要沟通。2.2 找外部实体和数据存储的排除法补充外部实体的题目通常给出四到五个空答案是题目描述里那些系统之外但和系统有交互的角色或系统。判定的思路很简单这个对象是不是在系统内部被处理如果它只是提供数据或者接收结果那它就是外部实体。值得注意的是外部实体不一定都是人也可能是另一个信息系统比如财务系统短信通知平台。但真正容易出错的地方在于名称的一致性。如果题面的描述里叫报修人员你的图里就不能写报修人或者申请人。听起来有点吹毛求疵但阅卷是按点给分的名称不一致会直接导致这个点被判错。我在练习时的做法是读题时把所有出现的角色名称、单据名称、数据名称单独抄在草稿纸上形成一个词表画图时直接从词表里取词绝不自己造新词。这个小习惯能救回不少冤枉分。补充数据存储的题目会稍难一点因为数据存储往往没有在描述里被显式命名。判断依据是系统需要记住哪些信息凡是需要保存、后续要被查询或更新的信息就是一个数据存储。比如报修单工单维修记录设备台账这些都需要持久保存。反过来说如果一个东西只是流经系统、处理完就结束那它只是数据流不是数据存储。数据存储的命名一般用XX表或XX记录并且要标注清楚它和哪些加工之间有读写关系——一条流从加工指向数据存储叫写入从数据存储指向加工叫读取方向错了同样是失分。2.3 缺失数据流的排查顺序这是整道题里最考验耐心的一问。我的固定排查顺序是这样的先看每个加工的输出流够不够。加工的产物如果要给外部实体必须有输出流如果加工的结果要保存必须有指向数据存储的流。再看每个数据存储的流向是否闭环。一个数据存储如果只有写入、没有任何读取通常意味着某条读取流缺失了——因为存起来不用是没有意义的。接着检查外部实体是否有只出不进或者只进不出的情况。如果某个外部实体提供了数据却从来没收到任何反馈那大概率缺一条输出流。最后回到父子图平衡逐条比对边界流。这个顺序的价值在于它是收敛的。你不必靠灵感去猜缺哪条流而是像查电路一样一个节点一个节点地过。练过五六道之后你会发现缺失的数据流往往集中在两三个位置上数据存储的读取方向、外部实体的反馈方向、以及跨加工的中间结果传递。这三种位置覆盖了绝大多数考题。注意写缺失数据流时必须写清从哪个对象到哪个对象只写流名称是不够的。标准答案的格式通常是XX → YY数据流名称为ZZ三条信息缺一不可。2.4 数据字典题的低成本拿分法数据字典一般是要求你写某个数据流或者数据存储的组成。它的标准写法是自顶向下逐层分解用表示定义用表示顺序组合用{}表示重复用[]配合|表示选择。举个例子报修单可以写成报修单 单号 报修人 联系方式 设备编号 {故障描述} 提交时间。如果某个字段本身还需要分解就继续往下写一层。这类题在整道大题里分值通常只有3到4分但性价比很高因为它几乎不依赖前面几问的正确性独立作答即可。我在考场上会把它当成必拿分来处理即使时间紧张也要把这个小问写完。写法上的注意点是括号必须成对层级符号不能混用字段名要和图里出现的名称对得上。这三条做到了基本不会扣分。3. 数据库设计题E-R图判定与关系模式转换的取舍3.1 什么时候必须把联系升级为实体数据库题的典型结构是给一段业务描述要求补充E-R图中的实体或联系然后把E-R图转换成关系模式标出主键和外键最后问某个关系模式属于第几范式。这里最容易卡住的是第一问——某个概念到底该画成实体还是画成两个实体之间的一个联系判定的核心在于这个联系本身是否携带属性。如果两个实体之间的关系仅仅是关联比如教师讲授课程那它就是一个联系不需要独立成实体。但如果这个关系有自己独有的属性比如教师讲授课程需要记录授课学年和课时数那么这个授课就应该是一个联系实体也可以叫关联实体它本身带属性转换时会形成一张独立的关系表。还有一个更隐蔽的判定条件联系的类型。多对多联系在转换成关系模式时必然要独立成表因为它无法通过在某一张表里加外键来表达。一对多联系可以通过在多的那一端加外键来表达不必独立成表。一对一联系则要看哪一端的参与是全部的把外键放在参与度高的那一端。这个联系类型决定表结构的链条是数据库题的核心逻辑理解了它后面几问就是机械操作。我编过一道自测题来练这个逻辑一个仓储场景描述是每个仓库可以存放多种物料每种物料可以在多个仓库存放且需要记录每个仓库中该物料的库存数量和库位编码。这里的存放是多对多且带属性库存数量、库位编码所以它必须独立成一张表主键由仓库编号和物料编号联合构成。如果你把它简化成仓库表里的一个字段整个模型就崩了。这类判断在考场上应该做到条件反射。3.2 主键与外键的书写规范转换之后的关系模式标准写法是把所有属性用括号括起来然后给主键加下划线外键在题目要求时用单独一行注明。很多人失分不是因为想错了而是因为格式没对主键没加下划线或者用波浪线代替外键写在该写的属性后面却漏了参照哪个关系。我的处理方式是先写属性列表再统一处理标注最后单独列一行外键XX 参照 YY(ZZ)。这样即使某个属性判断错了格式分至少不会丢。另外要注意的是联合主键必须整个下划线连起来画不能只画一半因为联合主键是一个整体缺一个属性它就不是同一个键了。3.3 范式判断题的答法说结论也要说理由问到这个关系模式属于第几范式为什么标准答案是两步先给结论再给理由。理由的表述是有套路的——如果存在非主属性对主键的部分函数依赖就是2NF如果存在非主属性对主键的传递函数依赖就是3NF如果存在主属性对主键的部分依赖或传递依赖那才牵扯BCNF。很多人只写因为有传递依赖却不指出具体是哪两个属性和哪个主键之间形成了传递这在阅卷时容易被判为表述不清。我的做法是把依赖关系写成一个明确的链条A → BB → C所以A → C 是传递依赖其中C是非主属性因此不满足3NF。这种写法虽然啰嗦但清晰度极高几乎不会因为表述含糊而失分。顺带说一句如果题目要求规范化到3NF你就必须写出分解后的关系模式而不是只说应该消除传递依赖——分解动作是要给分的。4. UML与面向对象建模三类图的答题套路差别很大4.1 用例图连线方向与包含扩展关系的区分用例图这一题常见的要求是补充参与者、补充用例、标出包含include或扩展extend关系。参与者的判定标准是谁或什么系统与系统发生交互这一点和外部实体非常接近因此数据流图练熟了这里能直接迁移。真正的坑在连线上参与到用例的关联线是没有箭头的实线或者用箭头指向用例表示主动发起而include和extend是带箭头的虚线方向不能反。include的方向是基础用例指向被包含用例语义是我执行时必须做那件事extend的方向是扩展用例指向基础用例语义是某个条件下我会给基础用例加一段额外行为。这个方向很容易记反因为直觉上会觉得是扩展加进来所以应该指向基础。我用的记忆方法是包含是我叫你去扩展是你来找我——我做主体我指向被包含者扩展是被动附加扩展方指向主体。还有一个高频失分点用例命名。用例必须是一个动宾结构表示一个对参与者有价值的目标比如提交报修单查询库存而不是报修单管理这种名词短语更不是校验数据这种内部步骤。内部步骤是不能作为用例的它属于系统内部的处理逻辑。这条规则在判断题里经常出现见到名词化的用例名就要警觉。4.2 类图多重度标注与聚合、组合的判断类图题通常要求补充类名、补全多重度、判断两个类之间的关系类型。类名的补充线索全部藏在题面描述的名词里把描述里所有的名词圈出来剔除掉它只是属性或者只是值的那部分剩下的就是类。这一步和数据流图找实体的思路是一致的。多重度的判断则要盯住描述里的数量词。一对一的典型表述是每个订单对应一张发票一对多的表述是一个部门有多名员工每名员工只属于一个部门多对多的表述是一名学生可以选修多门课程一门课程可以被多名学生选修。标注时要注意位置多重度标在关联线的两端靠近哪个类就表示哪个类的对象数量这个位置一旦标反语义就整个颠倒了。聚合和组合的差别说白了就是能不能同生共死。组合关系里部分不能脱离整体存在整体销毁部分也销毁图上用实心菱形聚合关系里部分可以独立存在用空心菱形。判断依据是看题面有没有暗示这部分是整体专属的。比如订单和订单明细明细离开订单没有意义是组合部门和员工员工离职后部门还在员工也可以调到别的部门这是聚合。至于泛化就是is-a的关系子类继承父类用空心三角形指向父类方向是指向父类的这一点也常有人画反。4.3 状态图与顺序图事件驱动与消息时序的差别状态图考的是对象的生命周期核心要素是状态、事件、迁移、守护条件。补状态的时候答案往往在描述的动词短语里——订单提交后进入待审核状态审核通过后变为已确认。这里的待审核已确认就是状态名。补事件的时候答案通常是触发状态变化的外部动作比如审核通过取消订单。顺序图考的是一次交互中对象的协作顺序纵向是时间轴横向是对象。补消息的时候要特别注意同步消息和异步消息的箭头差别实心箭头是同步调用需要等待返回开放箭头是异步消息发出就不管了。返回消息用虚线箭头。这些细节分值不高但都是明确的知识点会就是会不会就是不会没有中间地带。实际答题时我建议先画能确定的把不确定的留到最后因为图题有很强的互锁效应——一旦某个类名或状态名判断对了与之相关的几条线也跟着确定下来。反过来如果一开始就在最难的那个空上死磕很容易把整道题的节奏打乱。5. 算法设计题把代码填空当成逻辑推理来解5.1 先读问题描述的最后一段再回头看代码算法题的标准结构是先给一段问题描述比如求最长递增子序列的长度再给一段C语言代码框架中间挖四到六个空最后问时间复杂度和空间复杂度。很多人的阅读顺序是从头读到尾结果在描述里绕了十分钟还没进入代码。更有效的顺序是先看问题描述的第一句它通常直接点明算法要解决的问题再看代码的函数签名和变量名最后回头细读描述中的算法思路部分。函数签名和变量名给出的信息量远超想象。比如函数名叫findLongest参数里有int a[], int n返回值是int基本可以确定是在求某个最长长度如果内部出现dp[]数组和两层嵌套循环那十有八九是动态规划。先建立这个整体认知再去填空效率会高很多。5.2 高频算法骨架与对应的填空套路近些年的算法题集中在几类骨架动态规划最长公共子序列、背包、最大子段和、贪心区间调度、活动选择、图遍历DFS、BFS、连通分量、回溯排列组合、子集、以及部分排序类问题。每一类骨架的挖空位置都有规律。动态规划的挖空通常在三个位置状态转移方程、边界初始化、结果返回。状态转移方程的空最典型因为它往往是一个max或min表达式你需要判断的是取哪两个值比较。判断方法是回到问题定义——如果当前状态是以i结尾的最优解那比较的通常是接上i和不接i两种选择。贪心的挖空通常在比较条件上比如按结束时间排序后判断下一个活动能否接上的条件是a[i].start last_end。这类空的关键是搞清楚两个变量的物理含义写之前先在草稿纸上标注一遍。图遍历的挖空通常在递归调用或者队列操作上比较隐蔽的是访问标记的设置时机——是在入队时标记还是出队时标记这一点在BFS里会影响正确性出题人也喜欢在这里设空。我一般的做法是拿到题先把代码整体通读一遍搞清楚每个变量的含义用铅笔在代码旁边写下dp[i]表示什么last_end表示什么。这一步花五分钟但能避免后面所有空都填得似是而非。5.3 复杂度填空的判据复杂度这一问基本是送分题判断方法很直接数循环的嵌套层数。单层循环O(n)两层嵌套O(n²)如果内层循环的边界随外层变化比如快排的分区那就是O(nlogn)。递归算法看递归树的高度和每层的工作量二分查找是O(logn)归并排序是O(nlogn)。但有一个常见的陷阱题目里的代码可能带有剪枝或者提前退出这时候最坏复杂度仍然要按完整情况写。还有一种情况是空间复杂度里忽略了递归栈的消耗递归深度为n的话空间复杂度至少是O(n)。这两点我在练习时都栽过写答案时多问自己一句最坏情况是什么能避掉大部分错误。5.4 填不出来时的部分分策略算法题最忌讳的是空白。哪怕完全看不懂逻辑也有几类空是能猜的循环变量的初值通常是0或者1取决于数组下标从哪开始累加器的初值通常是0乘积的初值是1比较条件里的符号还是可以通过代一个小例子验证返回值的表达式通常和累加器或者dp数组的最后一个元素有关。我通常在时间不够的时候会把能填的空全部填上不确定的也写一个最可能的答案绝不留空。案例题是按空给分留空等于主动放弃写错至少还有概率蒙对这两者的期望值完全不同。6. 面向对象代码填空靠读框架而不是背语法6.1 类名和方法名本身就是提示第5题给的是完整度较高的Java或C代码挖空的位置往往是方法体内部、继承关系中的抽象方法实现、或者接口的调用处。它的难点不在语法因为语法部分通常不会挖空而在理解这套代码的设计意图。读懂设计意图的入口是类名和接口名。题目里如果出现AbstractHandler、ConcreteHandlerA、ConcreteHandlerB这样的命名你不需要看代码内容就能判断这是责任链模式出现Strategy和几个XxxStrategy就是策略模式出现Observer、Subject、notify就是观察者模式。命名是出题人留给你的地图顺着地图走就不会迷路。6.2 设计模式在题目中的常见埋点案例题里的设计模式不会考得很深通常是识别填空的组合。模板方法模式的埋点在于父类定义了一个流程方法里面依次调用几个抽象方法子类只需要实现抽象方法——挖空往往就在子类的具体实现里你需要根据子类的业务语义写出来。策略模式的埋点在于上下文类持有一个策略接口的引用挖空常在上下文类的构造函数或者执行方法里你需要填的是把具体策略传进去或者调用策略的某个方法。除了设计模式还有一些纯面向对象概念的填空比如多态调用、抽象类的实现、接口方法的实现。这类空的关键是看方法签名是否匹配——返回类型、参数列表必须完全一致差一个类型就是编译错误。填空时把上下文的调用语句翻出来看一眼参数是怎么传的返回值是怎么用的照着写就不会错。6.3 时间不够时的止损方式代码填空题有一个特点几个空之间有时存在依赖关系前面的空填错了后面的空跟着错。所以策略上是先做独立性强的空比如构造函数里的赋值、简单的getter/setter、明显的循环边界这些空不依赖其他空的答案。那些需要理解整套流程才能填的空放到最后。如果实在读不懂某段代码还有一个笨办法看这个空所在方法的调用方调用方传了什么参数进来又拿返回值做了什么反推这个方法该干什么。这个思路在调试真实代码时同样适用本质上就是从使用方推断实现方。我在练习时用这个方法救回过不少空尤其是那些涉及集合操作的填空。7. 手写规范、错题归档与临场节奏7.1 手写图的规范细节机考环境下画图是用鼠标拖拽完成的这反而是个好消息因为线条会自动对齐箭头方向不会画歪。但即便如此仍然有几个规范必须遵守外部实体用矩形加工用圆角矩形或圆形数据存储用两条平行线开口矩形数据流用带箭头的线并标注名称。图的布局要尽量从左到右数据流向不要来回穿插因为阅卷时看不清流向会直接影响判断。还有一点容易被忽略图的编号。分层数据流图的加工要有编号0层图里的加工编号1、2、3展开到1层图就变成1.1、1.2、1.3。这个编号体系是父子图对应的依据漏编或者编号不对应会让阅卷人无法确认你画的是哪一部分从而影响整题的得分。我在练习时会专门检查一遍编号的连续性这个动作只需要十几秒。7.2 错题复盘要按失分类型归档而不是按题号大多数人复盘的做法是把错题重做一遍做对了就算过了。这个方式对案例题效果有限因为案例题的失分原因高度分散同一道题可能既错在概念理解也错在书写格式。更有效的做法是建立一个失分类型表把每次的错误归到下面这几类里失分类型具体表现改进动作概念判定错误该建实体的画成了联系多重度标反回到教材对应章节重画三个同类例子术语不统一图里写报修人题面写报修人员养成先列词表再画图的习惯方向性错误箭头反向、include与extend搞混整理一份方向速查表背下来要素遗漏忘标主键下划线、漏写外键参照交卷前按清单逐项核对时间不足最后一题空白或只写了一半严格计时训练按题限时这张表的用处在于它可以告诉你自己的问题是知识型的还是习惯型的。知识型问题需要回去补对应章节习惯型问题只需要建立检查清单。我自己的统计是习惯型失分占了总失分的四成以上这些分本来是完全不用丢的。7.3 按套计时训练别拿单题练单题练习能解决知识点问题但解决不了节奏问题。案例题的节奏感非常关键因为五道题的阅读量加起来接近一万字中间还要画十几张图。我建议至少完整地做三套模拟全程计时中间不查资料、不中断。做完之后不要立刻对答案先自己给自己打分估一估每题能拿多少再对标准答案。这个自评的过程能训练你对得分点的敏感度——估得越准说明你越清楚阅卷的判分逻辑。计时训练还有一个附带好处它会暴露你在哪类题上超时。有人是数据流图读题慢有人是算法题卡壳有人是代码填空反复犹豫。这些弱点在单题练习里根本看不出来只有在完整的时间压力下才会显形。7.4 几个考场上的小动作最后分享几个我在考场上养成的习惯都是些不起眼但确实能救分的小动作。第一个是开考后先花两分钟把五道题浏览一遍确认题号和题型有没有变化尤其注意有没有出现往年没见过的题型——如果第3题不是UML而是别的你的时间规划就得当场调整。第二个是每道题答完后用半分钟做一次三查查名称是否和题面一致查方向是否画反查有没有漏标主键或外键。这三个动作加起来不到两分钟但能挽回的分数往往在五分以上。第三个是算法题的填空一个空都不要留。哪怕只是把循环变量的初值写上去也可能踩到一个得分点。案例题的判分是按点给的空白是零概率得分瞎写至少还有概率。第四个是不要在某一问上死磕超过八分钟。案例题的每一问分值都不高卡住一个空丢掉的时间可能足够你做完后面两问。遇到实在想不出来的写个最可能的答案先占位把剩下的做完再回头。这些经验谈不上高深都是练出来的肌肉记忆。案例题这门东西说到底是熟练度的问题——规则就那么些题型就那么五类练够三四十道考场上的大部分不确定感都会消失。真正难的从来不是题目本身而是愿不愿意动笔把每一道题完整地写一遍。