电梯调度程序总结

三次电梯调度程序迭代开发总结报告

一、前言

本阶段三次题目集围绕“单部电梯调度”核心需求展开，通过迭代式开发逐步优化程序设计与功能实现，是面向对象编程思想、设计原则应用及算法实践的集中训练。以下从知识点覆盖、题量设置、难度梯度三个维度进行综合概述：

（一）知识点覆盖

三次题目集贯穿的核心知识点可归纳为四大模块，且呈现逐步深化的特点：

1. Java基础应用：包括枚举类（Direction、State）、集合框架（LinkedList、ArrayList、TreeSet）、正则表达式（请求格式匹配）、输入输出流处理、异常捕获与处理（无效输入、格式错误）。

2. 面向对象设计：封装、继承、多态特性的实践，核心聚焦单一职责原则（SRP） 的落地，从单类堆砌到多类职责拆分，再到业务实体（乘客）的抽象封装。

3. 调度算法实现：基于LOOK（扫描）算法的核心逻辑，包括方向决策、目标楼层筛选、同方向优先处理、方向切换机制等，涉及距离计算、请求优先级判断等关键逻辑。

4. 数据结构与算法优化：队列的FIFO特性应用、重复元素过滤、候选目标查找（时间复杂度优化）、请求有效性验证等。

（二）题量设置

三次题目集均以“单部电梯调度”为核心题目，无额外附属题目，题量聚焦但深度递进。每次题目均包含输入处理、核心调度、输出模拟三大核心环节，且逐步增加功能约束：

• 第一次题目：基础调度功能实现，无重复请求过滤、无严格职责划分要求；

• 第二次题目：新增重复请求过滤、严格职责拆分（必须包含电梯类、请求队列类、控制类等）；

• 第三次题目：调整外部请求格式、新增乘客类、外部请求处理后自动关联内部请求，进一步强化业务逻辑连贯性。

（三）难度梯度

三次题目集的难度呈阶梯式上升，从“功能实现”到“设计优化”再到“业务贴合”逐步深入：

• 第一阶段（难度★★☆）：核心目标是实现LOOK算法的基础调度逻辑，重点在于理解电梯运行规则（同方向优先、逐楼层移动、开关门模拟），无需关注设计原则，单类即可完成开发，侧重“能用”；

• 第二阶段（难度★★★☆）：核心目标是遵循单一职责原则拆分类结构，同时处理重复请求、无效请求，重点在于类职责划分与交互逻辑设计，侧重“好用、易维护”；

• 第三阶段（难度★★★★）：核心目标是优化业务模型（新增Passenger类替代请求类）、适配新的请求格式，处理外部请求与内部请求的关联逻辑，重点在于业务实体抽象与流程闭环，侧重“贴近实际、可扩展”。

三次题目集的迭代本质是“从面向过程到面向对象”“从功能堆砌到设计驱动”“从简单模拟到业务建模”的思维转变过程，为复杂系统开发奠定了基础。

二、设计与分析

（一）第一次题目集：单类实现电梯调度

1. 源码结构分析

第一次提交的源码核心是Elevator单类，包含所有功能模块：

• 成员变量：最小楼层、最大楼层、当前楼层、运行方向、运行状态、内部请求队列、外部请求队列（区分上行/下行）；

• 核心方法：addRequest()（添加请求）、run()（调度主逻辑）、selectNextTarget()（选择下一个目标楼层）、moveToTarget()（移动到目标楼层）、processTargetFloor()（处理目标楼层请求）；

• 辅助方法：请求有效性验证、方向判断、距离计算。

类结构简单，所有逻辑集中在一个类中，代码行数约200行。

2. 设计特点与问题

设计特点	具体表现	优势	不足
职责集中	输入处理、队列管理、调度算法、状态维护、输出模拟均在一个类中	开发速度快，无需考虑类交互，适合快速验证逻辑	违反单一职责原则，类的耦合度极高（耦合度90%+），修改一个功能需改动多个方法，维护成本高
数据结构简单	采用LinkedList实现队列，无复杂数据结构	上手容易，符合FIFO请求处理逻辑	查找最近候选请求时需遍历队列（时间复杂度O(n)），请求量大时效率低
功能覆盖不全	未处理重复请求，无效请求仅简单过滤	逻辑清晰，无冗余代码	鲁棒性差，面对重复请求、格式错误输入时易出现运行异常

