第一次Blog作业

一、前言

这是对第一次大作业的分析。

第一次题目

1. 电梯类的基础状态建模（当前楼层、运行方向、状态枚举）
2. 内外请求队列的分离管理（内部目标楼层队列、外部上下行请求队列）
3. 基础调度算法实现（同方向优先处理规则） - 串行请求处理（单线程模拟输入）

• 无效请求过滤（楼层越界处理）
• 状态输出逻辑（运行 / 开门 / 关门状态的控制台打印）
  第二次题目

1. 单一职责原则（SRP）实践：拆分电梯类、请求类、队列类、控制类
2. 复杂输入校验（连续重复请求去重、格式合法性检查）
3. 模块化设计（将调度逻辑从电梯类剥离至控制类） - 类图驱动开发（严格遵循给定类结构）

• 请求对象的封装（包含楼层、方向、有效性标记）
• 队列去重机制（避免无效重复请求入队）
  第三次题目

1. 乘客类建模（封装请求源楼层与目的楼层）
2. 外部请求到内部目标的转化逻辑（外部请求处理后自动添加目的楼层到内部队列）
3. 职责进一步细化（控制类负责调度策略，队列类支持动态入队规则） - 数据流转链路扩展（外部请求→乘客对象→源楼层处理→目的楼层入队）

• 输入格式调整（外部请求从 “楼层 + 方向” 变为 “源楼层 + 目的楼层”）
• 边界条件复杂化（需处理源楼层与目的楼层相同的无效请求）

二、设计与分析

第一次电梯迭代程序

源码报表分析图

一、代码规模分析
行数与语句：代码总计 266 行，包含 94 条语句，平均每行约 0.35 条语句，代码密度较高，存在一行多语句的情况，降低了代码的可读性。
类与接口数量：仅有 2 个类及接口，功能高度集中在少数结构中。根据单一职责原则，一个类应仅承担一项职责，而此处类数量过少，易导致单个类职责过重，代码逻辑混杂，后续理解与修改成本高。
二、设计分析
功能耦合度：功能集中在少数类中，类间交互频繁，耦合度高。一个类的修改可能直接影响另一个类的功能，系统灵活性与可维护性差，难以独立扩展或替换模块。
单一职责缺失：未遵循单一职责原则，类可能同时处理多种不相关功能。如一个类既负责业务逻辑计算，又处理输入输出，导致代码冗余，后期维护时牵一发而动全身。
三、复杂度分析
分支占比：分支语句占比 20.2%，表明代码中条件判断（如 if-else）、循环（如 for、while）等结构较多。这会增加代码逻辑的复杂度，使执行路径多样化，加大测试与调试难度，也易因考虑不全导致潜在 bug。
方法调用：60 次方法调用虽体现功能交互，但过长的调用链可能导致逻辑分散，追踪问题时需在多个方法间跳转，增加理解成本。
注释占比：23.7% 的注释对代码理解有一定帮助，但仅靠注释无法弥补结构缺陷。若代码逻辑本身复杂混乱，注释可能沦为对零散代码的解释，缺乏对整体逻辑的清晰引导。
四、不足与影响
维护与扩展难度：类数量少且功能过度集中，修改某一功能可能需深入多个复杂逻辑块，易引入新问题。例如，添加新功能时，可能因类职责不清晰而不知从何处切入，或被迫修改已有稳定代码。
代码清晰度与模块化：整体结构缺乏清晰的模块化划分，未将功能拆分为更小、更独立的单元。高分支占比进一步加剧逻辑复杂性，不利于后续迭代。长期来看，代码会逐渐成为 “技术债务”，维护成本呈指数级增长。
综上，该代码在设计上需优化类结构，遵循单一职责与低耦合原则；在实现上应简化分支逻辑，提高模块化程度，结合注释完善整体可读性，以提升可维护性与扩展性。

第二次电梯迭代程序

类图设计如下：

源码报表分析图

一、代码规模分析
行数与语句：代码共 301 行，包含 125 条语句，平均每行约 0.42 条语句，语句密度较 1.0 有所提升，需关注代码可读性，避免因单行逻辑过多影响理解。
类与接口数量：类及接口数量增至 3 个，体现了初步的职责拆分，向单一职责原则靠近，有助于降低单个类的复杂度，提升代码组织性。
二、设计分析
职责划分：类数量增加表明设计上的改进，开始将不同功能分散到多个类中，减少功能过度集中的问题，类间协作通过 64 次方法调用体现，初步建立了结构框架。
逻辑清晰度：分支占比降至 16.0%，较 “电梯 1.0.java” 的 20.2% 有明显改善，说明条件判断、循环等逻辑控制结构更简洁，代码执行路径更易追踪，逻辑复杂度降低。
三、复杂度分析
方法调用：64 次方法调用虽略有增加，但伴随类数量提升，反映出类间协作机制的建立，只要调用逻辑合理，可增强代码模块化，而非单纯增加复杂度。
注释占比：注释占比降至 15.9%，关键逻辑缺乏清晰说明。
注释缺失：注释占比下降不利于代码维护，后续需补充关键逻辑注释，提升代码可理解性。
逻辑拆分潜力：尽管分支占比下降，但 16.0% 仍有优化空间，部分复杂逻辑可能未彻底拆分。可进一步审视代码，将长方法、多层嵌套的条件判断等重构，降低分支依赖，提升代码可维护性与扩展性。

