注此篇博客只记录三次单部电梯调度程序。其他小题第一次大作业其他题目总结里写有我的学习记录。三次迭代历时21天。其实感觉就第一次辛苦一些在电脑前坐了12个小时弄清运行逻辑后后面两次迭代都没啥问题很快都能通过。此片博客是对上篇的一次续写小韩的blog。在此向一路遇到的所有朋友、老师致谢目录一、前言二、设计与分析三、第一次实验四、第二次迭代五、第三次迭代六、代码性能分析1、针对核心问题的改进建议2、代码结构与可维护性优化3、长期质量保障措施七、踩坑总结1、end不区分大小写2、一种特殊情况的电梯运行逻辑3、第二次迭代数据处理八、个人感想一、前言此次单部电梯调度程序涉及到的主要知识点有面向对象编程、数据结构、控制流与逻辑判断、字符串处理、状态管理。从Java初学者的角度考虑其实难度属于中等偏上主要用为逻辑复杂度高、涉及多对象协作等问题。二、设计与分析看看我这篇博客 小韩的blog自家兄弟们给土狗点点赞吧。里面包含了原题以及我对题目的理解。三、第一次实验依然上面那篇blog。我设计了三个类分别为电梯类、请求类、乘客类。相当于把电梯类混在电梯类里。四、第二次迭代第二次迭代加了如下这些条件无非就是先处理下输入数据再将数据存入队列中相信大家都能理解展示伪代码如下//判断输入是否合法 boolean isValidInput(int floor) { 判断是否符合楼层范围 }void addInnerRequest(int floor) { //如果内部请求队列队头元素与当前楼层不同加入队列 如果不是连续相同输入则内部请求入队 } void addOuterRequest(Request request) { //如果外部请求队列队尾元素与当前楼层不同加入队列 如果不是连续相同输入外部请求入队 }五、第三次迭代第三次迭代加了如下这些条件第一是外部请求输入数据格式变了第二是每处理完一次外部请求就将此外部请求的“请求目的楼层”加入到当时的内部请求队列的队尾。伪代码分别如下if (str.matches(^\\d,\\d$)) { // 处理外部请求 楼层,目标楼层 空格分割 int floor 楼层 int target 目标楼层 if(elevator.isValidInput(floor) elevator.isValidInput(target)){ requestQueue.addOuterRequest(new Request(floor, target)); } }//yes标志为当前选取的请求为外部请求 if(!requestQueue.outerQueue.isEmpty()yes1){ 将外部请求的目标楼层加入内部请求队列 requestQueue.outerQueue.remove(); yes0; }六、代码性能分析使用IDEA自带插件plantuml4idea分析类的设计参考如下Passenger对应代码里RequestQueue。这插件还是比较好用的类似于Latax对于编写文档的作用。使用SourceMontor分析代码如下各行列含义如下列名含义说明Checkpoint Name检查点名称用于标识本次代码度量的版本 / 节点此处为 Checkpoint2。Create...代码度量的创建日期2025 年 11 月 17 日。Files参与度量的文件数量此处仅 1 个文件。Lines代码总行数包含空行、注释、语句等共 301 行。Statements可执行语句数量共 143 条仅统计实际执行逻辑的代码行。% Branches分支覆盖率15.4%表示if-else、switch等分支逻辑被测试用例覆盖的比例该值越低说明分支测试越不充分。Calls函数 / 方法调用次数共 88 次。% Comments注释比例15.0%注释行数占总行数的比例反映代码的可理解性比例适中利于维护过高 / 过低都可能有问题。Classes定义的类数量共 4 个。Methods/Class每个类的平均方法数4.50体现类的职责划分密度。Avg Stmts/Method每个方法的平均语句数6.72语句数过多的方法可能逻辑过于臃肿需考虑拆分。Max Complexity代码的最大复杂度8复杂度越高表示逻辑越复杂如嵌套循环、多层条件分支多维护成本越高。Max Depth代码的最大嵌套深度4如循环或条件的嵌套层数过深会降低可读性。Avg Depth代码的平均嵌套深度1.46整体嵌套层级的均值。Avg Complexity代码的平均复杂度2.55复杂度的整体均值辅助判断代码逻辑的整体复杂度水平。1、针对核心问题的改进建议1提升分支覆盖率当前 15.4%需显著提高补充测试用例针对if-else、循环条件等分支逻辑补充未覆盖的测试场景如边界值、异常输入、特殊分支路径。例如存在if (x 0) { ... } else {... }需分别测试x0、x0、x0的情况。对循环逻辑需测试 “循环 0 次”“循环 1 次”“循环多次” 的场景。2. 控制代码复杂度最大复杂度 8需警惕拆分高复杂度方法若某个方法复杂度达到 8通常建议控制在 10 以内核心逻辑可放宽至 15需拆解逻辑将嵌套的条件判断如if (a) { if (b) { ... } }拆分为独立函数如isValidA()、isValidB()。对多分支switch考虑用 “策略模式” 替换将每个分支逻辑封装为独立类。减少嵌套深度当前最大 4嵌套过深如 “循环套条件套循环”会降低可读性可通过提前return减少。此处主要与电梯运行逻辑有关如下图若采用第二张图片的逻辑此处代码复杂度会更低嵌套深度会更低。2、代码结构与可维护性优化1平衡注释比例当前 15.0%可以针对性补充避免 “无意义注释”删除 “// 声明变量 i” 这类冗余注释。补充关键注释对复杂逻辑例如决定电梯目标楼层添加 “为什么这么做” 的注释。对类、方法添加注释说明功能、参数、返回值、异常场景。2优化类与方法设计警惕 “过大的类”若某个类的方法数远高于 4.5检查是否职责过于繁杂需按 “单一职责原则” 拆分。控制方法长度若个别方法语句数远高于 6.78拆分为小方法。3、长期质量保障措施1引入代码审查机制重点检查分支逻辑是否完整、复杂度是否合理避免 “一次性代码”。2自动化检查在 CI/CD 流程中集成静态分析工具设置门槛如分支覆盖率≥80%、最大复杂度≤10未达标则阻断构建。3定期重构对频繁修改的模块按上述建议重构避免复杂度过度增长。七、踩坑总结个人运气比较好加上有前辈们的铺垫老实说没踩过什么坑。我这倒是总结了同学们一起讨论时碰到的一些坑。1、end不区分大小写没啥好说的。2、一种特殊情况的电梯运行逻辑1 105,DOWN8end上面这条测试样例电梯会先去处理8再去处理5,DOWN因为电梯第一次经过5楼时电梯的运行方向向上无法处理5,DOWN。这对应电梯运行逻辑第二张图片里的第一条if语句。3、第二次迭代数据处理题目要求只需将连续的的相同请求按要求处理例如333或者5,DOWN5,DOWN。不是将所有输入存入后再对两个队列做去重操作。解决起来也很简单每次向队列中插入数据时将当前元素与队尾元素做比较即可。八、个人感想一个PTA上的题目写了300行代码三次加起来差不多900行还是挺有趣的一次体验。学到了很多东西正则表达式、队列及其各种方法、类的设计依照准则、面向对象的设计思维等等。非常感谢这次大作业感谢这次学习、与同学朋友们交流学习的机会。至于教学反馈给老师提意见就一条写博客只总结最后一题即只写电梯调度题目的博客写其他的有点多并且学习效率较低。当然我也不禁询问自己如果未来的工作生活或者说日常生活是以这样一种工作强度、工作习惯去度过度过那十五年或者二十年的时光我是否会愿意呢或者说我是否会快乐呢无论如何如果你看到这里我祝你快乐。谢谢你我的好朋友。