结对编程心得

电梯调度系统项目文档

项目仓库地址：https://z.gitee.cn/zgca/repos/zgca/elevator_arrange/blob/develop/
队友博客参考：CSDN 博客链接

---

1. 项目简介

本项目作为《现代软件工程》课程核心大作业，由三人团队采用结对编程形式开发了一套完整的高性能电梯调度系统。系统以 Python 为核心语言，结合 Elevator-Saga 模拟器接口，构建了“优化版调度算法 + Web 可视化监控”的双层架构。

核心目标

在多电梯、多楼层、高并发乘客请求场景下，实现：

• ✅ 乘客等待时间最小化
• ✅ 电梯运行效率最大化

架构设计

• 算法层：专注调度决策，不耦合展示逻辑
• 监控层：独立拉取数据，实时渲染状态
  → 二者可独立替换，又能高效协同

---

2. PSP 时间管理（预估 vs 实际）

模块	预计时间	实际时间	差异原因
需求分析	2h	2h	需求清晰，仅需确认接口适配规则，无额外沟通成本
架构与设计	3h	4h	新增“动态分区”与“预判调度”功能，需额外设计分区逻辑与高峰时段判定规则
编码实现	5h	8h	原计划用基础 SCAN 算法，实际优化为“多维度评分派梯”，需实现评分模型与能耗计算
测试调试	2h	8h	发现“高峰时段分区冲突”“乘客等待时间统计偏差”等问题，需针对性修复
重构与优化	3h	6h	为实现“算法与监控解耦”，重构数据交互逻辑（算法传数据 → 监控拉数据）
合并讨论	2h	6h	GUI 界面设计方案存在多轮激烈讨论与取舍
提交验收	1h	2h	远程仓库流水线测试需适配环境变量，调试接口兼容性

差异分析总结

1. “开头第二步”最难：需求看似简单，但架构设计阶段需反复权衡调度策略与可视化呈现方式。
2. 实现 ≠ 设想：原以为仅需添加判断逻辑，实际开发中频繁遭遇意料之外的边界错误与并发问题。
3. 持续讨论与迭代：团队成员思维差异带来多元视角，不断推翻并优化原有方案，导致时间超支。

---

3. 核心架构：松耦合设计

为实现“算法与监控可独立替换”，采用 “数据分离 + 接口标准化” 思路，分两版迭代：

3.1 初版：基础分离（数据暂存）

• 算法层：监听模拟器事件，将状态暂存于本地字典
• 监控层：定时读取字典更新界面
• ❌ 问题：监控依赖算法运行，无法独立启动

3.2 优化版：彻底解耦（监控主动拉取）

• 算法层：仅通过 OptimizedElevatorController 控制电梯，不处理任何展示逻辑
• 监控层：通过 WebMonitorSystem 每秒轮询服务器，直接拉取原始数据，独立解析与渲染

✅ 优势：

• 算法可替换为 FCFS、LOOK 等任意策略
• 监控可切换为 PyQt5 等其他前端，只需保持 /api/data 接口一致

---

4. Web 监控系统：可视化 + 实时性

4.1 界面设计（三区布局）

区域	内容说明
电梯状态区	卡片式展示：编号、楼层、方向（↑/↓）、负载（如 3/10）、目标楼层列表，状态颜色标识
统计面板区	实时数据：总呼叫数、完成行程数、平均等待时间、各电梯能耗
系统日志区	倒序事件日志，按 info / warning / error 分色，便于排查问题

4.2 技术实现

• 后端：Python HTTPServer 提供：
  • / → 返回 HTML 页面
  • /api/data → 返回 JSON 状态数据
• 前端：ElevatorMonitor 类每秒轮询，仅更新变化内容，减少 DOM 操作
• 交互体验：方向箭头脉冲动画、进度条加载反馈

4.3 MVC 模式落地

层级	职责
Model	从模拟器拉取的原始状态数据
View	动态生成的 HTML 元素
Controller	ElevatorMonitor 负责数据处理与视图触发

---

5. 结对编程：三人协作模式

在传统“驾驶员-导航员”基础上，新增 “审核员” 角色，形成闭环协作：

角色	职责
驾驶员	编码实现（如评分计算）
导航员	把控逻辑（如提醒考虑早高峰场景）
审核员	检查规范与边界（如满载时是否仍派梯）

🔁 每 2 小时轮换角色，确保全员深度参与。

协作亮点

• ✨ 利用 GPT-5 / 豆包 生成基础框架（如 HTML 结构），节省 50% 编码时间
• 📝 即时文档同步，避免重复开发
• 💬 采用 “三明治沟通法”：
  肯定成果 → 提出改进（如硬编码问题） → 鼓励收尾

同伴优点

• 做事非常认真仔细
• 积极承担任务，非常负责
• 沟通很舒服

同伴缺点

• 过度依赖AI
  

---

6. 项目收获与反思

能力提升

• 🛠️ 熟练使用 Git 进行团队协作开发
• 🤖 学会精准向 AI 描述需求（如分模块请求建议，而非整体生成）

经验教训

• 📈 一个较大的项目一定要先自己了解整体架构和逻辑，不能直接完全交给AI

---

7. 总结

本项目不仅实现了高效调度与实时监控，更在 工程思维 与 团队协作 上带来双重成长：

• 通过多维度评分模型，理解了“场景化设计”的价值；
• 通过松耦合架构，掌握了“可扩展系统”的构建方法；
• 通过三人结对编程，很多时候同伴能一下指出自己看不出的问题，深刻体会到“协作共赢”的力量。

---