[P] 结对项目：影蛇舞
[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 提升前后端开发能力，掌握软件工程方法，强化团队协作和项目管理能力，实现高效的软件开发实践。 |
| 这个作业在哪个具体方面帮助我实现目标 | 理解软件工程核心概念，培养批判性思维，提高对需求分析、软件设计、测试及团队协作的理解 |
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.04.05 8:30
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
III
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025.04.05 09:00
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025.04.05 09:00
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先是根据guide.md中的官方链接，学习了rust的基本语法、cargo的使用方法和安装以及wasm工具的使用教程并安装。随后在开发的问题中，我们发现执行
wasm-pack build --target nodejs
命令来编译和打包现有项目为Node.js模块的过程中，Installing wasm-bindgen长时间无法成功。所以我们就去调查资料后解决了这个问题，解决问题的办法就是，首先在wasm的官网上手动下载wasm-bindgen的压缩包，然后在本地解压后，将我们需要的wasm-bindgen.exe放到.cargo\bin目录下，然后在系统环境Path中增加该路径。之后我们在使用wasm-pack build --target nodejs这个指令的时候，改成wasm-pack build --target nodejs --no-install，使用本地已经安装好的wasm-bindgen。最后则是在编写结束之后，运行test.js后发现程序存在的bug，即没有考虑到，蛇头的下一步可以移动到蛇尾而导致出现问题。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
我们的测试方法主要是自动化测试结合人工构造特殊样例进行测试。首先是自动化测试，通过编写相关的自动化测试代码，随机生成多组数据，来测试代码的基本功能是否可行。其次是针对一些特殊的情况，我们人为的构造一些样例来进行测试，例如直线追逐、蛇身阻挡、贴墙移动等较为特殊的情况。我们的测试涵盖了普遍和特殊两种情况，所以整体来说，测试的有效性相对来说是很高的。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试在软件开发中起到保障代码质量的重要作用，它通过对程序中最小可测试单元进行验证，能及时发现和修复错误，减少后期调试成本，同时有利于代码的重构和维护，提高开发效率，并促进模块化设计，是提高软件可靠性和可维护性的关键手段。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.05 10:25
→ 📖 Q1.6(I) 请写下本部分的心得体会。
直接尝试用rust写代码还是很有意思的，同时在这一部分我们只需要考虑不断逼近目标，不太需要考虑死活，不迟到自己就可以了，主打一个莽夫。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025.04.05 11:30
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
我们阅读了T2的问题描述以及要求，然后我们思考了可行性的算法来解决问题，最后根据要求，在T1代码的基础上进行了修改。在这个过程中，我们遇到了一个问题，如何判断这个果子是否可达。后来查阅相关资料，我们得到了可以通过BFS（广度优先搜索算法）可以用来判断这个果子是否可达。因此，我们更换了思路，在最开始的时候利用BFS判断果子是否可达，然后，我们在编写代码的过程中，考虑到了一种特殊的情况，即蛇头走进了一个“死胡同”，导致吃不到果子，无法出来。所以我们利用这个BFS得到的结果来直接给出蛇头移动的下一步。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
由于T2中增加了增加了障碍物，并要判断果子是否可达以及出现的一些“死胡同”的情况，针对T1中简单暴力的算法，无法解决该问题，所以我们采用了BFS来实现吃果子。这与T1中，基于当前位置和果子位置来做出判断并不相同，所以对于T1的代码我们并未进行复用。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
#[derive(Clone, Copy, PartialEq, Eq, Hash, Debug)]
struct Point {
x: i32,
y: i32,
}
#[derive(Clone)]
struct SnakeState {
head: Point,
body: VecDeque<Point>,
tail: Point,
fruit: Point,
barriers: HashSet<Point>,
}
设计了Point和SnakeState这两个结构，方便后续直接复用状态，并把其他蛇作为barriers即可。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
每次选择最近的一个吃，并模拟从吃到位置出发能不能到达剩余的果子（如果有的话）
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.05 14:23
→ 📖 Q2.7(I) 请写下本部分的心得体会。
bfs大法，使用bfs算法来判断果子是否可达，然后根据bfs的结果来直接给出蛇头移动的下一步。然后，我们在编写代码的过程中，考虑到了一种特殊的情况，即蛇头走进了一个“死胡同”，导致吃不到果子，无法出来。所以我们利用这个BFS得到的结果来直接给出蛇头移动的下一步。而且我们在调研的过程中发现了A*算法，我们认为在这个问题中，用BFS即可较好的解决这个问题，速度不是我们的瓶颈，所以我们选择了BFS。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025.04.05 14:30
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先是阅读并详细了解清楚本章节所要求的内容，了解蛇蛇大战的基本规则。然后，我们就如何更快吃到果子，即在对战的过程中可以得到更多的分数进行了讨论，需要选择什么算法进行解决。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
我们通过构建棋盘状态、路径搜索以及决策逻辑对贪吃蛇的移动需求进行了建模。首先，将输入抽象为当前棋盘大小、蛇的坐标、果子位置和其他蛇的位置，构建一个包含障碍物（如蛇身、蛇头可能移动的危险区域）的棋盘模型。然后，采用A*路径搜索算法，从蛇头出发寻找通往最近果子的最短路径。在路径找到的前提下，通过比较路径中下一步的位置与当前蛇头的关系，确定对应的移动方向（上、下、左、右）。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
针对本次贪吃蛇的移动决策任务，我们采取了“安全优先、贪心吃果、灵活避险”的综合策略来优化蛇的行动路径。首先，为避免死亡，我们构建了障碍物集合，将自身蛇身、其他蛇的身体以及在多蛇情况下其他蛇头的下一步可能移动位置统一视为障碍，从而在路径搜索中规避撞墙、撞蛇的风险；其次，我们采用贪心策略，使用A*在所有果子中寻找一条最短可行路径，并优先前往最近的果子，提高得分效率。整体决策逻辑清晰，配合Rust的高效数据结构实现，能够在复杂局面中做出稳定、合理的移动选择。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
为了量度我们所实现的贪吃蛇程序模块的有效性，我们采取了多种定量分析方式来评估其对弈能力。首先，通过统计程序的平均得分，我们能够衡量其在吃果子方面的效率；得分越高，表明蛇的生存和进攻能力越强。其次，记录程序的存活时间或回合数，可以评价其避免死亡的能力，存活时间越长，说明程序的路径规划和避险能力越好。此外，死亡频率越低的程序表明其在避免碰撞和死胡同方面的决策更为有效。通过分析果子吞噬速率，我们可以评估程序在规定回合数内吃果子的效率，吞噬速率越高说明程序能够快速获取果子，提升得分。最后，通过与其他标准贪吃蛇算法的对比，我们能够进一步量化程序的优势，尤其是在面对复杂障碍和敌蛇时的表现，从而全面评价程序的对弈能力。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.05 18:30
→ 📖 Q3.7(I) 请写下本部分的心得体会。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
在回顾结对编程的过程中，我们发现了一些可以提升和改进的地方。首先，尽管我们的合作相对顺畅，但在任务分配和时间管理上可以更为精细。在某些阶段，分工不够明确，导致某些模块的实现进度较慢，或者有些细节被忽视。因此，未来可以更加明确地划分任务，避免重复工作，提高工作效率。
其次，沟通上的频率和方式也可以有所改进。在有些问题出现时，我们可能并没有及时交换想法和解决方案，导致某些错误被拖延处理。我们可以更频繁地进行代码审查和讨论，及时发现潜在的问题并解决。定期的回顾和讨论对于提高代码质量和减少后期修改的工作量非常重要。
另外，测试和调试的工作也可以更加系统化。尽管我们对代码进行了测试，但在某些情况下，特定的边界条件或复杂场景下的测试不够全面，导致某些异常情况未能及时发现。今后我们可以制定更详细的测试计划，确保每个功能模块都经过充分的验证，尤其是在处理复杂输入和特殊情况时。
最后，在代码质量方面，我们也可以更加注重代码的可读性和可维护性。虽然我们在功能实现上达到目标，但部分代码可能存在冗余或者结构不够清晰的情况。通过更好地重构代码、优化算法和文档注释，能够使代码更易于理解和后期维护。
总的来说，尽管我们完成了任务，但在合作的过程中依然有很多值得反思和改进的地方。通过总结这些经验，我们可以在今后的团队协作中不断提升工作效率，优化沟通方式和技术方案。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- 身体健康
- 羽毛球很厉害
- 头发很茂密
缺点：
- 电脑老是卡死，建议哈基助资助一下
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/hjzts/BUAASE2025-PairProgramming
附录
附录A：基于 PSP 2.1 修改的 PSP 表格
T1:
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 120 | 105 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 8 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 10 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 15 | 10 |
| - Coding | - 具体编码 | 40 | 35 |
| - Code Review | - 代码复审 | 10 | 7 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 2 |
| TOTAL | 合计 | 120 | 105 |
T2:
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 180 | 133 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 15 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 25 | 15 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 25 | 20 |
| - Coding | - 具体编码 | 70 | 50 |
| - Code Review | - 代码复审 | 10 | 8 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 15 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 5 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 3 |
| TOTAL | 合计 | 180 | 133 |
T3:
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 360 | 280 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 25 | 20 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 50 | 40 |
| - Coding Standard | - 代码规范 | 10 | 10 |
| - Design | - 具体设计（确定怎么实现） | 40 | 30 |
| - Coding | - 具体编码 | 1400 | 110 |
| - Code Review | - 代码复审 | 15 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 25 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 5 |
| TOTAL | 合计 | 360 | 280 |
浙公网安备 33010602011771号