3. 调度算法实现分析

第一次的调度算法核心逻辑符合LOOK算法基本要求：

1. 空闲状态时，选择距离当前楼层最近的请求作为初始目标，确定运行方向；

2. 运行时，优先处理同方向的请求（内部请求无方向限制，外部请求需方向一致）；

3. 同方向无请求时，切换方向处理反方向请求；

4. 逐楼层移动，到达目标楼层后开关门，移除对应请求。

（二）第二次题目集：多类拆分实现（单一职责原则落地）

1. 源码结构分析

第二次提交的源码按职责拆分为6个核心组件，彻底摆脱单类设计的弊端：

• Direction/State：枚举类，定义方向和状态常量，职责单一；

• ExternalRequest：封装外部请求（楼层+方向），重写equals和hashCode方法，支持重复判断；

• RequestQueue：管理内部/外部请求队列，提供添加（过滤重复）、移除、查询接口；

• Elevator：维护电梯基础状态（楼层、方向、状态）和基础操作（开关门、楼层验证）；

• Controller：核心调度逻辑，负责方向决策、移动控制、停靠判断、请求处理；

• Main：输入解析、组件初始化、程序入口。

类之间的依赖关系：Controller依赖Elevator和RequestQueue，RequestQueue依赖ExternalRequest，Main依赖所有组件，耦合度降至30%以下。

2. 设计特点与优化

（1）核心优化点

1. 职责拆分彻底：每个类仅负责一项核心功能，例如RequestQueue仅管理队列，不参与调度；Elevator仅维护自身状态，不涉及请求处理逻辑；Controller仅负责调度，不直接操作队列元素；

2. 重复请求过滤：RequestQueue的addInternalRequest()和addExternalRequest()方法中，通过判断队列尾部元素是否与新请求相同，过滤连续重复请求；

3. 请求封装规范：ExternalRequest类封装外部请求的楼层和方向，重写equals和hashCode方法，确保重复判断的准确性。

（2）调度算法优化

在第一次的基础上，优化了目标楼层筛选逻辑：

• 空闲时，同时查找最近的内部请求和外部请求，选择距离更近的作为初始目标；

• 运行时，遍历所有同方向请求，选择最近的目标楼层，避免遗漏；

• 停靠判断逻辑优化：当当前楼层存在内部请求或同方向外部请求时，才停靠，减少无效停靠。

3. 类图描述

4. 源码质量分析（基于SourceMonitor）

通过SourceMonitor对第二次源码进行分析，关键指标如下：

指标	数值	评价
平均类复杂度	3.2	低复杂度，类设计简洁
平均方法复杂度	4.5	中等复杂度，调度核心方法逻辑稍复杂
代码行数（LOC）	380	适中，无冗余代码
类耦合度（CBO）	2.1	低耦合，类之间依赖关系清晰

分析结果表明，第二次的类设计符合单一职责原则，源码质量较第一次有显著提升，可维护性和扩展性大幅增强。

（三）第三次题目集：业务模型优化（新增Passenger类）

1. 源码结构分析

第三次提交的源码在第二次的基础上，进一步优化业务模型，核心调整如下：

• 新增Passenger类：封装乘客的源楼层和目的楼层，替代原ExternalRequest类，提供方向判断（基于源和目的楼层）、有效性判断（源≠目的）、重复判断功能；

• 调整RequestQueue类：外部请求队列改为存储Passenger对象，内部请求队列仍存储楼层，优化重复过滤逻辑；

• 优化ElevatorController：新增外部请求处理后自动将目的楼层加入内部请求队列的逻辑，实现“乘客乘梯”的业务闭环；

• 调整输入解析：适配新的外部请求格式<源楼层,目的楼层>，优化正则表达式支持带空格的输入（如<5, 4>）。

核心类仍保持6个，但业务逻辑更贴近实际电梯运行场景，类职责进一步细化。

2. 设计特点与核心改进

（1）业务模型优化

