电梯类大作业

一，前言

第一次写电梯类题目时，我丈二摸不清后脑勺，看到一个人都写不出，我怀疑是题目出错，心安理的地躺平。之后，面对阉割版的电梯类题目描述，我深感无力，我无法弄清老师给的主函数逻辑，索性放弃。就此，三个电梯类我都没写完。通过观看同学代码，我事后诸葛亮式的明白了。好，好，好，好无语的逻辑。

二，代码分析

第一次电梯程序：

以下是各项指标解读：

参数含义
Project Directory：项目目录，显示项目在本地磁盘的存储路径。
Project Name：项目名称，此项目为 CalendarAnalysis 。
Checkpoint Name：检查点名称 ，这里是 Baseline。
File Name：文件名，即 Main.java 。
Lines：代码行数，共 176 行。
Statements：语句数量，有 87 条。
Percent Branch Statements：分支语句占比，为 23.0% ，反映代码中分支逻辑（如 if - else、switch 等）的比例。
Method Call Statements：方法调用语句数量，有 57 条。
Percent Lines with Comments：含注释的代码行占比，为 14.2% 。
Classes and Interfaces：类和接口数量，共 1 个。
Methods per Class：每个类的平均方法数，为 9.00 。
Average Statements per Method：每个方法的平均语句数，是 8.67 。
图表含义
Kiviat Graph（雷达图）：展示代码多个维度的度量情况，包括注释占比（% Comments）、每个类的方法数（Methods/Class）、每个方法的平均语句数（Avg Stmts/Method） 、最大深度（Max Depth）、最大复杂度（Max Complexity）、平均深度（Avg Depth）、平均复杂度（Avg Complexity） 。
Block Histogram（柱状图 - 语句数与深度）：横坐标是代码块深度，纵坐标是对应深度的语句数量 ，反映不同深度代码块中语句的分布情况。

优点

简洁性尚可：从行数（176 行）和平均每个方法的语句数（8.67 条）来看，代码没有过于冗长和繁杂，方法粒度控制相对合理，没有出现单个方法代码量爆炸的情况，在代码阅读和维护上相对友好。
结构较清晰：每个类的方法数平均为 9 个，说明代码有一定的模块化意识，将功能拆分到不同方法中，利于代码的组织和理解，后续查找和修改特定功能代码相对容易。
注释比例适中：含注释的代码行占比 14.2% ，一定程度上表明代码有必要的注释说明，有助于其他程序员（或自己后续）理解代码逻辑，降低代码理解成本。

可改进之处

分支逻辑占比问题：分支语句占比达 23.0% ，说明代码中条件判断较多，可能导致代码逻辑复杂度过高，可读性和可维护性在长期可能受影响。可考虑是否能通过设计模式或优化算法来简化条件判断逻辑。
代码复杂度：从雷达图和柱状图来看，虽然不清楚具体复杂度数值，但可以推测代码存在一定复杂度。需进一步审视是否存在可以重构、简化的部分，比如一些重复的代码逻辑可以提取成公共方法，以降低复杂度，提高代码的可维护性和可扩展性。
方法调用管理：方法调用语句有 57 条，可能存在方法间调用关系复杂的情况。应梳理方法调用链路，确保调用逻辑合理，避免出现循环调用等不合理情况，以提高代码的稳定性和可测试性。

第二次电梯程序：

代码规模：

276 行不算特别庞大，但语句数达 189 条，说明代码较为紧凑。有 7 个类和接口，平均每个类 5.29 个方法 ，方法数量分布相对均衡，体现了一定的模块化设计思路，利于功能拆分与管理。

注释情况：

含注释的代码行占比为 0.0% ，这是非常不好的情况。缺乏注释会使代码可读性大打折扣，无论是其他开发人员接手，还是自己后续维护，理解代码逻辑都会变得困难，增加排查问题和扩展功能的成本。

分支语句占比：

分支语句占比 22.8% ，和常见合理范围相比处于适中水平，但仍需关注是否存在过度复杂的条件判断逻辑，可考虑优化以提升可读性和可维护性。

方法复杂度：

