对大作业电梯三次测试的感想与总结

题目集5~7 单部电梯调度——三周迭代测试

一.前言：
由于没有写类似迭代性测试代码的经历及经验，导致在一开始写电梯代码时就遇到了困难，再加上在第一次电梯代码测试几乎没人过的情况下，虽然有了电梯分析详解但仍未了解其内部逻辑，自己就没有了能够通过的勇气，于是在代码只写了一半的情况下我就有了放弃的念头。

但由于电梯测试大作业是迭代的，于是在第二次测试中写完了，但是代码只有一个测试点，而且我也一直在给的基本测试点能不能过中漂浮，毫无办法，就更别说其它更深层的测试点了。

最后一次测试虽然分了控制，需求，电梯等不同类，代码仍错误。这电梯代码并没有一开始想的那么轻松，对于刚入Java的我有一定的挑战难度。
二.设计与分析-三次迭代做出的改变

1.第一次迭代

对类的分析：虽然代码只做了一半，但该有的类还是写出来了
• 类：
队列请求，行动方向等都在这个类里面。
• Main类：
对输入数据进行处理。
小总结：在第一周已经见识到了电梯程序的强度，已经产生了畏惧放弃的心理了，满是血与泪。
2.第二次迭代

类图

对类的分析：
在第二次迭代中由于题目要求必须有不同的类来实现电梯程序，虽然代码还是编译错误或答案错误，但是相对第一次有了比较大的提高，毕竟还是实现了从零到有的飞跃，而且对于类的单一职责有了更深刻的了解和使用，通过拆分更多的类能够有效提高代码的复用性并且代码逻辑更加清楚了。

Main类：
对输入数据进行处理。
• Controller类：
对电梯及请求类进行相关操作的类
• Elevator类：
设置电梯相关信息以及楼层相关信息类
• RequestQueue类：
用于处理外部与内部的楼层信息的类
• Floor类：
关于楼层的信息的处理以及行进方向的处理

小总结：在以上类的基础上我还加入了枚举类
enum Direction { UP, DOWN, IDLE }
enum State { MOVING, STOPPED }，这还是挺有作用的

第三次迭代

类图

对类的分析：

相对于之前两次迭代后的改变：乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>

对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
Main类：
对输入数据进行处理。
• Controller类：
对电梯及请求类进行相关操作的类
• Elevator类：
设置电梯相关信息以及楼层相关信息类
• RequestQueue类：
用于处理外部与内部的楼层信息的类
Passenger类：
之前的floor类改成了乘客类，满足了规则变更的需要。
小结：对于电梯的运行规则和代码逻辑有更加深刻的理解，对于使用不同的类及其职责所在更为深刻。

最终代码的 SourceMonitor 报表解读

字段 数值 解读
Lines 482 文件行数接近 500，Main.java 承载了过多核心逻辑，建议按功能拆分为多个文件（如 RequestHandler、ElevatorLogic）。
Statements 216 业务逻辑密集，但注释与空行占比极低（仅 0.4%），代码可读性差。需补充注释以提升维护性。
Percent Branch Statements 17.6% 分支逻辑占比接近 20%，整体可控，但需关注嵌套过深的方法（如 Controller.recept_twoList()）。
Method Call Statements 95 方法调用频繁，跨类依赖较强，需检查接口设计是否合理，避免过度耦合。
Percent Lines with Comments 0.4% 注释几乎空缺，后期维护困难。建议为目标方法（如核心算法）添加详细 Javadoc。
Classes and Interfaces 12 单文件包含 12 个类/接口，严重违反单一职责原则。应分包管理（如 model、controller、util）。
Methods per Class 3.50 类方法数量合理，但文件内类过多导致职责混乱。需拆分文件并重构模块化设计。
Average Statements per Method 3.45 方法长度较短，但文件整体过长。建议合并工具类方法或抽取通用逻辑。
Name of Most Complex Method Controller.recept_twoList() 输入解析逻辑集中，圈复杂度高达 20，远超安全阈值（10），亟需拆分。
Maximum Complexity 20 最复杂方法（recept_twoList）包含多层嵌套与分支，测试和维护成本极高。
Maximum Block Depth 8 嵌套深度达 8 层（如多重 if-else），可读性极差。需通过“早返回”策略减少嵌套。
Average Block Depth 2.39 平均嵌套深度合格，但局部方法（如 recept_twoList）深度超标，需针对性优化。

总结
当前代码实现了核心功能，但存在高复杂度方法、注释缺失和局部深层嵌套问题。建议优先重构方向决策和请求处理逻辑，补充文档，并简化集合操作。通过优化，可显著提升可维护性和扩展性，降低后期迭代风险。

三.踩坑心得-三周的折磨及感想

1.要在一开始就抓步伐--在一开始看到大作业是电梯时感觉应该不会太难吧，于是我并没放在心上，想着到周末再搞，但是星期五的晚上同学们的讨论让我明白了电梯的难度其实挺大的，毕竟没有一个人拿满分，虽然许多同学通过了给出的测试点，由于我的起步较晚导致了第一次迭代代码也没写完。
2.了解电梯的运行规则--在给出的电梯运行详解中我了解了大概运行规则代编写代码与测试点还是有点不同，
掌握了动态调整电梯方向的核心逻辑，理解了如何平衡响应时间和运行效率。
3.尽量多分类来实现一个程序--使用了Passenger,RequestQueue,Elevater,Controllerd类实现不同职责，让代码逻辑更清晰了，代码可维护性显著提高。
4.注释--关键逻辑添加注释，如方向决策的优先级说明，便于协作维护，不会让自己看懂代码都要费好多时间和精力。

四.改进与展望

1.有些方法代码重复性挺高的，应该尽量使用精简的方法和代码来代替不然在更长的代码证容易出现错误而且不易修改，代码可读性大大降低，尽量多用些有用的方法来代替一些复杂的ifelse代码。
2.尽量使用并发挥出类的单一职责性的优势所在提高复用性，提升代码的清晰度和可维护性，这对于面向对象程序设计还是很重要的。
3.对之后的练习态度更加认真，把Java的语法学好及面向对象设计理念根固于心，并且认真对待每一次大作业及线上课程。

五.总结

通过本次电梯调度程序的开发，不仅巩固了Java面向对象编程的核心技能，还深入理解了调度算法的实际应用。在解决输入解析、方向决策、队列管理等复杂问题的过程中，提升了逻辑设计能力和调试技巧。未来在类似项目中，可进一步探索多电梯协同调度、动态权重调整（如高峰时段优先响应高层请求）等高级功能，持续优化系统性能。拿到题目要先思考类的划分比如是否应该加入控制类的设计。
。