关于迭代电梯调度问题的总结与反思

一、前言：

5~7周的第五次到第七次PTA题目集迎来了截止，每个题目集中都有一道令人意难平的编程题——电梯调度问题，对于迭代加强的电梯调度问题对于我而言很难同时并没有电梯程序即没有通过测试点。每个题目集中都会有几道题目为此做一个简单的铺垫，然后让你对之后的题目可以增强信心、提高积极性去应对。

二、问题

第五次PTA作业中有对正则表达式的训练（验证码校验，QQ号检验）从而引出第五题电梯调度中需要运用到正则表达式的一个过程与引领，但是我并没有对正则表达式进行一个更加深入的了解与掌控，这促使我在看到第一眼电梯调度问题的时候产生畏难心理。

第一次电梯调度问题附录

1
 20
 <3,UP>
 <5>
 <6,DOWN>
 <7>
 <3>

 end
楼层最小值：1
楼层最大值：20
电梯外：3楼向上请求
电梯内：去5楼
电梯外：6楼向下请求
电梯内：去7楼
电梯内：去3楼
输入结束标志

我第一眼看到附录的时候并没有任何头绪我看着“<>”以及里面的数字以及“up”和“down”脑子中很凌乱，不知道该怎么写怎么去设计思路也并没有想到需要去使用正则表达式，构思在那个时候已经离我很远了，只有“我应该不会吧”“我肯定不会吧”围绕在我的心头。在我将被彻底击垮的时候，老师在课上对于电梯调度问题给了一些提醒比如说需要使用正则表达式并且写了一些代码供我们进行观察与借鉴，那节课有认真的听，并且认为自己**记住**了一些，但其实并没有。同时**去记**也成为了一个诟病——只听不做、只记不想，让我对这困难问题榨干了想法。

虽然有运行结果但是却不是正确的答案，没有通过测试点。
接下来到了第六次PTA作业，通过两次类设计的引入从而引出到pro版电梯调度（类设计）的版本

同时代码里有以下问题

项目目录（Project Directory）：D:\basic_code\day01\src\com\itheima\zz
项目名称（Project Name）：'uʌeʃəu
检查点名称（Checkpoint Name）：Baseline
文件名称（File Name）：BrokenElevator.java
总行数（Lines）：101
语句数（Statements）：71
语句百分比（Percent Statements）：21.1
方法相关
方法调用次数（Method Call Statements）：36
每行带有注释的百分比（Percent Lines with Comments）：2.0
类和接口数量（Classes and Interfaces）：1
每个类的方法数量（Methods per Class）：5.00
每个方法的平均语句数（Average Statements per Method）：10.80
复杂度相关
最复杂方法的行号（Line Number of Most Complex Method）：48
最复杂方法名称（Name of Most Complex Method）：BrokenElevator.run()
最大复杂度（Maximum Complexity）：8
最深块的行号（Line number of Deepest Block）：36
最大块深度（Maximum Block Depth）：5
平均块深度（Average Block Depth）：2.54

同样，界面下方有一个 Kiviat 图（Kiviat Graph）展示了平均复杂度（Avg Complexity）、方法数量 / 类（Methods/Class）、平均深度（Avg Depth）、平均语句 / 方法（Avg Stmts/Method）、最大深度（Max Depth）和最大复杂度（Max Complexity）等指标。
右侧有一个柱状图（Block Histogram），标题为 “语句与深度（statements vs. depth）”，展示了不同深度下语句的分布情况。

从这些数据来看，BrokenElevator.java文件存在以下可能的问题：

• 复杂度较高：最大复杂度为 8，最复杂方法是BrokenElevator.run()，这表明该方法内部可能有较多的逻辑分支，需要关注其可读性和可维护性。
• 方法较多：每个类有 5 个方法，且每个方法平均有 10.80 个语句，这可能意味着类的功能较为分散，有必要检查是否符合单一职责原则。
• 块深度较大：最大块深度为 5，平均块深度为 2.54，说明代码中可能存在较深的嵌套结构，这会影响代码的可读性，建议进行优化。

这次的PTA电梯调度也是提升了一个档次本希望这次电梯难题可以有所提升但是刚开始写合格程序的时候，依旧是是没有什么思绪，只让电梯希望可以上下跑可以从而完成上下楼的功能，但是对于里面乘客的要求，以及楼层的需求无法达成，运行结果出现少一层的现象以及问题。同时完全没想过会有重复请求这回事，直到测试时发现电梯在3楼开了三次门。同样也没有通过编程测试点。就像在玩数字游戏一样开始给你一些简单题目让你开心让你放心，后面的难题里面蕴含的思路根本想不出来，解决方法也越来越隐蔽。