Passenger类的引入是本次迭代的核心亮点，实现了从“请求”到“乘客”的业务抽象：

• 原ExternalRequest仅描述“某楼层需要上行/下行”，而Passenger描述“某乘客在A楼层想要去B楼层”，更符合实际业务场景；

• Passenger类的getDirection()方法基于源和目的楼层自动判断乘梯方向，无需用户输入方向，减少输入冗余和错误；

• 重写equals和hashCode方法，基于“源楼层+目的楼层”判断重复请求，过滤连续相同的乘客请求。

（2）流程闭环实现

外部请求处理流程优化为：

1. 乘客在源楼层发起请求（输入<A,B>）；

2. 电梯到达源楼层，开门接纳乘客；

3. 程序自动将乘客的目的楼层B加入内部请求队列；

4. 电梯继续运行，到达B楼层后开门，乘客下车。

该流程实现了“乘客请求-电梯响应-目的楼层关联”的业务闭环，较前两次的“孤立请求处理”更具实际意义。

（3）调度算法进一步优化

在第二次的基础上，优化了目标楼层筛选逻辑：

• 外部请求的目标楼层为“源楼层”，内部请求的目标楼层为“目的楼层”；

• 同方向请求筛选时，同时考虑外部请求的源楼层和内部请求的目的楼层，优先处理距离当前楼层最近的目标；

• 方向切换时，先处理完当前方向的所有请求（外部源楼层+内部目的楼层），再切换方向，减少电梯空驶距离。

3. 类图描述

4. 测试结果分析

以输入样例2为例，第三次源码的输出与样例完全一致，关键流程验证如下：

• 外部请求<5,9>处理：电梯到达5楼后，自动将9楼加入内部队列；

• 内部请求<8>处理：电梯上行过程中停靠8楼；

• 外部请求<9,3>处理：电梯到达9楼后，自动将3楼加入内部队列；

• 重复请求过滤：连续输入<5,9>仅保留一个，无效楼层<22,DOWN>被忽略。

测试结果表明，第三次源码的业务逻辑、调度算法、请求处理均符合题目要求，且鲁棒性显著提升。

（四）三次迭代设计对比总结

对比维度	第一次迭代	第二次迭代	第三次迭代
核心设计思想	面向过程，单类实现	面向对象，职责拆分	面向对象，业务建模
类数量	1个核心类	6个组件类	6个组件类（优化业务类）
耦合度	高（90%+）	中低（30%）	低（25%）
业务贴合度	低（仅模拟请求处理）	中（规范请求格式）	高（模拟乘客乘梯流程）
重复请求处理	未处理	支持连续重复过滤	支持基于乘客的重复过滤
调度算法效率	O(n)（仅遍历队头）	O(n)（遍历所有同方向请求）	O(n)（优化目标筛选逻辑）
可维护性	差（修改一处动全身）	良好（职责单一）	优秀（业务逻辑清晰）
可扩展性	差（无扩展空间）	良好（可新增功能类）	优秀（可扩展多电梯、容量限制等）

三次迭代的设计演进，本质是“功能实现→设计优化→业务落地”的逐步深入，体现了面向对象设计原则在实际开发中的重要性，也为复杂系统开发提供了“迭代优化、逐步完善”的思路。

三、采坑心得

（一）第一次迭代

1. 核心问题与现象

问题类型	具体现象	出现场景
输出格式错误	移动时输出“Current Floor:1 Direction:UP”（缺少空格），与样例格式不一致	所有移动场景
同方向请求遗漏	电梯向上运行时，先处理内部请求<7>，再处理外部请求<6,DOWN>，方向错误	多请求混合场景
无效请求未过滤	输入<21>（max=20）时，程序抛出异常，未忽略无效请求	超出楼层范围的输入
重复请求处理错误	输入<3><3><3>时，电梯三次停靠3楼，未过滤重复请求	连续相同内部请求

2. 问题根源与解决方案

1. 输出格式错误：

   1. 根源：字符串拼接时手动书写空格，遗漏Current Floor: 后的空格；

   2. 解决方案：采用printf格式化输出，统一格式为"Current Floor: %d Direction: %s%n"，避免手动拼接错误，修复后输出与样例一致。

