[P] 结对项目：影蛇舞

结对项目：博客问题清单

请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。

Chapter.0 Belua multorum es capitums.（你是多首的怪物。）

引入

→ 📖 Q0.1(P) 请记录下目前的时间。

2025.04.05 8:30

调查

→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。

I. 没有听说过；

II. 仅限于听说过相关名词；

III. 听说过，且有一定了解；

IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。

answer:I. 没有听说过；

总结

→ 📖 Q0.3(P) 请记录下目前的时间。

2025.04.05 09:00

Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。

2025.04.05 09:00

→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
   首先是根据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

附录A：基于 PSP 2.1 修改的 PSP 表格

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

→ 📖 Q1.6(I) 请写下本部分的心得体会。

在开发贪吃蛇AI的过程中，我深刻体会到测试的重要性。通过编写测试用例，我提前发现了许多容易被忽略的问题，比如蛇头撞墙或咬到自己身体的bug。

刚开始觉得写测试很麻烦，但后来发现它其实节省了大量调试时间。特别是当游戏规则变化时，跑一遍测试就能快速确认哪些地方需要调整。测试也帮助我理清了算法逻辑，比如如何选择最优路径、如何处理特殊情况等。

这次经历让我明白，好的测试不是负担，而是开发的好帮手。它让代码更健壮，开发过程更顺畅。以后做项目，我会更重视测试，把它当作开发中必不可少的一部分。

Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）

结对过程

→ 📖 Q2.1(P) 请记录下目前的时间。

2025.04.05 11:30

→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

我们阅读了T2的问题描述以及要求，然后我们思考了可行性的算法来解决问题，最后根据要求，在T1代码的基础上进行了修改。在这个过程中，我们遇到了一个问题，如何判断这个果子是否可达。后来查阅相关资料，我们得到了可以通过BFS（广度优先搜索算法）可以用来判断这个果子是否可达。因此，我们更换了思路，在最开始的时候利用BFS判断果子是否可达，然后，我们在编写代码的过程中，考虑到了一种特殊的情况，即蛇头走进了一个“死胡同”，导致吃不到果子，无法出来。所以我们利用这个BFS得到的结果来直接给出蛇头移动的下一步。

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T2 中已实现的代码进行了哪些复用和修改。

由于T2中增加了增加了障碍物，并要判断果子是否可达以及出现的一些“死胡同”的情况，针对T1中简单暴力的算法，无法解决该问题，所以我们采用了BFS来实现吃果子。这与T1中，基于当前位置和果子位置来做出判断并不相同，所以对于T1的代码我们并未进行复用。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。

首先是可以将BFS可达性判断与移动决策逻辑分离两个模块进行分离，这样有助于理清代码逻辑、方便后续进行进一步的拓展和算法升级。同时也有助于我们分模块进行单元测试。其次是设计冗余的考虑，我们在设计代码的时候，如果T1的代码可以进行拓展之后可以解决T2的问题，可以实现多算法兼容，保留T1的简单决策逻辑作为反馈。最后，设计冗余中，我们可以进行输入冗余校验，保证输入格式正确，增强鲁棒性。

头脑风暴环节

**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：

在 🧑‍💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。

每次选择最近的一个吃，并模拟从吃到位置出发能不能到达剩余的果子（如果有的话）

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

2025.04.05 14:23

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

→ 📖 Q2.7(I) 请写下本部分的心得体会。

这次开发让我深刻体会到几个关键点。首先是想清楚再写代码很重要。一开始我们急着直接改T1的代码，结果发现T2的障碍物机制完全变了，之前的方法不适用。后来先花时间分析需求，改用BFS算法，反而节省了时间。然后是写测试时模拟各种特殊情况，增强代码的鲁棒性。最后是代码分模块的好处，把BFS和移动决策分开成两个模块，后面要加新功能或者替换相关功能的时候就比较方便，减少代码耦合的程度。

Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）

结对过程

→ 📖 Q3.1(P) 请记录下目前的时间。

2025.04.05 14:30

→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

首先是阅读并详细了解清楚本章节所要求的内容，了解蛇蛇大战的基本规则。然后，我们就如何更快吃到果子，即在对战的过程中可以得到更多的分数进行了讨论，需要选择什么算法进行解决。

需求建模和算法设计

→ 📖 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

附录A：基于 PSP 2.1 修改的 PSP 表格

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

→ 📖 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 表格

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	合计