[P] 结对项目：影蛇舞

结对项目：博客问题清单

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

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

引入

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

31/03/2025 19:30

调查

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

I. 没有听说过；

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

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

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

I.没听说过

总结

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

31/03/2025 20:29

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

结对过程

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

31/03/2025 20:33
配了一个半小时环境，燃尽了
再启动时间：04/04/2025 16:10

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

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

---

估计任务耗时

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	5	3
- Estimate	- 估计这个任务需要多少时间	150	198
DEVELOPMENT	开发	120	153
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	20	10
- Technical Background	- 了解技术背景（包括学习新技术）	30	90
- Coding Standard	- 代码规范	10	3
- Design	- 具体设计（确定怎么实现）	10	20
- Coding	- 具体编码	20	12
- Code Review	- 代码复审	10	5
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	10	10
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	10	3
REPORTING	报告	30	45
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	15	20
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	20
TOTAL	合计	155	121

---

任务记录
首先花了很长时间折腾环境，探索如何跑Rust。过程中最大的问题是构建不了，查找群聊后修改了代理配置，还是不行，最后选择改成手动下载。
第一次修改代码时发现新增的代码不生效，查询大量资料后，手动删除了.cargo目录下的registry似乎就解决了（也可能并不需要删除这个）

实际编写较为顺利，对Rust语法不熟练的地方借助LLM辅助编写。

---

设计思路

• 先确定蛇身体方向，四个方向排除一个。
• 在剩下的三个方向中fake move获取新坐标，判断是否撞墙或者撞到自己，借此筛选出可以移动的方向。
• 在可以移动的方向中选择举例果子最近的方向。

测试

→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。

测试用例内容方面，为了测试是否能正确运行，编写了两个简单测试样例。接着考虑容易相撞的情况进行特殊情况的样例编写。
测试有效性方面，主要考虑是否在样例合法的情况下覆盖多种极端情况。由于T1条件较为简单，因此重点考虑了【当蛇蛇被堵在角落里只能往尾巴走】这种情况下是否能正常给出结果。

→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。

软件开发工程相对较大，解决的是实际问题，需要综合考虑多种情况。单元测试的好处，一个是可以在软件开发的过程中随时测试，防止全都写完结果发现有问整个推翻重来；另一个是在更细的粒度下测试可以考虑更多种情况。另外，由于需要进行单元测试，这也在一定程度下要求程序高内聚低耦合；经过单元测试的代码，也会比一大坨代码整体更容易维护和移植。

总结

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

04/04/2025 17:07

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

为什么大把时间都用在配环境上了，难道我其实是环境工程学院的

刚拿到文档的时候特别迷茫，很多东西都不了解。索性和搭档一起摸爬滚打还是弄出来了，很有成就感啊！并且能感觉到在其中磨合的不只是我和电脑（闭目），还有和搭档的沟通协作方式。可能这也是结对的魅力所在吧。

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

结对过程

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

04/04/2025 17:07

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

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

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	3	3
- Estimate	- 估计这个任务需要多少时间	180	243
DEVELOPMENT	开发	150	209
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	20	10
- Technical Background	- 了解技术背景（包括学习新技术）	20	14
- Coding Standard	- 代码规范	0	0
- Design	- 具体设计（确定怎么实现）	30	15
- Coding	- 具体编码	20	20
- Code Review	- 代码复审	30	120
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	10	20
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	20	10
REPORTING	报告	30	34
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	15	20
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	9
TOTAL	合计	183	246

---

任务记录
一开始试图在之前的代码基础上增加“果实是否可达”的检查，其他不变。然而这样的结果是蛇蛇容易一直安全地绕圈。
试图记录蛇蛇走过的地块，不让他多次经过同一个地块。然而实现的函数是一步步调用，如果要增加一个静态的记录容器略显奇怪，因此这个方案被废除掉了。
退回到之前的版本，试图在有多个安全方向的情况下随机选择一个方向，进而破除循环，但是也是治标不治本，未采用。
最后选择修改BFS的方法，不止用于可达性检测，还返回这条可行的路径。然后吩咐蛇蛇沿着这个可行的路径行走。虽然不一定是最近的路径，但T2也没有追求性能，所以直接采用了这个方案。

代码可复用性与需求变更

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

一开始进行了大批量的复用，但是在迭代过程中已经修改得和最初的两模两样了，最终只是在局部（如碰撞检测、方向选择）等进行了少量代码复用。

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

