PTA电梯调度程序5~7总结性Blog

一. 前言
三次题目集难度分层明显，最后一题与之前的题有很大的差距，我认为这是通过让学生在前几题快速建立信心，再以高难收尾激发深度思考。三次题目集题量均较小，聚焦问题的质量而非数量。首次题目集聚焦正则表达式应用，通过校验题训练正则表达式，其中最后一题因需自主设计类结构且无类图提示，同时我没能理解其运行逻辑，成为三次中难度最高的挑战；第二次题目集转向多类设计，要求根据给定类图实现复杂系统，类图的存在降低了架构设计难度，但仍具挑战；第三次题目集为综合应用，融合正则表达式与多类设计，提供类图辅助，难度中等偏低。
二. 设计与分析
1.第一次电梯题目的设计与分析
（1）题目要求：编程实现电梯程序，对于乘客的输入，分为外部请求和内部请求，然后分别加入到外部，内部请求队列中去。再根据队列以及算法来确定电梯的运行方向，每次移动一个楼层，判断该楼层是否应该停下来处理请求，如果有将两个队列中的队头的该楼层请求全部出队。最后打印出电梯每次运行的楼层和状态。
（2）类：第一次写这个题时，我因为没有摆正心态，将代码只写在了Main中，导致了我没能完成它。那种焦虑感至今记忆犹新，然后我选择AI，但我发现这是一条错误的路。
（3）Source Monitor分析结果

方法具体复杂度

（4）分析与心得
这是AI帮助下的代码，可以看出这个代码几乎大部分都合格，但是它有一个致命的漏洞，它无法处理多次同样楼层的请求，它会先到达最高层，在处理第二次请求。
如果我不使用AI，我应该可以完成这题目，但我也从中获取了教训，为我第二次电梯题目的完成打下了基础。
2.第二次电梯题目的设计与分析
（1）题目要求：新增处理如下情况：乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数；乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>。
（2）类图：我完全是以参考类图完成

每个类的功能：

• Elevator 类：表示电梯的实体类，包含电梯的当前楼层、运行方向、状态（移动或停止）以及电梯的最低和最高楼层。
• ExternalRequest 类：表示外部乘客的请求，包含请求的楼层和方向。
• RequestQueue 类：管理电梯的请求队列，包括内部请求（电梯内乘客的请求）和外部请求（电梯外乘客的请求）。
• Controller 类：控制电梯的运行，处理请求队列中的请求，决定电梯的运行方向和停靠楼层。
  （3）Source Monitor分析结果：
  
  方法具体复杂度
  
  （4）分析与心得
  通过分析，我发现了以下几个关键问题，这些问题不仅反映了我当前的编码习惯，也为我未来的代码优化提供了明确的方向。

1. 注释缺失：代码中几乎没有注释，这表明我在编写代码时缺乏添加注释的习惯。缺乏注释可能导致开发者难以理解代码的意图和逻辑，增加了代码的维护成本。因此，我需要培养在编写代码时添加详细注释的习惯，以提升代码的可读性和可维护性。
2. if-else嵌套层数过多：结果显示，代码的最大深度（Max Depth）和平均深度（Avg Depth）都超过了4.0，这表明代码中存在过多的if-else嵌套。过多的嵌套会导致代码的可读性下降，增加理解和维护的难度。
3. 函数平均语句数较少：每个函数平均包含的语句个数较少，这可能意味着代码的粒度过于细化，导致函数数量过多。
4. 代码复杂度过高
   最大复杂度（Max Complexity）过高，这表明代码中存在一些过于复杂的部分,高复杂度的代码通常难以理解和维护，容易引入错误。
   这次代码分析让我对自身的编码能力有了更清晰的认识，也为我指明了未来代码优化的方向。
   2.第三次电梯题目的设计与分析
   （1）题目要求：乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>。
   对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
   （2）类图：我完全是以参考类图完成
   
   每个类的功能：

• Elevator 类负责管理电梯的状态和属性。
• Passenger 类表示乘客的请求，包括起始楼层和目标楼层。
• RequestQueue 类管理乘客的请求队列，区分内部和外部请求。
• Controller 类控制电梯的运行，根据乘客请求确定电梯的移动方向和停靠楼层。
• Main 类作为程序入口，读取用户输入并启动电梯控制系统。
  （3）Source Monitor分析结果：
  
  方法具体复杂度
  
  （4）分析与心得
  这次的代码质量和上一次的差不多，就是变化了输入的格式和一部分运行逻辑。