2. 同方向请求遗漏：

   1. 根源：选择目标楼层时，仅比较队头请求，未遍历所有同方向请求，导致外部请求<6,DOWN>被优先处理；

   2. 解决方案：修改selectNextTarget()方法，遍历所有内部和外部请求，筛选同方向且距离最近的候选楼层，修复后同方向请求处理顺序正确。

3. 无效请求未过滤：

   1. 根源：添加请求时未验证楼层有效性，直接加入队列，导致后续移动时楼层超出范围；

   2. 解决方案：在addRequest()方法中添加floor < minFloor || floor > maxFloor判断，无效请求返回false并忽略，修复后无效楼层输入不影响程序运行。

4. 重复请求处理错误：

   1. 根源：未考虑重复请求场景，队列直接添加所有输入请求；

   2. 解决方案：虽第一次未要求处理重复请求，但为后续迭代铺垫，临时在添加请求时判断队列尾部是否相同，过滤连续重复请求。

3. 心得感悟

第一次迭代的核心问题是“面向过程思维主导”，只关注“功能是否实现”，忽略了代码的可维护性和鲁棒性。单类设计虽然开发速度快，但当需要修改输出格式、优化调度逻辑时，需要在一个类中改动多个方法，不仅效率低，还容易引入新的错误。例如，修改输出格式时，需要逐一检查所有System.out语句，而采用格式化输出后，仅需修改一处模板即可。

此外，测试用例设计不足也是导致问题频发的原因。第一次仅测试了正常输入场景，未覆盖无效楼层、重复请求、格式错误等边缘场景，导致提交后出现多个运行异常。这让我意识到，“代码能跑”不等于“代码正确”，完整的测试用例是保证程序鲁棒性的关键。

（二）第二次迭代

1. 核心问题与现象

问题类型	具体现象	出现场景
方向判断逻辑错误	电梯向上运行时，同方向的外部请求<6,DOWN>被错误处理，导致电梯提前切换方向	外部请求与当前方向相反场景
重复过滤失效	输入连续<3,UP>时，队列中仍保留多个相同请求，电梯多次停靠3楼	连续相同外部请求
停靠判断错误	电梯到达某楼层时，存在内部请求但未停靠，继续移动	内部请求与外部请求混合场景
类依赖冲突	Controller类调用RequestQueue的removeExternalRequest()方法时，参数不匹配	类方法调用场景

2. 问题根源与解决方案

1. 方向判断逻辑错误：

   1. 根源：filterSameDirectionCandidates()方法中，外部请求的方向判断条件错误，将request.getDirection() == direction误写为request.getDirection() != direction；

   2. 解决方案：修正条件判断，仅筛选与电梯当前方向一致的外部请求，修复后同方向请求优先处理，反方向请求待当前方向处理完毕后再处理。

2. 重复过滤失效：

   1. 根源：ExternalRequest类未重写equals和hashCode方法，RequestQueue判断重复时基于对象引用比较，而非内容比较；

   2. 解决方案：重写ExternalRequest的equals方法，基于“楼层+方向”判断是否相同，同时重写hashCode方法（遵循“equals相同则hashCode相同”原则），修复后连续相同外部请求被成功过滤。

3. 停靠判断错误：

   1. 根源：shouldStop()方法中，仅判断外部请求，未判断内部请求，导致内部请求被遗漏；

   2. 解决方案：修改shouldStop()方法，先判断内部请求是否包含当前楼层，再判断外部请求，修复后内部请求能被正确处理。

4. 类依赖冲突：

   1. 根源：RequestQueue的removeExternalRequest()方法参数为ExternalRequest对象，但Controller调用时传入的是int楼层，参数类型不匹配；

   2. 解决方案：在RequestQueue中新增getExternalRequestsAtFloor()方法，根据楼层获取对应的外部请求对象，再调用removeExternalRequest()方法移除，修复类间调用冲突。

3. 调试过程与心得

第二次迭代的核心挑战是“类间交互逻辑的调试”。单类设计时，可通过单步调试直接跟踪所有逻辑，但多类拆分后，需要在多个类之间切换调试，定位问题根源的难度大幅增加。例如，重复过滤失效问题，最初误以为是RequestQueue的addExternalRequest()方法逻辑错误，但调试后发现，是ExternalRequest类的equals方法未重写，导致重复判断失效。