第三次电梯迭代程序

类图设计如下：

源码报表分析图

一、代码规模分析
行数与语句：代码共 281 行，包含 150 条语句，语句密度进一步提升（每行约 0.53 条语句），功能复杂度增加，需关注代码是否因逻辑堆砌影响可读性。
类与接口数量：类及接口数量保持 3 个，引入乘客类体现职责细化，是设计上的优化尝试，但整体类数量仍较少，复杂功能集中在有限类中。
二、设计分析
职责细化：引入乘客类，进一步细化职责，符合单一职责原则的实践，有助于将乘客相关逻辑集中管理，提升代码组织性。
注释与维护风险：注释占比骤降至 12.8%，为三次分析中最低，关键逻辑缺乏说明，带来理解障碍。
方法调用复杂度：方法调用达 121 次，较 2.0 的 64 次翻倍，类间交互频繁，调用逻辑不清晰及存在不必要的调用，会导致类间耦合度显著升高，牵一发而动全身，破坏代码的独立性与可测试性。
三、复杂度分析
分支逻辑：分支占比 21.3%，为三次分析中最高，新增的乘客类及相关处理逻辑未通过有效重构简化，导致条件判断、循环等分支结构增多，代码执行路径复杂，逻辑难以追踪，测试覆盖难度加大，潜在 bug 风险增加。
结构优化不足：尽管引入新类，但未显著降低复杂度，说明代码结构调整不够彻底，可能存在长方法、多层嵌套或冗余的条件判断，未对复杂逻辑进行深度拆分与优化。
四、不足与改进方向
注释补充：急需补充关键逻辑、类 / 方法功能的注释，提升代码可理解性，降低维护门槛。
降低耦合与简化逻辑：梳理 121 次方法调用，去除冗余调用，优化类间协作机制，降低耦合度；针对 21.3% 的分支占比，重构复杂方法，拆分多层嵌套逻辑，减少不必要的条件判断，提升代码清晰度与可维护性。
深化结构设计：评估是否需要进一步拆分类，避免功能过度集中在现有 3 个类中，真正实现高内聚、低耦合的设计目标，为后续功能扩展奠定良好基础。

三、踩坑心得

1. 第一次作业：对空链表操作缺乏严谨性，未先判断链表是否为空就直接调用方法，致使程序崩溃，暴露出对数据结构使用规范的忽视。此外，单个函数功能过于复杂（如电梯控制函数）集多种逻辑与分支于一体，不仅调试困难，还违背了代码简洁性与单一职责原则，后续维护与扩展举步维艰同时，注释严重缺失，当时虽清楚代码逻辑，但后续复查时因无注释难以快速理解，大大增加了维护难度。
2. 第二次作业：依旧未重视注释的作用，代码可读性差，给后续协作与自我检查带来困扰。更关键的是，在逻辑未完全梳理清晰时就急于编码，中途发现逻辑漏洞后不得不返工，既浪费时间，又破坏了代码结构的整洁性。
3. 第三次作业：对电梯业务逻辑理解出现偏差，如对调度算法或请求处理流程的误解，导致电梯运行不符合预期，深刻认识到理解需求与逻辑是编码的前提。这些经历让我明白，编码前需理清逻辑、规范注释、合理拆分功能，避免因小失大，从源头提升代码质量。

四、改进建议

一、操作严谨性
边界校验：操作链表 / 队列前添加空值校验。
二、代码可读性与可维护性
注释规范
模块化拆分
单一职责
三、降低复杂度
减少if-else语句的使用
四、逻辑规划
用流程图理清核心逻辑。
针对典型场景编写测试用例验证逻辑。
复杂逻辑与他人讨论，避免理解偏差。

五、总结

通过三次电梯调度程序的设计与实现，我在代码编写、问题分析有了不小的进步，深刻体会到软件开发中 “细节决定成败” 的核心逻辑。

1. 从实践中积累的核心经验
   初期忽视空链表校验、注释缺失等问题，导致后期调试成本激增。意识到代码不仅要 “能运行”，更要 “易读、易维护”
   单一职责原则的缺失让第一次作业代码臃肿不堪，而第三次作业尝试拆分类与方法后，代码结构明显清晰。这让我认识到，在编码前花时间规划类职责、绘制 UML 类图，远比后期重构高效得多。
2. 暴露的问题与能力短板
   需求理解的严谨性不足：第一次作业因误解 “电梯调度优先级” 导致逻辑错误，导致做无用功。
   复杂逻辑的拆分能力待提升
   异常处理薄弱：三次作业中多次出现空指针异常。
   4.总结
   我学会了使用正则表达式高效处理字符串，以及枚举的使用，还学会了使用PowerDesigner与SourceMonitor