1. 注释缺失：代码中几乎没有注释，这表明我在编写代码时缺乏添加注释的习惯。缺乏注释可能导致开发者难以理解代码的意图和逻辑，增加了代码的维护成本。因此，我需要培养在编写代码时添加详细注释的习惯，以提升代码的可读性和可维护性。
2. if-else嵌套层数过多：结果显示，代码的最大深度（Max Depth）和平均深度（Avg Depth）都超过了4.0，这表明代码中存在过多的if-else嵌套。过多的嵌套会导致代码的可读性下降，增加理解和维护的难度。
3. 函数平均语句数较少：每个函数平均包含的语句个数较少，这可能意味着代码的粒度过于细化，导致函数数量过多。
4. 代码复杂度过高
   最大复杂度（Max Complexity）过高，这表明代码中存在一些过于复杂的部分,高复杂度的代码通常难以理解和维护，容易引入错误。
   这次代码分析让我对自身的编码能力有了更清晰的认识，也为我指明了未来代码优化的方向。

三.踩坑心得
在这三次电梯题目编程过程中，踩过的坑不计其数。
1.过度依赖 AI 的后果：第一次面对电梯题目时，由于对自身能力缺乏信心，加上时间紧迫，我几乎完全依赖 AI 生成代码。 原以为这样能快速完成任务，却忽略了对代码逻辑的深入理解。当发现代码存在无法处理重复楼层请求的致命漏洞时，我甚至都不知道从何处入手修改。因为没有经历独立思考和调试的过程，我对电梯运行的逻辑、队列处理机制等关键知识点依旧模糊不清。这不仅浪费了大量时间，还让我错失了一次锻炼编程思维的宝贵机会。此后，我深刻认识到AI 可以作为辅助工具提供思路，但绝不能替代自己的主动思考和实践。
2.类设计与功能划分的混乱：在代码编写过程中，我常常对类的设计和功能划分感到困惑。尤其是在第一次自主设计类结构时，由于缺乏经验，没有清晰规划每个类的职责，导致多个类之间功能重叠、相互依赖。比如，将电梯请求处理的部分逻辑同时写在了RequestQueue类和Controller类中，这使得代码结构变得混乱不堪。在调试时，一个小小的功能修改就可能引发其他地方的错误，且很难快速定位问题根源。为了解决这个问题，我花费了大量时间重新梳理代码逻辑，参考设计模式对类进行拆分和重构，明确每个类的边界和功能。这个过程让我明白，在编程前做好类的设计和规划至关重要，它是保证代码质量和可维护性的基础。
3.在使用get方法来取出队列头部来判断电梯的运行方向的时候没有考虑到队列可能为空的情况，导致提交了几次都显示我非零返回。
四.改进建议
针对上述出现的问题，我提出以下改进建议。首先，在编码前要做好充分的准备工作，仔细研读题目要求，梳理逻辑思路，绘制清晰的类图和流程图，明确各个类的职责和交互关系，避免在编写过程中思路混乱。其次，养成良好的编码习惯，及时添加注释，合理控制 if - else 语句的嵌套层数，优化函数设计，提高代码的可读性和可维护性。再者，加强代码审查，在完成代码后，认真检查代码的逻辑是否正确，是否符合设计要求，也可以与同学交流，互相审查代码，从不同角度发现问题。最后，定期对代码进行重构和优化，随着编程技能的提升和对问题理解的深入，不断改进代码，使其更加高效和完善。
五.总结
通过这三次电梯题目编程，我在编程技能和思维方式上都有了很大的提升。从最初的手足无措到逐渐能够理清思路，从频繁出错到学会从错误中总结经验，每一次的挑战都让我更加成熟。虽然在过程中暴露出了很多问题，但这些问题也为我指明了前进的方向。在未来的编程学习中，我会牢记这些经验教训，不断改进自己的不足，注重代码质量，培养良好的编程习惯，努力提升自己的编程能力，以更好地应对各种复杂的编程任务。