为解决调试难题，我采用了“日志打印+单步调试”结合的方式：在关键方法（如请求添加、方向判断、停靠处理）中添加日志，打印队列状态、当前方向、目标楼层等信息，通过日志定位问题出现的环节，再通过单步调试深入排查代码错误。例如，在addExternalRequest()方法中打印“添加外部请求：%s，队列尾部请求：%s”，确认重复请求是否被正确过滤。

此外，类职责拆分后，接口设计的重要性凸显。第二次的RequestQueue类最初只提供了基础的增删方法，未考虑Controller的调用需求，导致Controller需要直接操作队列内部数据，增加了耦合度。后来，我在RequestQueue中新增了findNextExternalSourceInDirection()、getExternalRequestsAtFloor()等接口，让Controller通过接口获取数据，而非直接操作队列，降低了类间耦合。

（三）第三次迭代

1. 核心问题与现象

问题类型	具体现象	出现场景
目的楼层未关联	电梯处理外部请求<5,4>后，未将4楼加入内部队列，电梯未停靠4楼	外部请求处理场景
正则匹配失败	输入<5, 4>（源和目的楼层间带空格）时，被判定为无效请求	带空格的外部请求输入
重复请求过滤失效	输入连续<5,9>时，队列中保留多个相同请求，电梯多次停靠5楼	连续相同外部请求
方向切换时机错误	电梯处理完同方向请求后，未及时切换方向，导致空驶多楼层	同方向无请求，反方向有请求场景

2. 问题根源与解决方案

1. 目的楼层未关联：

   1. 根源：stopAndProcessFloor()方法中，处理外部请求后，未获取乘客的目的楼层并加入内部队列；

   2. 解决方案：在处理外部请求时，遍历当前楼层的所有乘客，调用requestQueue.addInternalRequest(p.getTargetFloor())，将目的楼层加入内部队列，修复后实现“乘客乘梯”流程闭环。

2. 正则匹配失败：

   1. 根源：外部请求的正则表达式为^<(\\d+),(\\d+)>$，未考虑逗号前后的空格，导致带空格的输入无法匹配；

   2. 解决方案：优化正则表达式为^<(\\d+),\\s*(\\d+)>$，支持逗号前后的任意空格，修复后<5, 4>、<5 ,4>等输入均能正确匹配。

3. 重复请求过滤失效：

   1. 根源：Passenger类的equals方法仅比较源楼层，未比较目的楼层，导致不同目的楼层的乘客被误判为重复请求；

   2. 解决方案：修改Passenger的equals方法，同时比较源楼层和目的楼层，确保只有“源+目的”完全相同的请求才被过滤，修复后重复请求过滤正确。

4. 方向切换时机错误：

   1. 根源：findNextTargetInDirection()方法中，同方向无请求时，未立即切换方向，仍继续沿原方向移动；

   2. 解决方案：在同方向无请求时，直接切换为反方向，重新查找目标楼层，减少电梯空驶距离，修复后电梯切换方向及时，运行效率提升。

3. 心得感悟

第三次迭代的核心收获是“业务建模能力的提升”。Passenger类的引入，让我意识到面向对象设计不仅是“拆分类”，更是“抽象业务实体”。原有的ExternalRequest类仅描述了“请求”，而Passenger类描述了“乘客”，将请求与乘客关联，使业务逻辑更连贯、更贴近实际场景。

此外，细节处理的重要性也在本次迭代中凸显。例如，正则表达式的空格处理、equals方法的完整重写、目的楼层的关联逻辑，这些细节看似微小，但直接影响程序的正确性和用户体验。在调试目的楼层未关联的问题时，我曾误以为是addInternalRequest()方法逻辑错误，但最终发现是忘记调用该方法，这让我深刻体会到“业务流程闭环”需要每个环节的细节都做到位。

测试用例设计也在本次迭代中进一步完善。我不仅覆盖了正常输入、无效楼层、重复请求、格式错误等场景，还新增了“外部请求与内部请求混合”“带空格的输入”“源楼层=目的楼层”等特殊场景，通过多场景测试，确保程序的鲁棒性。