最大复杂度为 24 ，出现在 Controller.processRequest() 方法（第 123 行） ，此方法复杂度较高，可能包含大量嵌套逻辑、条件判断或循环等，后期维护极易出错，可尝试对其功能进一步拆分、重构。平均复杂度 2.41 尚可，但最大深度 8（最深代码块在第 146 行 ）、平均块深度 2.66 ，表明代码中存在一定深度的嵌套结构，可能影响代码的理解和调试。

方法调用：

118 条方法调用语句，说明代码中各方法间交互频繁，需梳理调用关系，避免出现复杂混乱的调用链路，比如循环调用等情况，以增强代码逻辑的清晰性和可测试性。

方法粒度：

平均每个方法 3.51 条语句，方法粒度较细，好处是功能相对单一、易于理解和测试，但也可能存在方法拆分过细导致方法数量过多、代码结构零散的问题，需权衡是否可以适当合并一些功能相近的方法。

第三次电梯程序：

优点

注释情况良好：含注释的代码行占比达 25.5% ，能帮助开发人员理解代码逻辑，无论是后续维护、功能扩展，还是团队协作，都降低了理解成本，提高了代码可读性。
分支逻辑较简单：分支语句占比 18.0% ，相对较低，意味着代码中条件判断等逻辑不是特别繁杂，代码逻辑相对清晰，不易出现复杂的条件嵌套导致的混乱情况，便于理解和维护。
方法复杂度尚可：最大复杂度仅为 1 ，说明代码中最复杂方法的复杂程度不高，整体代码复杂度可控，开发人员阅读和修改代码时难度较小。平均每个方法 5.90 条语句 ，方法粒度较为适中，功能相对集中且不过于冗长。
类结构较合理：有 6 个类和接口，平均每个类 3.33 个方法 ，类与方法的数量分布较为均衡，体现了较好的模块化设计思想，有助于代码的组织和管理，不同功能可以在各自的类中实现，职责相对清晰。

可改进之处

方法调用过多：方法调用语句达 231 条，数量较多，可能导致方法间调用关系复杂，难以梳理和理解调用链路。可通过重构，合理减少不必要的方法调用，或者优化方法调用的逻辑，使代码结构更加清晰。
行数与语句数差异：代码行数 345 行，但语句数仅 183 条 ，可能存在较多空行或冗余代码行。可对代码进行精简，删除不必要的空行和冗余内容，使代码更加紧凑、简洁。

三，自我反思

我的问题本质上是 “被动学习” 与 “依赖心理” 的集中体现。在课堂学习中，我缺乏主动探索的意识。当面对电梯类这种需要综合运用数据结构、设计模式的复杂题目时，这种被动性暴露无遗。例如，我从未主动查阅过电梯调度算法（如 SCAN 算法、LOOK 算法）的实现细节，也没有尝试通过模拟真实乘梯场景来抽象代码逻辑。

未来的改进需从三方面入手：

主动构建知识体系：

系统学习设计模式（如行为型模式中的策略模式、状态模式），并在实际项目中刻意练习。例如，尝试用状态模式重构电梯的运行状态管理，对比重构前后代码的可维护性差异；

强化问题拆解能力：

面对复杂问题时，采用 “自顶向下” 的分析方法。以电梯为例，可先定义核心对象（电梯、乘客、请求），再梳理对象间交互流程（乘客发出请求→电梯接收请求→调度算法处理→电梯移动→乘客进出），最后逐步实现每个子模块；

增加实战训练量：

每周至少完成一个小型 Java 项目（如简易计算器、学生管理系统），通过实践加深对知识点的理解。例如，在实现学生管理系统时，运用集合类（如ArrayList）存储学生信息，用HashMap实现快速查询，强化数据结构的应用能力。

四，踩坑心得

第二次程序中，由于将核心调度逻辑集中在Controller.processRequest()方法（复杂度 24），且未拆分出独立的测试单元，导致调试时难以定位问题。例如，当电梯无法响应下行请求时，我不得不逐行追踪数百行代码，耗时数小时才发现是方向判断逻辑中遗漏了 “当前楼层等于目标楼层” 的边界条件。

五，一点建议

将大作业的测试用例增加亿点，以便弥补题目说明不全，增强对题目的理解。

六、总结

通过三次电梯程序的实践，我对软件开发的认知经历了从 “无知” 到 “有序” 的转变。初期的挫败感源于对复杂问题的畏惧和被动学习模式，而后期的改进则得益于主动拆解问题、系统学习设计模式以及强化实战训练。