第一次blog作业

一、前言：
这三次“单部电梯调度”的题目无疑使我受益匪浅，三次迭代设计，让我了解了类设计及多类设计，并在学习过程中熟悉了一些Java的基础语法知识，以及java编程知识，如：类与对象、枚举与泛型、正则表达式、集合框架等，以及了解了何为单一职责原则。当我第一次尝试此类问题时，无疑对我产生了巨大的挑战，难度的跳跃让我无从下手，我也逐渐开始了解此类设计，但经过大量尝试后，我的代码始终与测试案例所给出的预期结果有所出入，以致于我在之后的第二、三次题目中愈发困难，接下来我将展现我存在的问题。
二、问题分析：
(1)第一次作业：
第一次作业对我而言是最困难的一次，因为毫无头绪。

1.存在的逻辑问题：
问题一：我并未考虑到电梯在移动中应该优先处理同方向的请求，以致于一些请求被延后导致最终结果超出预期。
问题二：同一楼层的多个请求不能够用代码整合，导致结果杂乱，且代码复杂，可读性差。
问题三：不能够正确识别电梯应该行进的方向，导致结果一直与预期不符合，电梯错误地保持上行方向。
我应当还存在着相当多的问题没有发现，可我实在是没有头绪去处理，这也让我的结果与预期不符。
2.分析思路：
我一开始想直接逐个处理请求，按按钮顺序让电梯上下跑。比如收到5层的请求就让电梯直接上5层，结果发现这样没法处理同方向的请求，比如上行时3层有人按上行。
然后试着给请求分方向：电梯上行时只处理上方请求，下行时处理下方请求。但实现时发现难以同时处理内外请求的匹配，比如电梯内有人按5层，外面3层有人按上，电梯上行时要同时响应这两个请求。
后来改用两个队列：一个是当前运行方向的请求队列，一个是相反方向的队列。电梯始终先处理当前方向的请求，处理完再反转方向处理另一队列。每次移动楼层时检查是否有需要停止的请求，这样就能实现顺路带人。但代码中需要特别注意请求方向的判断和队列切换的条件，容易漏掉边界情况，比如最高层有人按上无效。
3.分析SourceMonitor报表：

优点：
代码行数为：184，相对简洁。
方法平均语句数为：6.50，方法长度较为适中。
缺点：
最大复杂度路径值为：15，如Elevator.run()方法（位于第50行）逻辑复杂，可读性和维护性差。
百分比分支语句为：25.2，分支判断较多，逻辑不够清晰。
从报表可见，Main.java中的Elevator 类包含enqueueInner、enqueueOuter、run等核心方法，但存在以下设计问题：
1.输入处理、队列管理和调度算法高度耦合，违反了单一职责原则。
2.run 方法作为电梯主循环，需处理方向判断、楼层移动和停靠逻辑，代码冗长（推测实际代码量较大，可能超出合理范围），导致维护困难。
3.仅1.6%的代码行含注释，可读性进一步降低。
(2)第二次作业：

1.存在的逻辑问题：
问题一：在 findNextUpFloor 和 findNextDownFloor 方法中，遍历请求队列时，没有区分请求的方向与当前电梯运行方向的关系，导致可能会选择到不符合当前运行方向的楼层，从而使一些同方向的请求被延后处理。
问题二：对于同一楼层的多个请求，无论是内部请求还是外部请求，没有进行有效的合并处理。在shouldStop方法中，只是简单地判断当前楼层是否在各个请求队列中，没有对同一楼层的多个请求进行整合，导致代码逻辑复杂，可读性差。
问题三：在确定电梯运行方向时，findNextUpFloor 和 findNextDownFloor 方法返回值的逻辑存在问题。当没有合适的同方向请求时，返回值的处理不够准确，可能导致电梯在某些情况下错误地选择运行方向。
2.分析思路：
根据上一次的思路来写我发现难以下手，后来发现对于同一楼层的多个请求，应该考虑如何进行有效的合并处理，以简化代码逻辑和提高处理效率。在处理请求队列的操作时，要确保代码的健壮性，避免出现无效的移除操作。另外，在确定电梯运行方向时，要综合考虑各种边界情况，确保电梯能够正确地选择运行方向，避免出现错误的方向判断。
3.分析SourceMonitor报表：

优点：
代码行数为139，相对简洁。
总行数139（行业参考值<=200），未出现冗余代码，整体规模可控。
方法平均语句数为5.27，方法长度较为适中
方法平均语句数5.27（参考值<=8），逻辑块拆分合理，符合简洁性原则。
缺点：
最大复杂度为7，逻辑复杂且可读性差。
Elevator.determineDirection()方法（位于第19行）复杂度为7参考值<=5，存在多层嵌套条件分支（如电梯方向决策逻辑），维护成本高。
分支语句占比21.5%，逻辑不够清晰
分支语句占比21.5%（参考值<=15%）,表明代码中频繁使用if-else/switch.
类职责高度耦合，违反单一职责原则
Main.java中的Elevator 类包含以下耦合逻辑：
输入处理：通过enqueueInner/enqueueOuter 管理请求队列。
调度算法:determineDirection 方法实现方向决策逻辑。
主循环控制：run 方法需处理移动、停靠等操作，推测代码冗长且未拆分职责。
注释覆盖率极低，可读性差，仅2.2%的代码行含注释（参考值>=20%），尤其是复杂方法（如 determineDirection）缺乏解释，导致逻辑难以理解。
(3)第三次作业：