模块化设计：可以考虑把蛇蛇的碰撞检测，移动方向探寻，fake move等封装成独立的模块，这样要修改的时候可以减少对全局的影响，并且代码逻辑也会更加清晰。
冗余设计：可以多预留一些接口，或者同样的数据多存几种数据结构。代码需求变更后可能会对数据的格式有新的要求，特别是如果一开始设计的时候为了方便写了比较别扭的代码，那最好留一个更加通用的冗余便于拓展。

头脑风暴环节

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

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

初始获取所有果子的位置，计算贪吃蛇当前位置到每个果子的最短路径。构建果子之间的距离矩阵。随后找到果子的访问顺序，规划从贪吃蛇当前位置到第一个果子的路径。每次贪吃蛇吃掉一个果子后，更新状态，重新计算剩余果子之间的最短路径，并调整访问顺序，确保路径不会导致贪吃蛇撞到自己或障碍物。

总结

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

04/04/2025 21:29

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

好像做出了很多愚蠢的尝试，太坏了啊……根本问题是为了快点推进进度，在一开始设计的时候并没有考虑的太全面。下次一定会和队友先敲定完全后再开始动手！

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

结对过程

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

4.6 8：30

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

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

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	10	10
- Estimate	- 估计这个任务需要多少时间	10	10
DEVELOPMENT	开发	200	230
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	10	10
- Technical Background	- 了解技术背景（包括学习新技术）	5	5
- Coding Standard	- 代码规范	5	5
- Design	- 具体设计（确定怎么实现）	10	15
- Coding	- 具体编码	100	105
- Code Review	- 代码复审	10	20
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	20	20
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	60	70
REPORTING	报告	20	20
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	10	10
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	5	5
TOTAL	合计	230	260

---

到这里遇到的问题比起之前已经少很多了，基本上都是代码层面的，不怎么需要额外查找资料。

需求建模和算法设计

→ 📖 Q3.3(P) 请说明你们如何建模这一需求。

思路大致沿用T2，将场上其他蛇蛇视为障碍物。我们的蛇蛇目标是在不死的情况下，努力往最近的果子的方向走。

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。

首先，由于其他蛇的位置直接影响我们的寻路，我们重新规划了“障碍物”的区域。考虑到其他蛇蛇也会移动，因此其他蛇的蛇尾并不用视为障碍物。然而，其他的蛇蛇盘起来的情况下，如果他选择往蛇尾移动，我们可能会直接撞上。我们最终考虑把其他蛇拆成蛇头、蛇头周围四格、第二节身体（第一节算在蛇头周围四格里），不让我们的蛇走到这些地方。重新规划后蛇蛇不那么容易暴毙了，而且有时候可以钻别蛇的蛇尾！
另外，我们还考虑到有时候蛇蛇到别的果子的路会被堵死，但是蛇蛇可以通过绕圈来苟活一段时间，直到其他的蛇走掉或者死掉，然后再进行移动。
果子的寻路采用简单的贪心算法，计算路径最短的果子然后出发。

软件度量

→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。

由于蛇死不能复活，因此我们优先考虑蛇的生存能力，其次是获取果子的数量。具体而言，我们考虑了蛇蛇的生存能力（存活回合数或步数），果子获取能力（在都存活的情况下是否获取最多）。

总结

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

4.6 11：41

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

到这个部分大家已经相当熟练了，配合得很有默契，真好啊。
蛇蛇打架也太好玩了。
还有优化空间但是已经花了很长时间了TT！那就好好休息吧！

结对项目总结

结对过程回顾和反思

→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。

→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。

应该第一周了解一下as和rust的相关环境，这样就不会在开始时浪费很多时间在配环境和尝试运行测试上了。
到第三次时有很多思路当时没有记录，应该在讨论时直接填写到表格里。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。

优点：非常有耐心，非常能肝，在我有时候太过于急躁或者异想天开的时候能及时拉回现实，非常优秀的搭档！
缺点：怎么没有熟练掌握git操作啊（恼

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。

我理解的结对编程就是两个人分工迅速地完成同一份任务，这里的分工不是指任务量上的，而是指工作方式上的。总体来说，一个人负责把控思路和整体情况，另一个人负责实现前者的想法以及根据前者的指导进行修改。

优点是两个人在逻辑上可以有一定程度上的分工，这样负责实现细节的人就只需要闷头干就好而不用担心是否会偏离整体，负责整体把控的人也不用陷入细节之中。
大家不同思维碰撞会产生新的有趣的想法！
缺点是在大家都不太明白的时候，合作似乎并不会变得高效，反而会消耗双倍的时间。
并且要找两个人都有大块的时间好困难啊！

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。

https://github.com/Carbon231/Snake-PP

附录

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