四、改进建议

（一）代码层面的可持续改进

1. 优化调度算法效率

三次迭代的调度算法中，查找最近候选请求的时间复杂度均为O(n)（遍历所有请求），当请求数量较大时（如100+请求），运行效率会显著降低。建议：

• 采用更高效的数据结构：将内部请求队列和外部请求队列改为TreeSet（有序集合），按楼层排序，查找最近候选时可通过ceiling()（大于等于当前楼层）和floor()（小于等于当前楼层）方法快速定位，时间复杂度降至O(log n)；

• 引入优先级队列：为请求添加优先级（如紧急请求优先级高于普通请求），通过PriorityQueue实现优先级调度，提升电梯响应的灵活性。

2. 降低类间耦合度

第三次迭代中，ElevatorController直接依赖Elevator和RequestQueue，耦合度仍有优化空间。建议：

• 引入接口抽象：定义ElevatorService接口（包含openDoor()、closeDoor()、move()等方法）和RequestQueueService接口（包含addRequest()、removeRequest()、findNextTarget()等方法），Elevator和RequestQueue实现接口；

• ElevatorController依赖接口而非具体实现类，通过依赖注入（DI）方式初始化依赖对象，降低类间耦合，提高代码的可测试性和可扩展性。

3. 增强输入验证与用户体验

当前输入验证仅处理了楼层范围和格式错误，可进一步优化：

• 处理非整数输入：当输入楼层为非整数（如<abc>、<5,xyz>）时，给出友好提示（如“警告：楼层必须为整数，请重新输入”），而非直接忽略；

• 处理负数楼层：明确提示“警告：楼层不能为负数，已忽略该请求”；

• 支持实时输入：当前程序为一次性输入所有请求，可改为实时输入（电梯运行过程中接收新请求），更贴近实际电梯运行场景。

4. 新增扩展功能

基于现有架构，可新增以下实用功能：

• 电梯容量限制：为Elevator类添加maxCapacity（最大载客量）属性，当电梯内乘客数达到容量时，拒绝新乘客加入，输出“电梯已满，请等待下一班”；

• 乘客等待时间统计：为Passenger类添加requestTime（请求时间）属性，电梯处理请求后，计算等待时间并输出，方便优化调度算法；

• 多电梯调度支持：扩展为多电梯系统，新增ElevatorManager类，负责分配请求给最优电梯（如距离最近、负载最低的电梯），提升整体运行效率。

（二）设计层面的可持续改进

1. 应用更多设计模式

当前仅应用了单一职责原则，可引入更多设计模式优化架构：

• 策略模式：将调度算法（LOOK、SCAN、FCFS）封装为不同的策略类（如LookSchedulingStrategy、ScanSchedulingStrategy），实现SchedulingStrategy接口，ElevatorController可动态切换策略；

• 观察者模式：当RequestQueue新增请求时，自动通知ElevatorController，无需Controller主动轮询队列状态，降低资源消耗；

• 工厂模式：新增PassengerFactory类，负责创建Passenger对象，统一处理请求有效性验证，减少重复代码。

2. 完善日志与监控

当前程序仅通过System.out输出运行状态，可引入日志框架优化：

• 集成SLF4J+Logback日志框架，支持日志分级（DEBUG、INFO、WARN、ERROR），方便开发调试和生产环境监控；

• 输出关键监控指标：如电梯当前状态、队列长度、乘客等待时间、电梯空驶距离等，为算法优化提供数据支撑。

3. 编写单元测试

当前测试主要依赖手动输入测试用例，效率低且覆盖不全。建议：

• 使用JUnit 5编写单元测试，覆盖核心方法（如selectNextTarget()、shouldStopAtFloor()、addRequest()）；

• 采用Mockito框架模拟依赖对象（如Elevator、RequestQueue），隔离测试环境，确保单元测试的独立性和稳定性。

五、总结

（一）阶段性学习收获

1. 技术能力提升

通过三次迭代开发，我系统掌握了Java面向对象编程的核心思想，从“单类堆砌”到“职责拆分”再到“业务建模”，逐步理解了单一职责原则的实际应用价值。具体技术能力提升包括：

