[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 在实践中提升前后端开发与撰写报告的能力，培养需求分析与团队协作素养。 |
| 这个作业在哪个具体方面帮助我实现目标 | 体验结对开发的过程 |
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025/3/20 14：15
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过；
总结
wasm-pack build --target nodejs打包时遇到了诸多问题
Error: failed to download from https://github.com/WebAssembly/binaryen/releases/download/version_111/binaryen-version_111-x86_64-windows.tar.gz
需要自行下载binaryen并加入到环境变量path。（https://juejin.cn/post/7327937033321070604）。
error occurred in cc-rs: failed to find tool "gcc.exe": program not found (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
需要配置mingw64环境。等等
Installing wasm-bindgen...处卡住
需要下载wasm-bindgen-cli，需要管理员权限运行命令行等
思考题R1：cdylib 表示生成一个 C兼容的动态链接库，其核心目的是让编译后的代码能够通过 C ABI（应用二进制接口） 被其他语言（如C/C++、Python、Node.js等）调用。
思考题R2：发现删去注释之后缺少函数信息，推测添加注释#[wasm_bindgen]能生成对应的JavaScript接口，使其能调用rust中的函数
→ 📖 Q0.3(P) 请记录下目前的时间。
2025/3/20 16:01
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025/3/20 16:17
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 2 | 2 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 40 | 20 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 10 |
| - Coding | - 具体编码 | 40 | 43 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 3 | 3 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 13 |
| TOTAL | 合计 | 140 | 124 |
- 我们仔细阅读了课程组给出的题目要求，经过讨论完成了程序设计；
- 参考rust菜鸟教程、rust官方文档和网上的若干rust资料，完成了程序实现；
- 在程序编译过程中，一开始忘记添加
#[wasm_bidgen]导致没有成功导出greedy_snake_move()函数； - 忽略了rust的基于表达式特性，导致函数返回值部分逻辑有问题，编译报错，查阅资料后修改正确；
- 最后编写了单元测试函数。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
主要考虑碰撞检测（即，移动后不能出现碰到蛇身/边界），设计了三个测试用例。具体实现上使用了rust中的测试函数，即通过#[test]属性和宏assert_ne！完成测试
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
验证代码单元的正确性，提前发现错误；提升代码质量，支持安全重构；促进模块化设计，减少耦合；降低调试成本，提升开发效率；提供文档说明，增强代码可维护性。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/3/20 18:00
→ 📖 Q1.6(I) 请写下本部分的心得体会。
完全理解了结对的作用，效率提高得非常明显^^
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025/4/1 14:50
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 30 | 120 |
| - Coding | - 具体编码 | 120 | 112 |
| - Code Review | - 代码复审 | 10 | 110 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 5 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 2 | 2 |
| - Size Measurement | - 计算工作量 | 2 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 209 | 391 |
- 阅读题目需求，明确在T1基础上增加了障碍物，由此引发对果子可获得性的判定；
- 将该问题转化为迷宫问题，通过bfs搜索最短路径进行求解，完成了基础版不能掉头的蛇；
- 构建测试样例时发现，基础的bfs搜索忽视了蛇转身的情况，使得蛇通过重复路径后转身吃到果子这一情况不能被bfs搜索。后续对该情况进行修正，即首选bfs搜索到的路径，当无法搜索到时，选择一个最大自由度（即后续可走路最多）的方向乱爬，并限制最大步数，每一步模拟后均检查是否存在bfs路径；若仍无法找到路径，则返回-1
- 在构建特殊测试样例报错时，发现了对题目理解上的错误。蛇是可以一直原地打转绕行的，也就是说对蛇身的判定，只要不向第一截蛇身的方向爬行即可。由于这个理解错误，前面的设计实际上过于复杂和没有必要了（）但是由于时间问题，我们仅针对正确性做了修改，没有精力再优化算法了TT
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
复用了T1中对场地边界和蛇身的碰撞检测
T1中的输入保障了蛇对果子的可获得性，而由于T2中增加了障碍物需要判断蛇是否吃到果子。因此先使用考虑蛇身为障碍物的bfs搜索查找bfs路径，如果不存在，再运行最大步数为50的模拟，每一步模拟后均检查是否存在bfs路径，存在则认为可达，返回记录的第一步方向；若50步后（或者进入死胡同）仍无法找到路径则返回-1。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
- 将策略分级，在编码中分优先级处理了可达路径与自由度策略，也便于后续扩展
- 将蛇身与障碍物统一为不可达方向
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
或许可以使用多目标点路径规划的蚁群+A*算法。（或者邀请美团外卖骑手口述一下外卖算法罢）
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/1 2025/4/1 14:50 ~ 17:42 第一次（基础的不能掉头的bfs蛇）
2025/4/2 09:00开始 ~10:36 结束第二次（实现了蛇的掉头）（修复了关于蛇不能原地打转的错误认知）
2025/4/2 10:40测试时发现新bug ~11:24 结束debug
→ 📖 Q2.7(I) 请写下本部分的心得体会。
一开始苦恼于bfs难以应对需要掉头的情况，但后续发现尝试着乱爬是一种不错的选择
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025/4/2 11:40 绝望开始
2025/4/2 12:20 看完题目，第一轮策略讨论结束
2025/4/2 14:30-15:00 进行了一些可能的实现方案调研
2025/4/2 18:30 开始实现
2025/4/2 21:00 开始测试，尝试改进
2025/4/2 22:35 结束
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 30 | 40 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 40 | 60 |
| - Coding | - 具体编码 | 120 | 110 |
| - Code Review | - 代码复审 | 80 | 90 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 0 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 0 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 0 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 360 | 315 |
- 查阅资料发现A*算法
- 口头讨论了一些改进策略并实现了代码
- 改进了障碍检测（因为发现我们的蛇常常提前暴死）
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
我们认为需求可以概括为：综合考虑得分（果子位置）和生存（它蛇位置），完成蛇的单回合方向决策，以达到最大化该局游戏得分的目的。
该需求可以分为两部分：得分和生存。我们考虑到：如果一味的采取避让策略，尽管存在生存优势但可能无法在得分上胜出；如果一味的冒风险争取果子，则可能过早死亡导致得分时间被压缩。因此，我们认为应当综合考虑这些因素，采取根据当前状况打分的方式，实现更为灵活的决策。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
- 避免死亡：最基础的单步碰撞检测（若碰撞直接否决方向） + 动态障碍物预测+洪水填充算法评估方向的安全系数
- 吃到更多果子：首先考虑是否存在果子，在多蛇对这个果子的竞争上自己有绝对优势（绝对最近，在其它蛇不可能过来的时候就能吃到），如果存在直接确定方向；然后综合评估该方向最近的果子距离（往这里走可能最快吃到这个果子） + 附近果子个数（往这里走吃完果子之后可以少绕路）
编程实现上，我们注意到A*路径规划算法中存在路径的代价评估机制，因此考虑在A*算法的基础上对评估机制进行改进实现我们的程序。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
我们写了两个版本的蛇，分别命名为简单蛇（只考虑吃最近果子和基础碰撞）和复杂蛇（按照上述策略），在4蛇游戏中统计了得分，具体得分如下：
| 轮次 | 复杂蛇1 | 复杂蛇2 | 简单蛇2 | 简单蛇2 |
|---|---|---|---|---|
| 1 | 18 | 28 | 1 | 10 |
| 2 | 3 | 18 | 4 | 6 |
| 3 | 8 | 6 | 2 | 1 |
| 4 | 12 | 27 | 1 | 15 |
| 5 | 32 | 17 | 13 | 6 |
| 6 | 4 | 1 | 4 | 1 |
| 7 | 9 | 15 | 2 | 5 |
| 8 | 54 | 21 | 4 | 10 |
| 均分 | 17.5 | 16.625 | 3.5 | 6.75 |
最终处于平均性能的考量，选择了相对来说对弈能力更强的复杂蛇
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/2 22:35
→ 📖 Q3.7(I) 请写下本部分的心得体会。
这部分主要在理解A*等搜索算法，但由于第二部分花费了较多时间，没有在碰撞检测部分进行更多的优化TT
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 两个人都不熟悉wasm和rust，而查阅菜鸟教程和官方文档等往往耗时过多，编译也出现很多问题和bug，在t1和t2开始之后因为效率原因还是投入了deepseek老师的怀抱。
- 由于没有准备private远程仓库，我们的所有代码编写都在一台机器上完成，导致领航员和编程手的角色转换上存在一些障碍（用不习惯对方的电脑键盘）
- 实际上后期还是出现了许多微信发文件的原始操作（x）
- 接上文，由于没有采用git的优雅合作，我们的版本管理变得十分复杂，特别是在t3评测多蛇对战的时候，经常分不清楚哪个文件是什么版本，给测试带来了麻烦
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
- 优点
- 沟通能力强
- 直觉敏锐，能快速发现核心问题以及特殊样例
- 抗压能力强，耐心包容，能始终冷静地解决问题
- 缺点
- 对rust不是很熟练Orz
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
- 优点
- 代码质量提升：实时审查减少错误，逻辑更严谨。
- 多视角观察：互相沟通，避免陷入局限的单视角。
- 高效解决问题：双重视角突破思维瓶颈。
- 缺点
- 沟通不顺利的话可能会降低效率
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/sigridwicks/BUAASE2025-PairProgramming
附录
附录A：基于 PSP 2.1 修改的 PSP 表格
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | ||
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | ||
| - Technical Background | - 了解技术背景（包括学习新技术） | ||
| - Coding Standard | - 代码规范 | ||
| - Design | - 具体设计（确定怎么实现） | ||
| - Coding | - 具体编码 | ||
| - Code Review | - 代码复审 | ||
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | ||
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | ||
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | ||
| - Size Measurement | - 计算工作量 | ||
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | ||
| TOTAL | 合计 |
浙公网安备 33010602011771号