同时这些代码里还有一些问题：

• 1、当最大复杂度达到 8 时，如Main.main()方法（Name Of Most Complex Method）所呈现的情况，这意味着该方法内部的逻辑可能极为复杂。高复杂度通常是由过多的条件判断、循环嵌套或者大量的逻辑分支导致的。这种复杂性使得代码难以阅读和理解，对于后续的维护和扩展工作带来了很大的挑战。
• 2、每个类包含 24 个方法是一个相对较高的数字，这违反了面向对象编程中的单一职责原则。一个类承担过多的功能意味着它可能涉及到多个不同的业务逻辑，这使得类的职责变得模糊不清。这样的类不利于代码的复用，因为它包含了太多特定于不同功能的方法。同时，在维护和扩展代码时，开发人员需要在一个类中处理大量的方法，增加了出错的风险。

接着来到了第七次PTA题目集做到这个题目集前面两题的时候就已经感觉到问题的不对劲，已经感觉到这次电梯调度更会让人深陷其中。结果也是,,,不出所料确实，电梯调度又来到了一个新的高度，这次我的畏难心理更加明显了在做到第二题的时候就已经开始害怕了题目给出了类与类之间的关系但是我看着这些类里面各种复杂的方法名以及一些他们其中的调用关系等等，

我确实很害怕以至于我甚至不想打开第三道电梯难题，前两次的失败让我确实对电梯难题产生了畏惧感，我只是对题目以及其中类图还有相关内容观察了一下但我确实没有了思路，所以对这次电梯难题真的放弃了。

三、心理历程和感悟

从一开始的正则表达式的引入我以为接下来的电梯难题也会简单，也啥都没想打开idea就是乱写代码，结果后面缓缓看，认真看这个题目的时候才发现这题目的内涵底蕴。接着就到了调试期，这个时期是最让人崩溃和难忘的前期大家都不会写电梯难题，idea不断的报红逐渐消磨着人的耐心，然后老师讲了一些正则表达式的相关知识和代码调试后很多人开始会写了但是，我以为只记不写和畏难心理的问题导致自己还是不会，于是我去问别人该怎么去做，然后也是在别人的帮助下可以运行但是问题还是存在楼层的减少输出数据的确实不能正确读取数据等等原因，答案还是有问题没有办法通过测试点。

四、总结

在参与这三次题目集的过程中，我遭遇了诸多困难，这些困难暴露出我自身存在的严重问题。“只记不写” 的陋习，让我在理论知识与实践操作之间产生了巨大鸿沟。课堂上，我认真记录老师讲解的每一个编程知识点、算法思路，自认为已经掌握得足够扎实。然而，当面对实际题目，尤其是电梯难题这类综合性较强的编程任务时，却发现自己连最基础的代码框架都搭建不起来。那些记录在笔记本上的知识，就像一个个零散的零件，无法组装成完整的机器，根本无法运用到实际编程中去。​
“畏难” 心理更是成为我前进道路上的 “拦路虎”。每当遇到复杂的编程逻辑、难以理解的算法，我就会本能地选择逃避，不愿花费时间和精力去深入钻研。这种心态导致我在面对三次电梯难题时，总是浅尝辄止，没有真正沉下心去分析问题、寻找解决方案。结果不仅浪费了大量时间，还让问题越积越多，最终陷入了恶性循环。​
“左耳进右耳出” 的学习方式，使得知识难以在脑海中形成深刻的印象。我常常只是机械地接收新知识，没有进行有效的思考和总结，导致学过的内容很快就遗忘了。在编程学习中，这种学习方式让我无法将前后知识融会贯通，遇到新问题时也难以从已有的知识储备中找到解决思路。​
这些问题对于程序员来说，无疑是致命的。在编程领域，创新思考和创造思路是核心竞争力。只有不断实践，才能将理论知识转化为实际能力；只有勇于面对困难，才能在挑战中不断提升自己；只有真正将知识内化于心，才能灵活运用并创造出新的解决方案。通过这三次题目集的教训，我深刻认识到，必须立刻采取行动，改变自己的学习方式和态度。我将制定详细的学习计划，增加实践练习的时间，强迫自己克服畏难情绪，积极主动地解决问题。同时，加强知识的总结和复习，确保每一个知识点都能真正被理解和掌握，希望能够有效、快速地改掉这些问题，成为一名合格的程序员。