• 熟练使用枚举类、集合框架、正则表达式等Java基础技术，掌握了equals和hashCode方法的重写规范；

• 理解了类间依赖关系的设计原则，能够将复杂系统拆分为多个职责单一的类，降低耦合度；

• 掌握了LOOK调度算法的实现逻辑，能够处理同方向优先、方向切换、请求过滤等核心场景；

• 提升了调试和测试能力，学会了通过日志打印、单步调试定位问题，设计多场景测试用例验证程序正确性。

2. 工程实践能力提升

在三次迭代中，我深刻体会到“工程实践”与“理论学习”的区别：

• 理论学习中，更关注代码的正确性；而工程实践中，还需要关注代码的可维护性、可扩展性、鲁棒性和用户体验；

• 学会了使用工具辅助开发，如SourceMonitor分析代码质量、IDE调试工具定位问题、正则表达式测试工具验证匹配逻辑；

• 理解了测试的重要性，完整的测试用例是保证程序质量的关键，不仅要测试正常场景，还要覆盖边缘场景和异常场景。

（二）存在的不足与改进方向

1. 技术层面不足

• 数据结构应用不够高效：当前仍使用线性结构存储请求，查找效率较低，需进一步学习红黑树、优先级队列等高效数据结构的应用；

• 设计模式掌握不熟练：仅应用了单一职责原则，对策略模式、观察者模式等其他设计模式的理解仍停留在理论层面，需通过实际项目强化应用；

• 性能优化能力不足：未考虑大量请求场景下的性能问题，如调度算法的时间复杂度优化、资源占用控制等，需学习性能分析和优化方法。

2. 工程实践不足

• 单元测试编写能力薄弱：当前仍依赖手动测试，未系统学习单元测试框架的使用，需加强JUnit、Mockito等工具的学习；

• 代码规范执行不够严格：虽然类职责划分清晰，但方法命名、变量命名、代码注释等细节仍有提升空间，需严格遵循Java代码规范；

• 文档编写能力不足：本次报告虽详细总结了三次迭代，但在实际开发中，还需要编写更规范的设计文档、接口文档，需提升文档编写能力。

（三）对课程的建议与意见

1. 课程内容建议

• 增加设计模式实践课程：当前课程中，设计模式的学习多为理论讲解，建议增加“设计模式在实际项目中的应用”实践环节，如要求使用策略模式优化调度算法；

• 引入多线程编程内容：当前电梯为单线程处理请求，可引入多线程内容，实现“实时请求处理”（电梯运行过程中接收新请求），提升课程难度和实用性；

• 增加性能优化课程：讲解数据结构选型、算法时间复杂度分析、性能测试等内容，帮助学生开发更高效的代码。

2. 作业与实验建议

• 提供更详细的设计指导：对于“职责划分”“类间关系”等设计层面的要求，可提供更详细的指导，如给出参考类图、职责说明等，帮助学生更好地理解设计原则；

• 增加代码评审环节：组织学生进行代码评审，互相学习优秀设计，发现自身代码的不足，提升代码质量；

• 提供测试用例集：作业中可提供完整的测试用例集（包括正常场景、边缘场景、异常场景），帮助学生验证代码的正确性，同时学习测试用例设计方法。

（四）心得体会

三次电梯调度程序的迭代开发，是一次“技术提升+思维转变+工程实践”的全面训练。通过这次训练，我不仅掌握了Java面向对象编程的核心技术，还理解了迭代开发、设计原则、测试驱动等工程实践思想，为后续复杂系统开发奠定了坚实基础。

同时，我也认识到自身存在的不足，如数据结构应用、设计模式实践、单元测试编写等方面的能力仍需提升。在今后的学习中，我将针对性地加强这些方面的学习，通过更多实际项目锻炼自己的工程实践能力，努力成为一名“会设计、能编码、善测试、懂优化”的合格开发者。

最后，感谢课程提供的迭代式作业设计，让我在一次次发现问题、解决问题的过程中，逐步提升自己的能力。这种“实践-总结-优化”的学习模式，比单纯的理论学习更有效，希望今后能有更多这样的实践机会。