1.存在的逻辑问题：
问题一：代码在处理请求时，没有严格遵循优先处理同方向请求的原则。例如在 processUp 和 processDown 方法中，只是简单地从相应队列中取出目标楼层并移动电梯，没有考虑在移动过程中同方向其他楼层的请求。
问题二：在collectRequests方法中，将内部请求和外部请求简单地合并到上下行队列中，没有考虑这些请求与当前电梯运行方向的一致性，影响电梯的正常运行逻辑。
2.分析思路：
这一次作业我实在难有什么思路，写了一段时间结果毫无收获，甚至无法得到有效的运行结果。
3.分析SourceMonitor报表：

优点：
代码行数为158，相对简洁
总行数158（行业参考值<=200），整体规模合理，未出现冗余代码。
方法平均语句数为5.12，方法长度较为适中
每个方法平均5.12条语句（参考值<=8），逻辑块拆分清晰，符合简洁性原则。
缺点
最大复杂度为7，逻辑复杂且可读性差
ElevatorSystem.process()方法（位于第21行）复杂度为7（参考值<=5），存在多层条件分支或嵌套逻辑，维护成本高。
分支语句占比19.3%，逻辑不够清晰
分支语句占比19.3%（参考值<=15%），表明代码中频繁使用 if-else/switch
仅0.6%的代码行含注释（参考值>=20%)，尤其是复杂方法（如ElevatorSystem.process）无解释，导致逻辑晦涩难懂。
三、踩坑心得：
1.第一次看到电梯调度的题目时，我整个人都懵了。题目要求又长又复杂，完全搞不懂电梯到底该怎么运行，看测试样例也像看天书一样。一开始好几天，我只能勉强把电梯类的基本框架搭起来，至于电梯怎么工作的核心代码，根本不知道从哪开始写。后来多亏老师在群里不断给提示，我才慢慢明白电梯运行要用 LOOK 算法，虽然最后还是没通过测试，但至少知道问题出在哪了。
2.写代码的时候，最让我头疼的就是程序报错和运行特别慢。程序报错很多时候是输入请求出问题，因为请求里带着<>符号，我用字符串读数据，经常读错，要么字符串太长，要么没把数字读对。这个改起来还算容易，研究下怎么按位置读取字符就行。我猜是电梯运行的核心逻辑写错了，导致程序一直在循环，停不下来。每次改这个问题，改完这里又错那里，就算感觉改好了，一测试答案还是不对。像题目集7里，有个判断电梯该往哪走的循环，我把逻辑弄错了，让电梯一直跑停不下来，找了好久才发现问题，可惜最后也没彻底解决。
3.在题目集5里，我把所有电梯运行的代码都塞在一个类里，代码又长又乱，后来想改都找不到地方。到了题目集6和7，要求把功能分开写，我之前写的代码基本都用不上了，只能重新写。虽然重新写代码很麻烦，但分开之后，代码看起来清楚多了，改错误也方便了不少，只可惜我还是没把代码改到能通过测试。
四、自我反思：
1.我写代码时经常将不同类写得紧凑，导致可读性差，以后写代码，我要把不同功能拆得更细，让代码之间的关联别那么紧密，这样不仅好理解，以后还能重复用。
2.我写代码时，经常偷懒用单个字母当变量名，过几天自己都不知道这些变量名啥意思了，我以后要按规范给变量、类起名字，方便以后修改。
3.我之前写的代码几乎没注释，时间一长，自己都读不懂了。以后写代码，我要给重要的地方都加上注释，记录下当时是怎么想的，这样以后再看就能很快明白。
4.我经常会困于一种方法而钻牛角尖，导致浪费太多时间，就算写出代码，代码也缺乏可读性，且难以运行，我以后应该多试着转变思维。
五、总结：
这三次电梯调度作业，对我这个 Java 新手来说，简直是 “地狱难度”。虽然到最后也没通过测试，但我也学到了不少东西。我明白了写代码要把功能分开，不能一股脑全堆在一起；也知道了读数据、处理逻辑时要仔细，不然很容易出错。
最开始做题目集 5 的时候，我完全找不到方向，感觉自己根本不可能完成。后面两次作业虽然核心逻辑差不多，但我还是没能改对代码。每次发现错误、尝试修改的时候，都特别煎熬，但也正是这些过程，让我慢慢对 Java 编程有了更多的认识。
我知道自己还有很多不足。对编程算法了解太少，遇到复杂问题就没思路；Java基础也不扎实，很多语法和用法还不熟练。在以后的学习中，我希望能多练习，把基础打牢，学会分析问题、找到解决办法。真希望以后再遇到电梯调度这类问题时，我能不再手忙脚乱，而是能一步步写出正确的代码，顺利通过测试！
建议：
希望老师能多给一些测试数据，这样我就能知道代码到底错在哪，也有修改的方向。
每次作业提交结束后，希望老师能告诉我们代码主要的问题在哪。